Кластеризация MongoDB: как развернуть реплики на нескольких серверах

Содержание

В статье объяснили, как настроить Replica Set в MongoDB: подготовить серверы, объединить их в кластер, включить репликацию и проверить отказоустойчивость.

Введение

Когда MongoDB работает на одном сервере, всё кажется простым и понятным. Есть база, есть коллекции, всё крутится и отвечает. Но стоит приложению начать расти, как появляются задержки, ошибки, странные падения и вечный вопрос: что делать, если сервер вдруг откажет. Даже самый надёжный хостинг не спасает от сбоев, а потерянные данные — это не шутка. Особенно если база развернута на VPS: сбой одной виртуалки может парализовать всю систему. Рассказали, как настроить кластер из нескольких MongoDB, чтобы база продолжала работать, даже если один из серверов отключился. Показали, как включить репликацию, настроить Replica Set, проверить отказоустойчивость и не запутаться в настройке.

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.

Зачем реплицировать MongoDB

Одна MongoDB на одном сервере — это как рабочий ноутбук без бекапа. Пока всё в порядке, проблем нет. Но если что-то сломается, остановится всё приложение, а восстановление может занять часы или даже не случиться вовсе. Репликация помогает избежать этого сценария. Это способ создать несколько копий базы, которые синхронизируются между собой и могут заменить друг друга при необходимости.

Основная идея простая: есть один основной узел, куда идут все записи, и есть один или несколько вторичных, которые получают эти записи почти в реальном времени. Если основной сервер отключится, один из вторичных возьмёт управление на себя.

Репликация полезна не только для отказоустойчивости. Вторичные узлы можно использовать для чтения данных, не нагружая основной. Это особенно удобно, если база активно используется в отчётах, бэкенде или для аналитики. В крупных проектах такой подход позволяет распределить нагрузку и ускорить отклик.

Репликация создаёт копии в реальном времени. Даже если один сервер полностью потеряет данные, копии останутся. Это не заменяет резервное копирование, но даёт дополнительный уровень защиты, который спасает от большинства типичных аварий.

Что такое Replica Set и как он работает

Replica Set — это группа серверов MongoDB, которые вместе работают как единая база. Один узел считается основным, остальные — копиями. Основной принимает все изменения: записи, обновления, удаления. Вторичные просто следят за ним и копируют всё, что он делает. Это не отдельные базы, а точные зеркала, которые всегда в курсе, что происходит на главном узле.

Если основной сервер падает, кластер не зависает. Replica Set сам проводит голосование, выбирает нового главного и продолжает работу. Приложение даже не замечает, что что-то произошло. Такой механизм называется failover, и именно он делает MongoDB пригодной для серьёзных задач.

Внутри всё устроено довольно понятно. Каждый узел регулярно отправляет другим послание: «я здесь, жив». Если один из них вдруг перестаёт отвечать, остальные договариваются, кто теперь будет основным. Это занимает несколько секунд, но этого хватает, чтобы сервис остался на плаву. Всё это происходит автоматически. Вам не нужно нажимать кнопку или перезапускать кластер, система справляется сама.

Кроме обычных узлов, в Replica Set можно добавить арбитр. Это сервер, который не хранит данные, а нужен только для голосования. Он помогает принять решение, когда есть чётное количество участников.

Подготовка серверов для кластера

Перед тем как запускать Replica Set, нужно подготовить серверы. Обычно это минимум три узла: один основной и два вторичных. Можно взять больше, но важно, чтобы общее число было нечётным — это упростит выбор нового основного в случае сбоя. Каждый сервер должен быть доступен по локальной или публичной сети и уметь общаться с другими участниками.

MongoDB можно ставить как на физические, так и на виртуальные машины. Если вы только выбираете хостинг, обратите внимание на серверы AdminVPS — здесь можно быстро поднять несколько серверов с нужной версией Ubuntu и стабильной сетевой связью между инстансами. Это упрощает отладку, настройку DNS и проверку связности кластера.

На каждом узле нужна одинаковая версия MongoDB. Лучше брать стабильную LTS-ветку. Для установки на Ubuntu сначала обновите пакеты и подключите официальный репозиторий MongoDB:

sudo apt update
sudo apt install gnupg curl
curl -fsSL https://pgp.mongodb.com/server-6.0.asc | \
sudo gpg -o /usr/share/keyrings/mongodb-server-6.0.gpg --dearmor

echo "deb [ signed-by=/usr/share/keyrings/mongodb-server-6.0.gpg ] \
https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/6.0 multiverse" | \
sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list

sudo apt update
sudo apt install -y mongodb-org

Убедитесь, что сервис MongoDB запускается:

sudo systemctl start mongod
sudo systemctl enable mongod

И проверьте статус:

sudo systemctl status mongod

MongoDB должна слушать соединения на порту 27017. Если используется файрвол, порт должен быть открыт на всех узлах внутри кластера. Используйте ufw allow 27017 или настройку iptables, если это требуется вашей инфраструктурой.

Важно, чтобы все серверы видели друг друга по имени. Можно прописать IP-адреса в /etc/hosts или настроить внутренний DNS, если работаете в рамках одной сети. Имена должны быть одинаковыми на всех участниках, чтобы MongoDB могла собирать конфигурацию без сюрпризов.

Как развернуть Replica Set в MongoDB

Когда MongoDB установлена на всех серверах, можно запускать Replica Set. Это значит — объединить узлы в один логически связанный кластер, где есть главный, вторичные и, при необходимости, посредник. Все действия выполняются из консоли mongo, подключённой к любому из участников.

Сначала настройте конфигурационный файл mongod.conf на каждом узле. Найдите или добавьте блок replication и задайте имя Replica Set:

replication:
  replSetName: rs0

Сохраните файл и перезапустите сервис:

sudo systemctl restart mongod

Теперь подключитесь к первому серверу:

mongo --host 127.0.0.1

Инициализируйте Replica Set:

rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongo1.example.com:27017" },
    { _id: 1, host: "mongo2.example.com:27017" },
    { _id: 2, host: "mongo3.example.com:27017" }
  ]
})

Адреса здесь должны совпадать с теми, по которым серверы видят друг друга. Если в конфиге mongod.conf настроен bindIp, убедитесь, что IP-адреса разрешают входящие соединения на 27017.

Через несколько секунд Replica Set поднимется.

Если нужно добавить узел позже, используйте команду:

rs.add("mongo4.example.com:27017")

MongoDB сама подключит его и начнёт репликацию. Также можно задать приоритеты, ограничить узлы только для чтения или назначить арбитра, если требуется экономия ресурсов.

Как проверить и протестировать кластер

Когда Replica Set настроен, важно убедиться, что всё действительно работает как кластер, а не просто набор независимых серверов. Проверка начинается с подключения к любому из узлов через mongo и выполнения команды:

rs.status()

Вывод покажет список участников, их роли, приоритеты, состояние синхронизации и лаги. Главный узел будет помечен как PRIMARY, остальные — SECONDARY. Это значит, что запись идёт только на один сервер, а остальные получают изменения автоматически.

Теперь отключите главный узел. Можно просто выключить сервис mongod или перезагрузить машину. Через несколько секунд один из вторичных должен стать новым PRIMARY. Повторная команда rs.status() на другом узле покажет это. Это нормальное поведение: Replica Set сам выбирает нового лидера, чтобы продолжать работу без сбоев.

Подключитесь к кластеру с клиента, например, через MongoDB Compass или любой драйвер, и выполните запрос на запись. Если всё настроено правильно, запись пройдёт даже после смены главного узла. Это и есть отказоустойчивость в действии.

Также проверьте репликацию. Добавьте запись в базу на главном сервере, потом выполните db.collection.find() на вторичном. По умолчанию чтение со вторичных запрещено, но можно разрешить его временно:

rs.slaveOk()

Это покажет, что данные успешно передаются и сохраняются. Если задержка небольшая, кластер работает стабильно.

Для дополнительного контроля стоит настроить мониторинг. MongoDB умеет передавать метрики в Prometheus, а для базовой отладки можно использовать встроенные команды — rs.printReplicationInfo(), rs.printSlaveReplicationInfo(), db.serverStatus().

Заключение

С Replica Set нет единой точки отказа, данные дублируются, чтение можно распределить между серверами. При этом всё работает автоматически: если один узел отключится, другой его подменит.

Даже в небольших проектах такой подход помогает избежать потерь. А при масштабировании он становится основой стабильной архитектуры. Главное правильно всё настроить и не забывать проверять, как ведёт себя кластер при сбоях.

MongoDB не требует огромных усилий, чтобы начать работать как кластер. Нужно просто пройти настройку один раз, и дальше всё будет под контролем.

Читайте в блоге: