Приложение не знает, что за строкой подключения стоит именно MongoDB Atlas. Оно не читает логотипы. Оно знает, что по адресу из конфигурации отвечает сервер, что после авторизации можно прочитать коллекцию products, что запрос по артикулу вернётся быстро, а вторая вставка с тем же артикулом будет отклонена. Если всё это сохранится, приложение «узнает» прежнюю базу. Если пропадёт хотя бы одно звено, переезд формально состоялся, а работать будет уже другая система.
Поэтому вопрос звучит не «как скопировать документы», а шире: что ещё нужно перенести или воссоздать, чтобы поведение осталось прежним. Дальше разберём это на небольшом вымышленном примере и пройдём путь от строки подключения до индекса.
Из чего состоит то, что мы называем «базой»
Возьмём вымышленный каталог интернет-магазина запчастей для велосипедов. База shop, коллекция products, документы вида: артикул sku, название, цена, остаток stock, категория. Приложение делает три вещи: читает карточку товара по sku, выводит список товаров категории, а при заказе уменьшает остаток. Поле sku уникально: два товара с одним артикулом в каталоге недопустимы.
Уже из этого описания видно четыре слоя переезда.
- Документы. Самое очевидное: содержимое коллекций.
- Индексы. Уникальный индекс по
sku— это не украшение, а правило целостности. Индекс поcategoryи цене — это скорость выдачи списка. - Учётные записи и роли. Приложение подключается под определённым пользователем с ограниченными правами. Отдельно существуют административные пользователи.
- Параметры подключения. Строка URI, имя базы, параметры TLS, таймауты, поведение драйвера при потере соединения.
Теперь посмотрим, какие из этих слоёв покрывает штатный инструмент выгрузки.
Что реально попадает в дамп
Согласно документации mongodump, утилита экспортирует документы, метаданные и параметры коллекций, а также определения индексов. Это хорошая новость для нашего каталога: уникальность по sku не нужно будет вспоминать по памяти и создавать вручную. Она описана в экспорте.
Обратная сторона: дамп описывает данные, а не весь облачный сервис. Всё, что относится к управлению кластером на стороне платформы, — настройки сети, расписания, оповещения, управление аккаунтом, а также возможности вроде полнотекстового поиска, работающего как отдельный сервис, — не превращается в файл, который можно положить на свой сервер. Обещать перенос control plane или Search через mongodump нельзя: это другая категория объектов. Если приложение использует поисковые индексы платформы, перенос придётся планировать как отдельную задачу с отдельной заменой, а не как строчку в списке.
Есть и ограничение, которое заметят не все: документация указывает, что использование mongodump с Queryable Encryption и CSFLE ограничено. Если в вашем проекте шифрование полей на стороне клиента включено, обычный сценарий «выгрузил и загрузил» требует отдельного разбора по документации, а не копирования команды из заметок.
Один запрос от строки подключения до индекса
Проследим за одним обращением: пользователь открывает карточку товара с артикулом BK-2041.
- Драйвер приложения берёт URI из конфигурации. В нём заданы хост, имя базы, пользователь, способ аутентификации и параметры шифрования канала. Для Atlas это обычно адрес кластера, у собственного сервера он будет другим. Уже здесь отказ возможен без единой проблемы с данными: неверная база аутентификации или отличающиеся параметры TLS дадут ошибку подключения.
- Сервер проверяет учётную запись. Пользователь, созданный в Atlas, на новом сервере не появится сам собой. Что именно можно восстановить, зависит от того, попали ли данные о пользователях и ролях в экспорт и в каком режиме выполняется восстановление, — так сформулировано в документации mongorestore. Надёжнее не рассчитывать на это, а явно создать пользователя приложения на новом сервере с минимально нужной ролью и проверить вход под ним.
- Запрос
find({ sku: "BK-2041" })доходит до коллекции. Если индекс поskuесть, сервер идёт по нему. Если нет, он просматривает коллекцию целиком. На сотне документов разницы не заметишь, на сотнях тысяч — заметишь. - При заказе выполняется обновление остатка. А при добавлении нового товара уникальный индекс решает, принять документ или отклонить дубль.
Видно, что приложение зависит от результата работы всех четырёх слоёв сразу, а документы — лишь один из них. Типичная картина неудачного переезда выглядит так: данные на месте, но вход не проходит; или вход проходит, но список категории грузится вдесятеро дольше; или всё быстро, но дубли артикулов начали проскакивать.
Как проверить это без боевой базы
Репетицию стоит устроить на отдельном VPS, не трогая действующий кластер. Порядок такой: выгрузить копию, восстановить её на пробный сервер, создать пользователя приложения, направить на него тестовую копию приложения и пройти три операции каталога. Чтение карточки по sku подтверждает вход и индекс поиска. Изменение остатка подтверждает права на запись. Попытка вставить товар с уже существующим артикулом должна быть отклонена — это проверка того, что уникальный индекс действительно приехал вместе с данными. Какие числа вы увидите по времени ответа, зависит от вашего объёма и сервера; заранее их не угадать, поэтому результат репетиции нужно записать самому.
Индекс можно проверить напрямую в оболочке: посмотреть список индексов коллекции и сравнить с тем, что есть в Atlas. Расхождение в списке — повод остановиться до того, как переключать приложение. Ссылку на подробности установки и настройки сервера под такие задачи можно найти в материале VPS для MongoDB: установка и безопасная настройка.
Что Atlas делал молча и что теперь делаете вы
Пока база живёт в облачной платформе, многое происходит фоном, и приложение этого не замечает. Переезд на VPS означает, что часть обязанностей переходит к вам. Составим честный список, не приписывая ничего, чего нет в вашей конфигурации заранее.
| Зона | В управляемом сервисе | На своём VPS |
|---|---|---|
| Установка и обновления сервера MongoDB | выполняет платформа в рамках сервиса | вы выбираете версию и обновляете сами |
| Сетевой доступ | настраивается через средства платформы | межсетевой экран и привязка адресов на вашей стороне |
| Пользователи и роли | создаются через интерфейс платформы или базу | создаются и сопровождаются вами в самой базе |
| Резервные копии | зависят от плана и настроек платформы | нужно построить и проверять самим |
| Мониторинг и оповещения | есть в интерфейсе платформы | нужно развернуть или подключить отдельно |
| Отказ узла | зависит от топологии кластера | зависит от того, что вы построили |
О резервных копиях на стороне хостинга отдельно: в публичном описании VPS MAATRIX подтверждены NVMe-диски, процессоры AMD EPYC и root-доступ, но автоматические резервные копии во всех тарифах как факт не заявлены. Значит, расписание дампов, место их хранения и проверка восстановления — ваша работа, и закладывать её в план нужно сразу, а не после первой потери данных.
Версии тоже требуют внимания. Документация mongorestore указывает, что у источника и назначения должна быть совместимость по основной версии или по feature compatibility version. На практике это значит: прежде чем ставить MongoDB на сервер, выясните, какая версия работает в Atlas у вашего кластера, и выберите для VPS такую, с которой восстановление допустимо. Какая именно версия окажется у вас, зависит от вашего кластера и выбора; фиксированную версию из этой статьи брать не нужно.
Standalone и replica set: не одно и то же
Кластер Atlas устроен как набор узлов, а значит, прикладной код мог незаметно привыкнуть к этому. Одиночный экземпляр mongod на одном VPS — это standalone. Несколько узлов, объединённых в replica set, — другая топология. Отличия касаются не только устойчивости.
Первое: подтверждённая в документации возможность включать в дамп изменения, происходившие во время экспорта (опция oplog), привязана к топологии и ограничениям самой команды. Для standalone-сервера эта схема может оказаться недоступной, поэтому непротиворечивый снимок живой базы без остановки записи там не получить так же, как на replica set. Универсальную команду с этой опцией без проверки условий давать нельзя: доступность oplog и сами операции на Atlas зависят от уровня кластера и прав доступа. Сначала выясните, что вам разрешено на исходной стороне.
Второе: если приложение использует возможности, свойственные replica set, ваш переезд на одиночный сервер изменит поведение. Подробности зависят от кода, но вопрос для проверки простой: есть ли в приложении операции, рассчитанные на набор реплик? Если да, топологию нужно строить сопоставимой, а не упрощать ради удобства. Обещать, что один VPS с replica set из нескольких процессов даст такую же отказоустойчивость, как управляемый кластер, нельзя: если все узлы находятся на одной машине, отказ машины останавливает их все. Несколько VPS сами по себе тоже не гарантируют размещения на разном оборудовании — это нужно уточнять, а не предполагать.
Отсюда практический вывод. Standalone — честное, простое и понятное решение для проекта, которому достаточно одного сервера и осознанного допущения, что при его отказе придётся восстанавливаться из копии. Replica set — другая инженерная задача со своей эксплуатацией, и называть её «таким же Atlas, только дешевле» неверно. Выбор между ними — это выбор допустимого поведения при поломке, а не вопрос вкуса.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации Россия, США, Франция и Великобритания. Оплата картой РФ и по СБП.
Допустимая остановка записи определяет способ переноса
Теперь главный практический рычаг: сколько времени приложение может не принимать записи. Это число определяет способ переноса сильнее, чем любые предпочтения по инструментам.
Если остановка допустима
Для каталога запчастей, где заказы приходят днём, а ночью их почти нет, самый простой и прозрачный путь — окно обслуживания. Приложение переводится в режим только чтения или временно останавливается, делается дамп, он загружается на VPS, создаются пользователи, проверяются индексы, затем в конфигурации меняется строка подключения. Данные за время выгрузки не расходятся, потому что никто их не меняет. Сложных механизмов синхронизации не нужно. Цена этого пути — время простоя, пропорциональное объёму базы и скорости канала между площадками, и его надо измерить на репетиции, а не оценивать на глаз.
Если остановить запись нельзя
Тогда дамп перестаёт быть снимком момента: пока он идёт, документы меняются. Опция oplog в mongodump призвана включать такие изменения, но её применимость определяется топологией и ограничениями команды, и на конкретном уровне Atlas она может быть недоступна. Если доступна, схема выглядит так: полная выгрузка с учётом изменений, восстановление на VPS, затем короткая остановка только для финального переключения. Если недоступна, остаются подходы уровня приложения: например, двойная запись или повторная досылка изменённых за время переноса документов по полю времени обновления. Это не функции из документации, а проектные решения, и их надёжность нужно проверять на вашем коде. Поле updated_at в каталоге позволило бы выбрать «всё, что менялось после начала выгрузки», но только если приложение действительно обновляет его при каждой записи — проверьте это, а не предполагайте.
В обоих случаях полезно заранее решить, что считать моментом необратимости. Пока приложение пишет в Atlas, отступить просто: вернуть прежнюю строку подключения. После того как первые заказы записаны на VPS, возврат к Atlas означает потерю или ручной перенос этих заказов. Поэтому порядок такой: репетиция на копии, затем переключение в окно с наименьшим потоком записей, затем наблюдение, и только после этого отключение старого источника. Старый кластер лучше не удалять, пока новый не прошёл полноценный рабочий цикл и не сделал свою первую проверенную резервную копию.
Рабочая репетиция: одна бизнес-операция целиком
Проверка «база запустилась» ничего не доказывает. Нужна одна бизнес-операция, проходящая через все слои. Для каталога это оформление заказа на товар с ограниченным остатком. Она читает документ по sku, проверяет остаток, уменьшает его и возвращает результат.
Составьте для неё короткий сценарий, исполняемый и на Atlas, и на новой площадке, и сравните поведение, а не только отсутствие ошибок:
- Подключение под учётной записью приложения, а не администратора. Если вход возможен только под административной записью, права настроены неверно.
- Чтение товара по артикулу. Сравните состав полей с ответом прежней базы.
- Уменьшение остатка. Убедитесь, что запись действительно прошла и остаток изменился на нужную величину.
- Попытка создать второй товар с существующим артикулом. Ожидаемое поведение — отказ по уникальному индексу.
- Список товаров категории. Оцените, не стал ли он заметно медленнее: это косвенная проверка индекса по категории.
Для вставки с дублем в оболочке достаточно простого примера; значения здесь условные:
db.products.insertOne({ sku: "BK-2041", title: "Тестовая позиция", price: 100, stock: 1, category: "parts" })Если команда выполнилась без ошибки при уже существующем артикуле, значит, уникальный индекс отсутствует, и дальше идти нельзя. Не забудьте удалить тестовую запись, если она всё же была создана.
Топология тоже проверяется этим сценарием. Если новая система — одиночный сервер, прогоните операции, которые в приложении опираются на поведение replica set, и убедитесь, что код не рассчитывает на то, чего больше нет. Если строите набор реплик, проверьте, как приложение ведёт себя при недоступности одного узла: это не доказывает «такую же надёжность, как в облаке», но показывает, что именно произойдёт у вас.
Какой сервер выбирать под репетицию и рабочую базу
Ресурсы тарифа — это отправная точка для размышления, а не гарантия ёмкости. В линейке VPS MAATRIX есть конфигурации от Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) и Uab (2 vCPU, 4 ГБ, 80 ГБ) до Heka (4 vCPU, 8 ГБ, 160 ГБ), Maat (8 vCPU, 16 ГБ, 240 ГБ) и Djed (16 vCPU, 32 ГБ, 320 ГБ). Выбор определяется не названием, а замерами: размер вашего набора данных вместе с индексами, рабочий набор, который должен помещаться в память, и нагрузка на запись. Для репетиции небольшого каталога хватит скромной конфигурации — это даже полезно, потому что быстро покажет, где узкое место. Для рабочей базы выбирайте после замера на копии ваших данных, а не по таблице.
Несколько практических соображений. Диск должен вмещать не только данные, но и дампы, которые вы будете делать, — иначе резервная копия вытеснит саму базу. Расположение сервера влияет на задержку между приложением и базой: если приложение остаётся у прежнего провайдера, а база уезжает в другую страну, каждый запрос получит добавку сетевой задержки. Среди локаций публичного предложения указаны UK, US, RU и FR; доступность конкретных образов и систем в каждой из них уточняйте в форме заказа. Оплата, по данным предложения, возможна картой РФ и через СБП, а сервер создаётся автоматически через пару минут после оплаты, поэтому пробный стенд для репетиции можно поднять быстро и не держать его дольше, чем нужно.
Доступ с правами root даёт полный контроль над установкой и настройкой, но вместе с ним приходит и ответственность за то, какие порты открыты наружу. Обычная разумная практика для базы данных — не выставлять её порт в общую сеть без необходимости, ограничивать подключения адресами приложения и включать аутентификацию. Конкретные шаги настройки описаны в статье о настройке MongoDB на VPS.
Параметры подключения: мелочь, на которой спотыкаются
Вернёмся к началу пути запроса. Строка подключения Atlas часто использует особый формат адреса, перечисляющий узлы кластера и включающий шифрование канала. При переезде на одиночный сервер строку нужно собрать заново: хост, порт, база аутентификации, режим шифрования. Если TLS на новом сервере не настроен, а в приложении он требуется, соединение не установится; если настроен самоподписанным сертификатом, драйвер потребует явно указать, чему доверять. Хорошая привычка — держать строку подключения в переменной окружения или секретах, а не в коде, чтобы переключение сводилось к смене одного значения и так же просто откатывалось.
Отдельно стоит просмотреть код на предмет жёстко прописанных имён: имя базы, имя коллекции, имя пользователя. Приложение, написанное под конкретный кластер, иногда хранит их в нескольких местах. Одна забытая копия старой строки — и часть запросов продолжит идти в Atlas, пока вы будете считать, что переключились. Простая проверка после переключения: посмотреть, прекратились ли подключения к старому кластеру. Если они продолжаются, вы нашли забытое место.
Кто заметит, что база упала
В управляемом сервисе у отказа есть адресат: платформа наблюдает за состоянием кластера и сама решает часть проблем. На собственном VPS этого адресата нет, пока вы его не назначите. Процесс mongod может остановиться из-за нехватки памяти, диск — заполниться дампами, сертификат — истечь, а приложение будет лишь выдавать ошибки соединения, не объясняя причин.
Поэтому к решению о переезде относятся вопросы, которые не видны в дампе. Кто получит сообщение, когда база перестанет отвечать, и в какое время суток? Где лежит последняя резервная копия, и пробовал ли кто-нибудь из неё восстановиться? Сколько времени займёт восстановление на этом же сервере и на новом, если старый не поднимется? Если на эти вопросы есть конкретные ответы с именами и сроками, переезд — взвешенный шаг. Если ответа нет, значит, вместе с документами вы переносите и пустое место там, где раньше стоял чужой дежурный. Кто теперь заметит отказ вашей базы и вернёт данные?