MongoDB шардинг на CentOS 7

Этот подробный пошаговый гид показывает, как развернуть шардированный кластер MongoDB на CentOS 7: настроить config-сервера, шарды (репликационные наборы), mongos роутер, включить шардинг базы и коллекций, протестировать вставку данных и подготовиться к эксплуатации. Приведены чеклисты для ролей, советы по выбору shard key, безопасность, откат и тесты приёмки.

Что такое шардинг

Sharding — это метод горизонтального масштабирования MongoDB, при котором набор данных разбивается на части (чанки) и хранится на разных машинах (шардах). Каждый шар обычно реализуется как репликационный набор для высокой доступности. Ключ шарда (shard key) определяет, как документ распределяется по шардам.

Кратко:

Шард хранит данные и в продакшне обычно является репликационным набором.
Config-сервер хранит метаданные кластера (маппинг чанков и шардов).
mongos — маршрутизатор запросов, через который работают приложения.

Определение термина: shard key — поле(я) в документе, используемые для распределения и маршрутизации данных по шардом.

Шардирование и репликация

Простая аналогия: шардинг — это разнесение музыкальной коллекции по разным папкам на разных серверах; репликация — синхронизация одной папки между копиями для отказоустойчивости.

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

Компоненты шардинга

Shard — хранит фрагменты данных; в продакшне каждый shard — репликационный набор.
Config Server — хранит метаданные кластера; рекомендуется иметь нечётное число config-серверов (минимум 3 в продакшне).
mongos/Query Router — интерфейс, к которому подключается приложение; маршрутизирует запросы к шардам с учётом метаданных.

Модель принятия решения: стоит ли шардировать

Mermaid схема для выбора (решение: шардинг или нет):

flowchart TD
  A[Требования по объёму и производительности] --> B{Данные превышают ресурс одного узла?}
  B -- Да --> C{Рабочая нагрузка требует параллельной записи/чтения?}
  B -- Нет --> D[Нет шардирования]
  C -- Да --> E[Рассмотреть шардинг]
  C -- Нет --> F[Вертикальная масштабируемость или Caching]

Альтернативные подходы

Вертикальное масштабирование (более мощный сервер) — простое, но быстро достигает предела.
Горизонтальная партиция на уровне приложения — простейшая форма шардинга, но переносит сложность в код.
Менеджерированные сервисы (например, MongoDB Atlas) — снижает операционную нагрузку.

Когда шардинг может не подойти:

Небольшие базы (<несколько десятков ГБ) с умеренной нагрузкой.
Сильно связанных данных, где запросы часто требуют чтения из нескольких партиций.

Факторы выбора shard key — эвристики

Избегайте поля с высокой частотой одинаковых значений (низкая картина). Это приведёт к «горячим» шардам.
Предпочтите поле с равномерным распределением по Cardinality.
Для диапазонных запросов используйте композицию: {userId, createdAt} при необходимости.
Для равномерных вставок хороши хешированные ключи; но хеширование ухудшает эффективность диапазонных запросов.

Краткая шпаргалка: cardinality > write shards > query patterns.

Требования и подготовка

Пример окружения, локальные IP — сохранены из оригинального примера (используются в командах):

configsvr1 — 10.0.15.31
configsvr2 — 10.0.15.32
shardsvr1 — 10.0.15.21
shardsvr2 — 10.0.15.22
shardsvr3 — 10.0.15.23
shardsvr4 — 10.0.15.24
mongos — 10.0.15.11

Привилегии: root доступ на всех серверах, стабильная сеть между узлами.

Важная заметка: пример использует MongoDB 3.4 в репозитории. Это старая версия — при внедрении в продакшн рекомендовано использовать поддерживаемые версии MongoDB и проверять совместимость между версиями.

Подготовка окружения

Отключите SELinux (в учебных/тестовых средах). В продакшне рассмотрите настройку правил SELinux вместо полного отключения.
Настройте /etc/hosts на всех узлах, чтобы каждый хост разрешался по имени.

Пример /etc/hosts (вставьте на каждой машине):

    10.0.15.31      configsvr1
    10.0.15.32      configsvr2
    10.0.15.11      mongos
    10.0.15.21      shardsvr1
    10.0.15.22      shardsvr2
    10.0.15.23      shardsvr3
    10.0.15.24      shardsvr4

Рестарт узлов после изменения SELinux/hosts:

reboot

Установка MongoDB на все инстансы

Пример занесения репозитория и установки MongoDB 3.4 на CentOS 7:

cat <<'EOF' >> /etc/yum.repos.d/mongodb.repo
[mongodb-org-3.4]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.4/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.4.asc
EOF

sudo yum -y install mongodb-org

mongod --version

Install MongoDB on All Instances

ALT текста изображения: Установка MongoDB на все инстансы — вывод установки и проверка версии.

Примечание: для продакшна используйте официальную документацию по установке конкретной версии и репозиторий соответствующей ветки.

Шаг 1 — Отключение SELinux и настройка хостов

Подключитесь к каждому узлу по SSH и выполните правки /etc/sysconfig/selinux, поменяйте SELINUX=enforcing на SELINUX=disabled (после изменений требуется перезагрузка).

Подключение:

ssh root@SERVERIP

Редактирование файла:

vim /etc/sysconfig/selinux

# Убедитесь, что строка имеет вид
SELINUX=disabled

Редактирование /etc/hosts — вставьте список, показанный ранее.

Перезапустите узлы.

Шаг 2 — Установка MongoDB на все инстансы

Следуйте инструкции из раздела выше. Убедитесь, что на каждом узле после установки команда mongod --version показывает установленную версию.

Проверьте, что сервис mongod не запущен автоматически, если вы будете запускать его вручную с конфигом.

Шаг 3 — Создание Config Server Replica Set

Config-сервера хранят метаданные кластера. В примере используются два config-сервера, но в продакшне минимум 3.

На каждой машине configsvr1 и configsvr2 выполните:

systemctl stop mongod
vim /etc/mongod.conf

В файле конфигурации измените dbPath, bindIP, replication и sharding разделы. Пример для configsvr1:

storage:
  dbPath: /data/db1

net:
  bindIp: 10.0.15.31

replication:
  replSetName: "replconfig01"

sharding:
  clusterRole: configsvr

Создайте директорию данных и установите владельца:

mkdir -p /data/db1
chown -R mongod:mongod /data/db1

Запустите mongod (в режиме config server):

mongod --config /etc/mongod.conf

Проверьте процесс и порт:

netstat -plntu

Create Config Server Replica Set

ALT текста изображения: Настройка конфигурационных серверов — проверка сетевых сокетов и запущенного mongod.

Инициируйте репликационный набор на одном из config-серверов (configsvr1):

ssh root@configsvr1
mongo --host configsvr1 --port 27017

rs.initiate(
  {
    _id: "replconfig01",
    configsvr: true,
    members: [
      { _id : 0, host : "configsvr1:27017" },
      { _id : 1, host : "configsvr2:27017" }
    ]
  }
)

Если возвращается { "ok" : 1 } — конфигурация прошла успешно.

Проверьте состояние:

rs.isMaster()
rs.status()

Initiate the replica set name with all configsvr members

ALT текста изображения: Инициализация репликационного набора конфиг-серверов и вывод состояния.

Шаг 4 — Создание Shard Replica Sets

В примере мы создаём два шарда, каждый как репликационный набор из двух узлов.

Для shardsvr1 и shardsvr2 (shardreplica01):

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

systemctl stop mongod
vim /etc/mongod.conf

Пример изменений для shardsvr1 (IP 10.0.15.21):

storage:
  dbPath: /data/db1

net:
  bindIp: 10.0.15.21

replication:
  replSetName: "shardreplica01"

sharding:
  clusterRole: shardsvr

Создайте директорию данных и запустите mongod:

mkdir -p /data/db1
chown -R mongod:mongod /data/db1

mongod --config /etc/mongod.conf

Проверьте слушающие порты:

netstat -plntu

Повторите для shardsvr2 с bindIp 10.0.15.22 и тем же replSetName.

Инициализируйте репликационный набор на shardsvr1:

ssh root@shardsvr1
mongo --host shardsvr1 --port 27017

rs.initiate(
  {
    _id : "shardreplica01",
    members: [
      { _id : 0, host : "shardsvr1:27017" },
      { _id : 1, host : "shardsvr2:27017" }
    ]
  }
)

Проделайте аналогичные действия для shardsvr3/shardsvr4 с replSetName “shardreplica02”.

Create Shard Replica Sets

ALT текста изображения: Создание репликационных наборов для шардов, вывод состояния и подключений.

Шаг 5 — Настройка mongos роутера

На сервере mongos остановите системный mongod (если запущен):

ssh root@mongos
systemctl stop mongod

Запустите mongos, указывая репликацию конфиг-сервера:

mongos --configdb "replconfig01/configsvr1:27017,configsvr2:27017"

В ответ вы увидите подтверждение подключения к config серверам.

Configure mongos/Query Router

ALT текста изображения: Запуск mongos и подключение к config-серверам, вывод успешного соединения.

В продакшне указывайте 3 config сервера и запускайте mongos как системную службу с конфигурационным файлом.

Шаг 6 — Добавление шардов в mongos

Подключитесь к mongo shell на mongos и добавьте шард-реплики:

ssh root@mongos
mongo --host mongos --port 27017

sh.addShard("shardreplica01/shardsvr1:27017")
sh.addShard("shardreplica01/shardsvr2:27017")

sh.addShard("shardreplica02/shardsvr3:27017")
sh.addShard("shardreplica02/shardsvr4:27017")

sh.status()

Проверьте, что sh.status() показывает добавленные шарды.

Add shards to mongos/Query Router

ALT текста изображения: Добавление шардов в кластер через mongos и вывод статуса sh.status().

Шаг 7 — Тестирование

Подключитесь к mongos и включите шардинг для базы данных:

ssh root@mongos
mongo --host mongos --port 27017

use lemp
sh.enableSharding("lemp")
sh.status()

Включите шардинг для коллекции и укажите shard key:

sh.shardCollection("lemp.stack", {"name":1})
sh.status()

Enable sharding.

ALT текста изображения: Включение шардинга для базы и коллекции, вывод sh.status().

Вставьте документ с shard key:

db.stack.save({
    "name": "LEMP Stack",
    "apps": ["Linux", "Nginx", "MySQL", "PHP"],
})

Подключитесь к primary одного из shard реплик и проверьте наличие данных:

ssh root@shardsvr2
mongo --host shardsvr2 --port 27017

show dbs
use lemp
db.stack.find()

Если данные видны — тест пройден.

Enable Sharding for Collections

ALT текста изображения: Коллекция ‘stack’ добавлена в шардинг; вывод результатов.

Критерии приёмки

Все узлы доступны по именам из /etc/hosts.
Config-сервера сформировали replica set и возвращают ok в rs.status().
Каждый shard оформлен как replica set и имеет PRIMARY/SECONDARY статусы.
mongos успешно подключается к config-серверам и видит добавленные шарды (sh.status()).
При вставке документов через mongos данные сохраняются и доступны через реплики.

Чеклисты по ролям

Системный администратор:

Настроить сетевую доступность и firewall между узлами.
Проверить права пользователя mongod и владельца директорий данных.
Настроить мониторинг и бэкапы.

Базы данных/DBA:

Подобрать shard key по паттернам запросов.
Проверить распределение чанков после загрузки данных.
Настроить резервирование и ротацию логов.

Разработчик приложения:

Убедиться, что все запросы идут через mongos.
Не использовать исключительно non-shardable запросы, если это критично.
Протестировать запросы с учётом shard key для оптимальной маршрутизации.

Бэкап, восстановление и откат

Резервные стратегии:

Logical dump: mongodump/mongorestore — удобно для миграций и небольших БД.
Snapshot уровня тома (LVM, ZFS) — быстрый полный бэкап с учётом согласованности на первичном экземпляре.

Откат схемы шардинга: удаление шарда — потенциально дорогая операция, требующая перемещения чанков: sh.removeShard(). Всегда тестируйте процедуру на стейджинге.

Инцидентный план (runbook):

При падении primary в replica set — rs.stepDown() или дождаться автоматического выбора нового primary.
При потере сети между шардами — проверить сетевые маршруты, firewall, MTU, DNS.
При повреждении данных — восстановление из последней корректной резервной копии, проверка целостности.

Мониторинг и SLI/SLO

Базовые метрики для мониторинга:

Нагрузка CPU и память на mongod и mongos.
Длительность операций: opcounters, opLatencies.
Размеры данных и индексная нагрузка per shard.
Балансировка чанков: количество чанков на шардах.

SLO примеры (качественные):

Доступность mongos: 99.9% (оперативное переключение при сбоях).
Время отклика 95-percentile < 200 ms для целевых API.

Тесты и приёмочные сценарии

Тесты для проверки корректности развертывания:

Проверка rs.status() на каждом репликационном наборе.
Выполнение sh.status() и проверка, что все шарды видны.
Массовая загрузка тестовых данных с равномерным распределением shard key — проверить распределение чанков.
Проверка failover: выключаем primary в шард-реплике и убеждаемся, что secondary становится primary.

Критерии приёмки:

Данные равномерно распределены по шардам по выбранному shard key.
Резервное копирование работает и восстановление тестировалось на стенде.
Мониторинг оповещает о задержках репликации и росте диска.

Отладка и распространённые ошибки

Не добавляется шард — проверьте доступность узлов и совпадение replSetName.
mongos не подключается к config серверам — проверьте параметры –configdb и доступ по сети.
Чанки сосредоточены на одном шарде — вероятно выбран неравномерный shard key; рассмотрите ребалансировку или выбор другого ключа.

Полезные команды:

rs.status()
sh.status()
db.collection.getShardDistribution()

Совместимость и миграция

MongoDB 3.4 устарела. При планировании продакшна рассмотреть переход на поддерживаемую ветку. При обновлении кластеров соблюдайте порядок: сначала config-сервера, затем шарды, затем mongos.
Тестируйте миграцию на тестовом окружении, особенно если используются устаревшие драйверы клиентов.

Сводка и рекомендации

Важно тщательно выбирать shard key и иметь политику резервного копирования и мониторинга. Для продакшна используйте минимум три config-сервера и как минимум два/три узла в репликационном наборе для отказоустойчивости. Рассмотрите менеджерированные сервисы, если операционная нагрузка высока.

Короткая приёмная памятка:

Настройте сеть и /etc/hosts.
Установите MongoDB и настройте mongod для каждого типа ролей (configsvr, shardsvr).
Инициализируйте replica set для config и shard узлов.
Запустите mongos и добавьте шарды.
Включите шардинг базы и коллекции, укажите корректный shard key.