Миграция MongoDB без остановки: replica set и план отката

Старый кластер MongoDB не справлялся: росли лаги репликации, страдали наш сервис и соседние, которые читали из тех же шардов. Остановить прод на окно миграции нельзя — SLA 99.99%.

Варианты

Подход	Плюсы	Минусы
mongodump / restore	Понятно, один снимок	Долго, риск рассинхрона на дельте
Replica set + постепенный cutover	Минимальный простой	Сложнее планирование, нужен мониторинг лага

Выбрали перенос через replica set: подняли новые узлы, добавили в топологию, догнали лаг, переключили primary. В любом случае перед cutover сделали полный бэкап на отдельное хранилище — не обсуждалось.

На скрине — Mongo Express на стенде: список баз (admin, cicd, рабочие). В проде админку держим только во внутренней сети; для миграции она помогала сверить количество коллекций и индексов до/после.

Ход работ

1. Новые серверы, те же версии движка и совместимый storage engine.
2. Initial sync, контроль replLag в Grafana.
3. Read preference secondaryPreferred на части read-only воркеров для прогрева.
4. Cutover в согласованное окно (ночь UTC+3): elect новый primary, DNS/connection string.
5. 48 часов усиленного мониторинга, старый кластер не трогали — rollback lane.

Результат

На новых железах доступность уложилась в 99.99%, лаги ушли. Сервисы перестали «подвисать» на тяжёлых aggregate.

Чему научился

Самая тяжёлая часть — не код приложения, а план отката: кто переключает строку подключения, за сколько минут, какой критерий «откатываемся» (лаг > N секунд, ошибки записи > X%). Мы расписали это в runbook на две страницы; один раз откат отрабатывали на стейдже — и хорошо, что отработали.