Home » Настройка replica set MongoDB на Ubuntu 24

Настройка replica set MongoDB на Ubuntu 24

Задача настроить replica set MongoDB на Ubuntu 24 может показаться сложной, но на самом деле это не так уж и страшно. Отказоустойчивость и масштабируемость – вот что нужно любому серьёзному проекту. Replica set обеспечивает автоматическую репликацию данных, быстрое восстановление после сбоев и распределение нагрузки при чтении. Если ваш проект растёт, и вы понимаете, что одного MongoDB-сервера уже недостаточно, то эта статья поможет вам развернуть надёжную архитектуру буквально за полчаса.

Как работает replica set MongoDB?

Replica set – это группа MongoDB-серверов, которые поддерживают одинаковый набор данных. Один сервер выступает как primary (главный), а остальные как secondary (дополнительные). Primary обрабатывает все операции записи, а secondary синхронизируются с ним автоматически. Если primary падает, один из secondary автоматически становится новым primary.

Минимальный replica set состоит из трёх узлов: один primary и два secondary. Почему именно три? Дело в алгоритме выбора нового primary – нужно большинство голосов. Три узла дают возможность выбрать новый primary даже если один из них недоступен.

Важная особенность: MongoDB использует oplog (operations log) для синхронизации. Это циклический журнал, который записывает все операции изменения данных. Secondary читают oplog с primary и применяют те же операции.

Пошаговая настройка replica set

Для начала нам понадобится минимум три сервера Ubuntu 24. Если тестируете локально, можно использовать виртуальные машины или контейнеры. Для продакшена рекомендую взять VPS или выделенный сервер.

Предположим, у нас есть три сервера с IP:

10.0.0.1 (mongo1)
10.0.0.2 (mongo2)
10.0.0.3 (mongo3)

Шаг 1: Установка MongoDB на все серверы

# Обновляем пакеты sudo apt update && sudo apt upgrade -y


# Устанавливаем зависимости

sudo apt install -y wget curl gnupg2 software-properties-common apt-transport-https ca-certificates lsb-release
# Добавляем ключ MongoDB

curl -fsSL https://pgp.mongodb.com/server-7.0.asc | sudo gpg -o /usr/share/keyrings/mongodb-server-7.0.gpg --dearmor
# Добавляем репозиторий

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/7.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list
# Обновляем список пакетов

sudo apt update

# Устанавливаем MongoDB sudo apt install -y mongodb-org

Шаг 2: Настройка конфигурации MongoDB

Редактируем файл /etc/mongod.conf на каждом сервере:

# /etc/mongod.conf


storage:

  dbPath: /var/lib/mongodb

  journal:

    enabled: true
systemLog:

  destination: file

  logAppend: true

  path: /var/log/mongodb/mongod.log
net:

  port: 27017

  bindIp: 0.0.0.0
processManagement:

  timeZoneInfo: /usr/share/zoneinfo
replication:

  replSetName: "rs0"

security: authorization: enabled

Шаг 3: Запуск MongoDB на всех серверах

# Запускаем и добавляем в автозагрузку sudo systemctl start mongod sudo systemctl enable mongod

# Проверяем статус sudo systemctl status mongod

Шаг 4: Инициализация replica set

Подключаемся к первому серверу и инициализируем replica set:

# Подключаемся к MongoDB mongosh --host 10.0.0.1:27017


# Инициализируем replica set

rs.initiate({

  _id: "rs0",

  members: [

    { _id: 0, host: "10.0.0.1:27017" },

    { _id: 1, host: "10.0.0.2:27017" },

    { _id: 2, host: "10.0.0.3:27017" }

  ]

})

# Проверяем статус rs.status()

Шаг 5: Создание административного пользователя

# Создаём root пользователя на primary use admin db.createUser({ user: "admin", pwd: "your_strong_password_here", roles: [ { role: "root", db: "admin" } ] })

# Проверяем аутентификацию db.auth("admin", "your_strong_password_here")

Практические примеры и кейсы

Сценарий	Решение	Результат
Primary сервер упал	Автоматический failover	Один из secondary становится primary (~10-30 секунд)
Нужно больше производительности чтения	Настройка read preference на secondary	Распределение нагрузки чтения
Обновление MongoDB	Rolling upgrade	Обновление без простоя
Резервное копирование	Бэкап с secondary узла	Нет нагрузки на primary

Пример настройки чтения с secondary:

# В приложении можно настроить чтение с secondary db.collection.find().readPref("secondary")

# Или установить для всего соединения rs.slaveOk()

Мониторинг replica set:

# Проверка статуса репликации rs.status()


# Проверка конфигурации

rs.conf()

# Проверка отставания реплик rs.printReplicationInfo() rs.printSlaveReplicationInfo()

Распространённые проблемы и их решения

Проблема 1: Сервер не может стать primary

Часто возникает из-за проблем с сетью или неправильной конфигурации. Проверьте:

Доступность портов между серверами
Правильность hostnames в конфигурации
Синхронизацию времени (установите ntp)

# Проверка доступности портов telnet 10.0.0.2 27017

# Установка ntp sudo apt install -y ntp sudo systemctl enable ntp

Проблема 2: Высокий replication lag

Если secondary сильно отстают от primary, проверьте:

Пропускную способность сети
Производительность дисков
Размер oplog

# Изменение размера oplog use local db.runCommand({replSetResizeOplog: 1, size: 16384}) # 16GB

Расширенные возможности и автоматизация

Arbiter для экономии ресурсов:

Если нужно сэкономить на серверах, третий узел можно сделать arbiter’ом. Он участвует только в голосовании, но не хранит данные.

# Добавление arbiter rs.addArb("10.0.0.3:27017")

Приоритеты узлов:

Можно настроить приоритеты, чтобы контролировать, какой сервер станет primary:

# Изменение приоритета cfg = rs.conf() cfg.members[0].priority = 2 # Высокий приоритет cfg.members[1].priority = 1 # Средний приоритет cfg.members[2].priority = 0 # Не может стать primary rs.reconfig(cfg)

Автоматизация с помощью Ansible:

Для автоматизации развёртывания replica set отлично подходит Ansible. Создайте playbook, который автоматически настроит все серверы.

Мониторинг с помощью Prometheus:

Используйте mongodb_exporter для интеграции с Prometheus и Grafana.

Сравнение с альтернативами

Решение	Преимущества	Недостатки
MongoDB Replica Set	Автоматический failover, простота настройки	Только один primary для записи
MongoDB Sharding	Горизонтальное масштабирование записи	Сложность настройки и управления
PostgreSQL Streaming Replication	ACID транзакции, SQL	Более сложная настройка автоматического failover
MySQL Master-Slave	Зрелое решение, много инструментов	Ручной failover, проблемы с консистентностью

Интересные факты и нестандартные способы использования

Hidden members: Можно создать скрытый узел, который не участвует в обслуживании клиентов, но реплицирует данные. Идеально для аналитики:

cfg = rs.conf() cfg.members[2].hidden = true cfg.members[2].priority = 0 rs.reconfig(cfg)

Delayed members: Узел с задержкой репликации – отличная защита от ошибок администратора:

cfg = rs.conf() cfg.members[2].slaveDelay = 3600 # 1 час задержки cfg.members[2].priority = 0 cfg.members[2].hidden = true rs.reconfig(cfg)

Интеграция с Docker Swarm:

MongoDB replica set отлично работает в Docker Swarm с использованием именованных сетей. Это позволяет легко масштабировать и управлять кластером.

Использование с Kubernetes:

Оператор MongoDB для Kubernetes автоматически управляет replica set, включая backup, monitoring и scaling.

Производительность и оптимизация

По статистике MongoDB, правильно настроенный replica set может обеспечить:

RTO (Recovery Time Objective) менее 30 секунд
RPO (Recovery Point Objective) менее 1 секунды
Увеличение производительности чтения в 2-3 раза

Настройка для максимальной производительности:

# Оптимизация для SSD echo 'never' | sudo tee /sys/kernel/mm/transparent_hugepage/enabled echo 'never' | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

# Увеличение лимитов echo 'mongod soft nofile 64000' | sudo tee -a /etc/security/limits.conf echo 'mongod hard nofile 64000' | sudo tee -a /etc/security/limits.conf

Безопасность replica set

Настройка SSL/TLS:

# Генерация сертификатов openssl req -newkey rsa:2048 -new -x509 -days 365 -nodes -out mongodb-cert.crt -keyout mongodb-cert.key cat mongodb-cert.key mongodb-cert.crt > mongodb.pem

# Настройка в mongod.conf net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem

Аутентификация между узлами:

# Создание keyfile openssl rand -base64 756 > /etc/mongodb-keyfile chmod 400 /etc/mongodb-keyfile chown mongod:mongod /etc/mongodb-keyfile

# Добавление в конфигурацию security: keyFile: /etc/mongodb-keyfile

Заключение и рекомендации

Replica set MongoDB – это must-have для любого серьёзного проекта. Настройка занимает максимум час, но даёт кратное увеличение надёжности и производительности системы. Основные рекомендации:

Используйте нечётное количество узлов – это гарантирует корректную работу алгоритма выбора primary
Размещайте узлы в разных датацентрах – это защитит от локальных сбоев
Настройте мониторинг – отслеживайте состояние replica set и replication lag
Регулярно тестируйте failover – убедитесь, что система корректно переключается
Используйте SSD диски – это критично для производительности oplog

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

Replica set решает 90% задач по отказоустойчивости MongoDB. Если нужно горизонтальное масштабирование записи, следующим шагом будет изучение sharding. Но для большинства проектов replica set – это именно то, что нужно для спокойного сна.

В этой статье собрана информация и материалы из различных интернет-источников. Мы признаем и ценим работу всех оригинальных авторов, издателей и веб-сайтов. Несмотря на то, что были приложены все усилия для надлежащего указания исходного материала, любая непреднамеренная оплошность или упущение не являются нарушением авторских прав. Все упомянутые товарные знаки, логотипы и изображения являются собственностью соответствующих владельцев. Если вы считаете, что какой-либо контент, использованный в этой статье, нарушает ваши авторские права, немедленно свяжитесь с нами для рассмотрения и принятия оперативных мер.

Данная статья предназначена исключительно для ознакомительных и образовательных целей и не ущемляет права правообладателей. Если какой-либо материал, защищенный авторским правом, был использован без должного упоминания или с нарушением законов об авторском праве, это непреднамеренно, и мы исправим это незамедлительно после уведомления. Обратите внимание, что переиздание, распространение или воспроизведение части или всего содержимого в любой форме запрещено без письменного разрешения автора и владельца веб-сайта. Для получения разрешений или дополнительных запросов, пожалуйста, свяжитесь с нами.