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, а финальный чек-лист сайта — в статье чеклист проверки сайта после миграции.