Настройка репликации MongoDB на сервере Ubuntu

Published by Leave your thoughts

MongoDB – это очень популярная база данных NoSQL, используемая для хранения и управления информацией сайта или приложения. Среди преимуществ MongoDB стоит выделить простое масштабирование, удобный формат данных и динамическую разработку схем.

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

Примечание: Нужно предварительно установить MongoDB; инструкции по установке можно найти в следующих статьях:

Что такое сеты MongoDB?

MongoDB обрабатывает репликацию при помощи так называемых сетов, или наборов реплик (англ. «replication sets»). Наборы реплик – это, по сути, те же ноды, которые используются в настройке master-slave; то есть, один член набора становится основным и далее используется в качестве ведущего при синхронизации настроек остальных членов.

Разница между наборами реплик и репликацией master-slave состоит в том, что наборы реплик используют встроенный автоматический механизм переключения в случае сбоя ведущего члена.

Первичный член (или узел) – это точка доступа для взаимодействия с набором реплик; это единственный узел, который может выполнять операции записи.

Каждый набор реплик может иметь только один первичный узел, поскольку репликация происходит путем копирования логов операций (oplog) первичного узла и изменения вторичных узлов согласно полученным данным. Наличие нескольких первичных узлов приведёт к конфликтам данных.

Вторичные узлы – это узлы набора реплик, подчиняющиеся первичному узлу. Каждый набор реплик может иметь несколько вторичных узлов одновременно.

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

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

Арбитр – это дополнительный член набора реплик, который фактически не принимает участие в процессе репликации; он добавляется в набор реплик для выполнения некоторых ограниченных функций как прерыватель соединений.

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

Арбитр необходим, если в наборе реплик есть только вторичные узлы.

Настройка вторичных узлов

Бывают случаи, когда не все вторичные узлы должны следовать за первичным. Набор реплик может содержать до 12 членов, 7 из которых могут голосовать в случае падения первичного узла.

Узлы реплик с приоритетом 0

Иногда голосование или отдельные узлы набора реплик, ставшие первичными, могут негативно повлиять на производительность приложения.

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

Скрытые узлы репликации

Иногда возникает необходимость отделить главный набор реплик, доступный и видимый клиентами, от фоновых узлов, которые преследуют другие цели.

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

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

Задержка членов репликации

Опция delay позволяет задать время ожидания, по истечении которого вторичные узлы приступают к выполнению операции, скопированной из oplog-а.

Это позволяет защититься от случайного удаления данных или восстановиться после взлома. Например, узлы с довольно большим временем ожидания (в несколько часов) не станут немедленно выполнять операции, запущенные по ошибке, в своих наборах данных и могут быть использованы для отмены изменений на остальных узлах.

Такие узлы не должны становиться первичными, но должны участвовать в остальных операциях. Кроме того, они должны быть скрытыми (чтобы предотвратить чтение процессами устаревших данных).

Настройка набора реплик

Для примера попробуем настроить простой набор реплик, состоящий из первичного и двух вторичных узлов. Для такого набора потребуется три выделенных сервера.

Примечание: В руководстве на серверах используется система Ubuntu 12.04.

Сначала нужно установить MongoDB на каждый сервер, участвующий в репликации. Все необходимые инструкции по установке можно найти здесь:

Подготовив серверы к работе, нужно настроить их взаимодействие.

Примечание: Для выполнения дальнейших инструкций нужен доступ к root.

Настройка DNS-резолвинга

Чтобы все экземпляры MongoDB взаимодействовали друг с другом, нужно настроить разрешение имён хостов каждого узла. Для этого можно либо настроить субдомены для каждого узла либо отредактировать /etc/hosts на каждом компьютере.

Для долгой настройки лучше использовать субдомены, а для тестовой настройки – отредактировать файлы hosts, что и будет рассмотрено ниже.

Итак, откройте файл hosts на одном из узлов репликации:

nano /etc/hosts

После первой строки (с настройками для localhost) нужно добавить запись для каждого члена набора реплик. Они выглядят так:

ip_address   mongohost0.example.com

Примечание: Внешний IP-адрес можно найти в панели управления сервером. Имя хоста можно выбрать любое, но оно должно быть описательным.

В данном примере файл /etc/hosts будет выглядеть так:

127.0.0.1           localhost mongo0
123.456.789.111     mongo0.example.com
123.456.789.222     mongo1.example.com
123.456.789.333     mongo2.example.com

На всех узлах репликации этот файл будет выглядеть почти одинаково. Сохраните и закройте файл. После этого нужно изменить имя хоста сервера согласно новым настройкам. Следующая команда должна отражать имя сервера, на котором она запущена, указанное в файле /etc/hosts.

hostname mongo0.example.com

Примечание: Отредактируйте команду на каждом сервере.

Также нужно отредактировать файл /etc/hostname, указав в нём новое имя хоста:

nano /etc/hostname
mongo0.example.com

Примечание: Инструкции этого раздела нужно выполнить на каждом узле репликации.

Настройка репликации MongoDB

Для начала нужно остановить MongoDB на каждом сервере:

service mongodb stop

Затем нужно настроить каталог, который будет использоваться для хранения данных. Создайте его с помощью следующей команды:

mkdir /mongo-metadata

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

nano /etc/mongodb.conf

В этом файле нужно отредактировать несколько параметров. Найдите переменную dbpath и направьте её на только что созданный каталог:

dbpath=/mongo-metadata

Раскомментируйте строку port, чтобы включить стандартный порт:

port = 27017

В нижней части файла нужно раскомментировать параметр replSet. Задайте ему значение, которое вы легко сможете узнать:

replSet = rs0

В завершение нужно включить ветвление процессов. В нижней части файла укажите:

fork = true

Сохраните и закройте файл. Запустите узел репликации:

mongod --config /etc/mongodb.conf

Примечание: Инструкции этого раздела нужно выполнить на каждом узле репликации.

Запуск набора реплик и добавление узлов

Теперь все члены набора реплик готовы к работе, притупайте к инициации репликации данных и добавлению узлов.

На одном из узлов введите:

mongo

Появится командная строка MongoDB для текущего узла.

Запустите набор реплик:

rs.initiate()

Эта команда инициирует набор реплик и добавит в него текущий сервер. Чтобы проверить это, введите:

rs.conf()
{
"_id" : "rs0"
"version" : 1,
"members" : [
{
"_id" : 0,
"host" "mongo0.example.com:27017"
}
]
}

После этого в репликацию можно добавить остальные узлы, сославшись на имя хоста, заданное в /etc/hosts:

rs.add("mongo1.example.com")
{ "ok" : 1 }

Повторите это для всех узлов. Теперь репликация данных настроена и запущена!

Заключение

Правильно настроенные наборы реплик позволяют защитить БД от аварийных отказов и аппаратных сбоев, а это чрезвычайно важно в любой среде производства.

Tags: , , ,

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>