MongoDB – популярная документо-ориентированная СУБД, для которой не требуется описывать и создавать схемы. Обычно используется в разработке веб приложений, но не только – там, где NoSQL система может быть полезнее и эффективнее реляционной СУБД.
В процессе разработки и тестирования приложения, часто бывает достаточно одного сервера для работы СУБД.
Перед началом использования приложения в рабочей (продуктивной) среде, необходимо определить – какие риски могут возникнуть в ситуации, когда все данные хранятся на одном сервере.
Если данные не критичны (например, это кэшированные данные), приложение продолжит функционировать без них на приемлемом уровне, и время на восстановление работы БД предполагается относительно небольшим – тогда можно сделать вывод, что одного сервера достаточно.
Если данные критичны, их потеря или недоступность (например, в результате инцидента с сетью) влияет на функционирование приложения (а следовательно, и на предоставляемый сервис клиентам) – в этом случае рекомендуется использование кластера для хранения данных.
MongoDB позволяет настроить два вида кластера:
- Replica set: группа серверов, которые хранят один и тот же набор данных. Надежность хранения обеспечивается репликацией данных между серверами.
- Sharded cluster: распределение наборов данных между серверами, т.е. горизонтальное масштабирование.
Для работы вам может пригодиться инструкция по установке MongoDB на Ubuntu. Далее описывается процесс настройки кластера replica set.
Replica set — роли серверов
Для кластера необходимо минимум три сервера MongoDB:
- Первичный (primary), выполняет все запросы на чтение и запись в БД от приложения. Все операции по изменению данных записываются в специальную коллекцию «oplog» (operation log) – она используется для репликации этих изменений на вторичные серверы.
- Вторичный (secondary), реплицирует коллекцию oplog, и применяет все имеющиеся операции из этой коллекции по изменению данных. Этим и обеспечивается идентичность данных на всех серверах кластера. Минимально требуется два вторичных сервера.
Схематичное изображение:
Replica set – конфигурирование
Описание серверов для примера настройки:
- Первичный сервер: имя – server1, IP 10.20.30.10;
- Вторичный сервер: имя – server2, IP 10.20.30.20;
- Вторичный сервер: имя – server3, IP 10.20.30.30.
Имена серверов и их IP адреса необходимо заменить на реальные.
Перед настройкой кластера необходимо:
- Установить MongoDB на все серверы;
- Разрешить в правилах firewall подключение между серверами для порта 27017;
- Настроить разрешение имен серверов: если DNS сервер отсутствует, то добавить на каждом сервере записи в /etc/hosts в виде:
10.20.30.10 server1.domain.local server1
10.20.30.20 server2.domain.local server2
10.20.30.30 server3.domain.local server3Важно: все дальнейшие команды для настройки должны содержать только имена серверов! Начиная с версии 5.0 не допускается использование IP адресов – MongoDB проверяет их наличие в конфигурации, и не запустится если они присутствуют.
Настройка кластера
1. Запустить на каждом сервере MongoDB:
mongod --replSet “rs0” –bind_ip localhost,server_name«rs0» – название реплики.
server_name – имя сервера, на котором запускается MongoDB.
2. На первичном сервере запустить командную оболочку mongo (используя свои учетные данные вместо username и password):
mongo -u username -p password3. В оболочке mongo инициализировать репликацию и добавить все серверы в кластер:
rs.initiate( {
_id: “rs0”,
members: [
{ _id: 0, host: “server1.domain.local:27017” },
{ _id: 1, host: “server2.domain.local:27017” },
{ _id: 2, host: “server3.domain.local:27017” },
]
})На других серверах эти действия выполнять не требуется.
4. Проверить настройки репликации командой rs.conf() – в выводе команды отображаются параметры каждого сервера. Для первичного сервера:
{
"_id" : "rs0",
"version" : 1,
"protocolVersion" : NumberLong(1),
"members" : [
{
"_id" : 0,
"host" : "server1. domain.local:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},5. Можно заметить, что для каждого сервера установлен приоритет по умолчанию – 1: строка «priority: 1».
Значение приоритета используется в процессе голосования: чем ниже значение, тем выше вероятность быть выбранным первичным сервером.
Можно заранее определить какой из вторичных серверов будет выбран следующим первичным такими командами:
conf = rs.conf()
conf[‘members’][0].priority = 1
conf[‘members’][1].priority = 2
conf[‘members’][2].priority = 3
rs.reconfig(conf)Таким образом:
- server1 всегда будет первичным;
- server2 будет выбран следующим первичным если server1 недоступен;
- server3 – останется единственным в кластере и станет первичным если server1 и server2 недоступны.
6. Проверить статус репликации командой “rs.status()”. Необходимо проверить наличие всех серверов в выводе команды, и состояние каждого сервера (строка “stateStr”).
Пример для первичного сервера:
"members" : [
{
"_id" : 0,
"name" : "server1:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 87986,
"optime" : {
"ts" : Timestamp(1526936047, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2023-03-29T12:54:07Z"),
"electionTime" : Timestamp(1526848104, 1),
"electionDate" : ISODate("2018-03-29T12:28:24Z"),
"configVersion" : 3,
"self" : true
},Значение для “stateStr” – “PRIMARY”, т.е. server1 действительно первичный.
Для вторичного сервера server2:
{
"_id" : 0,
"name" : "server2:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 97453,
"optime" : {
"ts" : Timestamp(1526936047, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2023-03-29T12:54:07Z"),
"electionTime" : Timestamp(1526848104, 1),
"electionDate" : ISODate("2018-03-29T12:28:24Z"),
"configVersion" : 3,
"self" : true
},«stateStr» – «SECONDARY», т.е. server2 действительно присутствует в кластере как вторичный.
Аналогичный вывод должен быть и для server3.
По умолчания серверы отслеживают состояние друг друга раз в 10 секунд (значение можно поменять на более подходящее).
Как было отмечено ранее – при недоступности первичного сервера запустится процесс голосования.
В соответствии с приоритетом, server2 станет первичным – это можно увидеть в выводе «rs.status()», значение «stateStr» изменится с «SECONDARY» на «PRIMARY».
Для server1 в выводе значение “stateStr” изменится на «(not reachable/healthy)». После того как server1 опять станет доступным, данные будут реплицированы с server2, и после этого запустится голосование – server1 опять станет первичным.
Наличие кластера позволяет также выполнять плановые работы на любом сервере без остановки приложения, так как критичные данные останутся доступными.
Заключение
Этих действий достаточно для простой настройки кластера replica set.
MongoDB предусматривает более сложные конфигурации, в том числе можно использовать сочетание replica set и sharding.
Примеры таких конфигураций будут рассмотрены в следующих статьях.
