Оновлення 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%. Маємо 5+ років досвіду з MongoDB, виконали понад 100 апгрейдів. Вартість робіт починається від $1000 за один крок для Replica Set. Економія від відсутності даунтайму може значно перевищити витрати на апгрейд.

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.