MongoDB переносять двома способами: швидким офлайн-перенесенням через mongodump і mongorestore для невеликих баз, і через тимчасову репліку для великих баз даних, де неприпустима довга зупинка запису.
Який спосіб перенесення обрати
Дамп підходить для баз до 20–30 ГБ, коли простій у кілька хвилин не критичний. Для бойових баз більшого розміру або систем без вікна обслуговування застосуйте додавання нового сервера до реплика-сету — тоді перемикання триває секунди, а не час повного копіювання.
| Спосіб | Розмір бази | Простій | Складність |
|---|---|---|---|
| mongodump / mongorestore | до 30 ГБ | хвилини | низька |
| Реплика-сет (replicaof) | будь-який | секунди | середня |
Перенесення через mongodump і mongorestore
На старому сервері зробіть дамп бази у бінарному форматі BSON — він компактніший і переноситься швидше за текстовий експорт:
mongodump --host localhost --port 27017 --db shop --out /backup/mongo_dump
Заархівуйте каталог і передайте на новий сервер через rsync, як описано у статті перенесення файлів сайту:
tar -czf mongo_dump.tar.gz /backup/mongo_dump
rsync -avz mongo_dump.tar.gz user@newserver:/backup/
На новому сервері розпакуйте архів і відновіть базу:
tar -xzf mongo_dump.tar.gz
mongorestore --host localhost --port 27017 --db shop /backup/mongo_dump/shop
Прапорець --drop перед відновленням видалить наявні колекції з такою самою назвою, коли на новому сервері вже є тестові дані.
Перенесення без простою через реплика-сет
Додайте новий сервер як учасника наявного реплика-сету — MongoDB сама скопіює дані через початкову синхронізацію і надалі триматиме їх актуальними:
rs.add("newserver.example:27017")
Зачекайте на стан SECONDARY у нового вузла командою rs.status() — поле stateStr повинно змінитися зі STARTUP2 на SECONDARY. Потім перемкніть роль основного вузла:
rs.stepDown()
Старий сервер стане вторинним, а новий — основним, без зупинки запису. Клієнти повністю перемкнулися на нову адресу — старий вузол можна вивести з реплика-сету командою rs.remove("oldserver.example:27017").
Налаштування підключення застосунку до нового сервера
У рядку підключення вкажіть новий хост або, коли застосовано реплика-сет, повний список учасників — драйвер MongoDB сам знайде поточний primary:
mongodb://appuser:password@newserver.example:27017,server2.example:27017/shop?replicaSet=rs0
Перевірте автентифікацію: на новому сервері авторизацію увімкнено вперше — створіть користувача з потрібними ролями до перемикання застосунку, інакше він втратить доступ до бази одразу після переїзду.
db.createUser({ user: "appuser", pwd: "новий_пароль", roles: [{ role: "readWrite", db: "shop" }] })
Перевірка даних після перенесення
Порівняйте кількість документів у ключових колекціях на старому і новому сервері — розбіжність вказує на незавершену синхронізацію або помилку restore:
db.orders.countDocuments()
db.users.countDocuments()
Перевірте індекси командою db.orders.getIndexes() — mongorestore відновлює індекси автоматично, а при ручному експорті через mongoexport їх доведеться створювати заново.
Чек-лист міграції MongoDB
- Обрано відповідний спосіб: дамп для невеликої бази, реплика-сет для бойової без простою.
- Дамп знято у форматі BSON і передано без пошкодження архіву.
- Новий вузол реплика-сету досяг стану SECONDARY перед перемиканням.
- Рядок підключення застосунку оновлено, авторизацію налаштовано заздалегідь.
- Кількість документів і індекси звірено зі старим сервером.
- Старий вузол виведено з реплика-сету лише після повного перемикання клієнтів.
Загальні принципи звірки даних після переїзду будь-якої бази зібрані у статті перенесення бази даних MySQL, а фінальний чек-лист сайту — у статті чеклист перевірки сайту після міграції.