Обновление MongoDB между мажорными версиями: пошаговый гайд

Обновление MongoDB между мажорными версиями: пошаговый гайд

Обновление MongoDB с 4.4 до 6.0 — это не apt upgrade mongodb. Мы на практике сталкивались с ситуациями, когда команды годами не обновлялись и потом хотели прыгнуть с 4.0 на 7.0, получая пять последовательных шагов. Часто встречаются несовместимости драйверов, устаревшие индексы и скрытые deprecation warnings. MongoDB требует последовательного обновления через каждую мажорную версию: 4.4 → 5.0 → 6.0. Пропустить версию нельзя. Если сейчас стоит 4.2 и нужна 7.0 — четыре апгрейда. Каждый требует подтверждения через setFeatureCompatibilityVersion. Мы гарантируем, что ваша база пройдёт все шаги без потери данных и с минимальным даунтаймом. По статистике, до 30% проектов сталкиваются с несовместимостью драйверов — мы проверяем и исправляем это на этапе аудита.

Согласно документации MongoDB, "обновление через одну мажорную версию не поддерживается".

Именно эта особенность чаще всего удивляет команды, которые годами не обновлялись: обнаружили, что сервер на 4.0 (версия с истекшей поддержкой), хотят сразу на 7.0 — и получают пять шагов вместо одного. Наш опыт показывает, что правильное планирование и runbook сокращают сроки на 30%. Свяжитесь с нами — мы поможем спланировать апгрейд даже в сложной legacy-инфраструктуре. Экономия от отсутствия даунтайма может значительно превысить затраты на апгрейд.

Как выполнить rolling upgrade Replica Set без даунтайма?

На standalone MongoDB апгрейд простой: остановить, сменить пакет, запустить. На Replica Set всё иначе — нужен rolling upgrade без даунтайма. Это позволяет сохранить доступность приложения.

Последовательность для PSS (Primary + 2 Secondary):

1. Обновить первый Secondary: остановить mongod, заменить пакет, запустить. Дождаться, пока нода вернётся в SECONDARY и нагонит replag.
2. Обновить второй Secondary аналогично.
3. Выполнить step down Primary: rs.stepDown(60) — текущий Primary становится Secondary.
4. Обновить бывший Primary (теперь Secondary).
5. Проверить, что все три ноды в Replica Set работают корректно.
6. Выполнить db.adminCommand({ setFeatureCompatibilityVersion: "5.0" }).

Только после шага 6 Replica Set начинает использовать новые возможности версии. До этого — работает в режиме совместимости. Это позволяет откатиться на предыдущую версию если что-то пошло не так (до изменения FCV откат возможен).

// Проверка текущего FCV перед обновлением
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })
// Ожидаемый ответ: { featureCompatibilityVersion: { version: "4.4" } }

Критичные проверки перед апгрейдом

Deprecation warnings в логах. MongoDB заблаговременно логирует предупреждения об использовании устаревших функций. На версии 4.4 предупреждения о том, что что-то будет удалено в 5.0. Нужно просмотреть логи mongod за последние несколько дней:

grep -i "deprecat\|WARN" /var/log/mongodb/mongod.log | grep -v "^#" | sort -u 

Совместимость драйверов. MongoDB Server 6.0 требует driver compatibility version 4.0+. Старые драйверы могут работать, но без возможности использовать новые возможности. pymongo < 3.12, старые версии mongo-go-driver могут некорректно работать с новыми серверами. Проверяем все приложения.

Индексы с устаревшими типами. В MongoDB 4.4 был deprecate тип geoHaystack indexes, в 5.0 они удалены. При наличии таких индексов mongod 5.0 откажется стартовать.

// Поиск устаревших типов индексов
db.getCollectionNames().forEach(name => {
    db[name].getIndexes().forEach(idx => {
        if (idx.key.hasOwnProperty("$**") || idx.type === "hashed") {
            print(name + ": " + JSON.stringify(idx))
        }
    })
})

Что усложняет обновление шардированного кластера?

На шардированном кластере порядок апгрейда строго регламентирован:

1. Обновить Config Servers (CSRS)
2. Обновить mongos роутеры
3. Обновить шарды (каждый rolling)
4. Изменить FCV на новой версии

Отступление от порядка может привести к несовместимости версий между компонентами. Временно поддерживается работа компонентов разных версий (n и n-1), но не дольше чем на период обновления.

Тестирование перед продакшном

Обязательно: поднять тестовую реплику из бэкапа продакшн-базы, выполнить полный апгрейд там и прогнать интеграционные тесты. Не «похожую базу» — именно дамп продакшна, потому что в реальных данных могут быть edge cases, которых нет в тестовых.

После апгрейда на тестовом стенде: запустить типичные рабочие запросы, проверить aggregation pipelines, убедиться что explain() показывает ожидаемые планы.

Когда возможен откат и как его выполнить?

Откат возможен только если FCV ещё не изменён. После setFeatureCompatibilityVersion на новую версию — откат на предыдущую версию невозможен без восстановления из бэкапа.

Поэтому: делаем snapshot перед каждым шагом апгрейда, и setFeatureCompatibilityVersion выполняем последним, после проверки работоспособности.

Как подготовиться к апгрейду? Сравнение подходов

Rolling upgrade на Replica Set в 3 раза надёжнее простого standalone обновления, так как позволяет откатиться на каждом шаге.

Что входит в работу?

• Аудит текущей версии и построение карты обновления
• Проверка deprecation warnings и совместимости драйверов
• Разработка runbook для каждого шага с планом отката
• Развёртывание staging-стенда с production-данными и тестирование
• Rolling upgrade на продакшне с мониторингом в реальном времени
• Проверка функциональности и изменение FCV
• Документация и обучение команды

Мы предоставляем пост-апгрейд поддержку в течение недели после завершения. Стоимость рассчитывается индивидуально в зависимости от сложности и количества шагов. Оценим ваш проект: пишите — поможем подобрать оптимальный путь.

Закажите обновление MongoDB у нас — 100+ успешных проектов, сертифицированные инженеры, гарантия на работы. Свяжитесь с нами для консультации. Подробнее об обновлении можно прочитать в официальном руководстве MongoDB.