Приветик. Я вам задачку принёс)
Ниже — сокращённый production-кейс, собранный из нескольких похожих ситуаций, в которых я успел побывать. Цифры и отдельные детали изменены, но ограничения вполне реальные.
Есть сервис, который работает круглосуточно и хранит основное состояние в PostgreSQL. База занимает около 1,7 ТБ. В пике приложение обрабатывает примерно 3 500 запросов в секунду, а на стороне PostgreSQL это превращается в 15–20 тысяч запросов. Значительная часть нагрузки связана с записью.
Сейчас база работает на одном мастере и двух репликах. Команде нужно перенести её в другой инфраструктурный контур и одновременно перейти на новую мажорную версию PostgreSQL.
Полностью остановить трафик нельзя. Ночью нагрузка снижается примерно на треть, но не исчезает. На пиках у реплик иногда растёт лаг, а основной узел периодически упирается в дисковую подсистему. Команда приложения может выкатывать изменения поэтапно. После переключения должен оставаться понятный способ отката.
На этом вводные всё. 😀
Предлагать схему миграции пока не нужно. Не требуется писать RFC, выбирать конкретные инструменты или подробно расписывать последовательность переключения.
Представьте, что вас подключили к обсуждению и попросили оценить возможные планы.
Какой информации вам не хватает до выбора плана?
Выберите одну вводную, которую запросили бы первой. Когда несколько вариантов кажутся одинаково важными, выбирайте тот, который способен сразу исключить часть стратегий.
В комментариях можно использовать простой формат:
Мне не хватает информации о ________, потому что от неё зависит ________.
Достаточно одной вводной и короткого аргумента. Полную архитектуру описывать не нужно.
Если не хочется отвечать публично, аргумент можно отправить мне в личку или в сообщения канала.
Для последующего разбора у меня уже подготовлены три стратегии миграции. Опрос ниже анонимный,, чтобы увидеть, какие неопределённости вы считаете критичными до обсуждения инструментов, порядка переключения и процедуры отката.