Как настроить репликацию MongoDB и автоматическое аварийное переключение

A Набор реплик определяется как кластер базы данных из нескольких узлов с настроенной между ними репликацией и автоматическим переключением при отказе. Чтобы гарантировать правильный выбор базы данных PRIMARY, важно иметь нечетное количество членов в наборе (включая или исключая узел Arbiter ). 

Выбранная база данных отвечает за все основные задачи. Она обрабатывает входящие операции записи и сохраняет информацию о них в oplog. Этот журнал может быть доступен и реплицирован членами вторичной реплики (SECONDARY) для применения к их собственным наборам данных. В результате все серверы в наборе будут представлять один и тот же контент и обеспечивать его доступность:

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

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

Шаг 1: Создание новой среды

Для начала вам понадобится как минимум 3 узла MongoDB, чтобы начать настройку набора реплик. Итак, перейдите к созданию новой среды следующим образом:

В нашем примере мы размещаем все экземпляры MongoDB версии 4.0.2 в одной среде. Вы можете изменить Имя среды при необходимости в соответствующем поле и продолжить процесс установки.

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

Шаг 2: Добавление файла ключа аутентификации

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

1. Нажмите на опцию Web SSH для одного из узлов базы данных и войдите в систему:

    2. Далее вы можете ввести свой собственный файл ключа или сгенерировать новый с помощью openssl с помощью следующей команды:

В этой команде 741 представляет собой размер ключа в байтах, а my.key — это имя ключа.

    3. Время распределить новый файл ключа по всем вашим экземплярам MongoDB. Вот как это сделать:

• Откройте Файловый менеджер нажав на кнопку Config рядом с любым из узлов базы данных:

• Найдите файл my.key на вкладке конфигурации по пути: /home/jelastic/my.key. Откройте его и скопируйте содержимое файла:

• По пути /var/lib/jelastic/keys вы найдете каталог keys. Создайте Новый файл, который экземпляры MongoDB будут использовать для взаимной аутентификации. В нашем случае мы создадим файл с именем mongo-set.key:

• Вставьте ранее скопированное содержимое в этот файл и примените изменения, нажав Save для всех экземпляров:

В результате этого процесса файл mongo-set.key был распределен по всем нашим узлам MongoDB.

Шаг 3: Настройка репликации MongoDB

Теперь, когда мы обеспечили безопасность экземпляров, мы можем перейти непосредственно к настройке набора реплик. Давайте начнем:

1. Начните с перехода на вкладку конфигурации для узлов MongoDB и откройте файл mongo.conf в папке etc папку. Прокрутите вниз, пока не найдете раздел replication. Раскомментируйте его и добавьте следующую строку с уникальным именем для вашего набора реплик. В нашем примере мы назовем его db-replication:

      2. Далее мы добавим новый параметр с именем keyFile в разделе security. Это послужит для указания пути к файлу ключа, который в данный момент находится по пути: /var/lib/jelastic/keys/mongo-set.key:

      3. Нажмите на соответствующую кнопку, чтобы Сохранить изменения для всех инстансов в окне редактора. 

      4. Теперь вам необходимо Перезапустить все ваши узлы БД nodes для применения новых параметров конфигурации:

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

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

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

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

В этой команде:

• {user} –указывает имя пользователя администратора, которое будет отправлено на вашу электронную почту (обычно по умолчанию это admin).

• {password} –это пароль, отправленный на вашу электронную почту вместе с соответствующим именем пользователя.

• {DB_name}- представляет собой имя базы данных, которую вы хотите реплицировать в этом наборе реплик (в нашем примере мы используем дефолтную базу admin).

В случае новых выборов вы можете использовать те же учетные данные пользователя admin для входа в новую базу данных PRIMARY.

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

В приведенных выше строках вы замените значения в скобках своими соответствующими данными:

• {replica_set} – это имя вашей реплицируемой группы баз данных, которое вы указали в начале этого раздела. В нашем случае это было db-replication.

• {current_db_ip} – указывает IP-адрес выбранного вами контейнера базы данных:

В нашем случае выполняемые строки выглядят так:

        8. Далее выполните следующую команду для всех остальных баз данных:

Здесь, {db_ip} означает IP-адрес каждой базы данных:

       9. После добавления всех участников репликации вы получите полностью функциональный набор реплик. Мы рекомендуем убедиться, что все настроено правильно в конце процесса. Для этого выполните команду: rs.status(). Это покажет вам полную информацию о вашем наборе реплик, как показано ниже:

Шаг 4. Настройка арбитра набора реплик (ReplicaSet Arbiter)

Мы рекомендуем использовать узел Arbiter в определенных случаях. Что такое узел Arbiter ? Как правило, репликация более надежна, если набор реплик содержит нечетное количество узлов. Поэтому, если в вашем наборе в данный момент четное количество узлов, вы можете добавить узел Arbiter , чтобы поддерживать кворум, поскольку он отвечает на запросы heartbeat и запросы на выборы от других участников набора. Вот некоторые подробности об узлах Arbiter типа Arbiter:

• Арбитр не хранит никаких данных; он просто голосует на выборах в случае сбоя другого узла.
• Он очень легковесный и не потребляет слишком много ресурсов.
• Он обменивался учетными данными пользователей между зашифрованными репликами.
• Для обеспечения максимальной доступности попробуйте запустить Арбитр на отдельном узле.

Вот как вы можете добавить узел Арбитра в свой набор реплик:

1. Сначала мы выполним горизонтальное масштабирование и добавим дополнительный узел в кластер:

2. После добавления узла нам понадобится новый файл ключа. Перейдите в директорию keys и создайте файл ключа mongo-set.key. Скопируйте содержимое ключа из любого из ранее настроенных узлов базы данных и вставьте его сюда, как мы делали ранее.

3. Перейдите к конфигурационному файлу mongod.conf. Раскомментируйте раздел репликации и добавьте repISetName (в нашем случае это db-replication). Также перейдите в раздел security и добавьте параметр keyFile ( /var/lib/jelastic/keys/mongo-set.key в нашем случае).

4. Наконец, перезапустите новый узел, чтобы применить эти новые параметры конфигурации:

Важно помнить, что на данном этапе вам НЕ нужно перезапускать все узлы в кластере. Перезапустите только вновь добавленный узел Арбитра. Перезапуск всех узлов приведет к новым выборам PRIMARY (если только вы не указали приоритеты для выбора конкретного узла базы данных в качестве PRIMARY).

 5. Наконец, Арбитр может быть добавлен в набор реплик. Для этого выполните следующую команду на узле PRIMARY:

Здесь {db_ip} — это IP-адрес нового узла:

 6. Теперь вы можете проверить, стал ли новый узел Арбитром. Вы можете сделать это, войдя на новый узел по SSH и подключившись к экземпляру MongoDB с учетными данными, которые вы получили по электронной почте при создании узла:

Это показывает, что новый узел, который мы только что добавили в кластер, работает как Арбитр для db-replication. Это обеспечивает кворум в любой ситуации, делая набор реплик более надежным.

Шаг 5: Тестирование доступности кластера базы данных

Далее мы можем настроить наш кластер MongoDB для удаленного подключения и выполнения операций. В следующем примере мы подключимся и выполним несколько проверочных команд с помощью простого PHP-апплета.

Для этого вам понадобится сервер приложений, например Apache. Вы можете добавить его в свое окружение, как это сделали мы, или создать новое в отдельном окружении.

1. Начните с нажатия на Change Environment Topology и добавления сервера:

    2. Откройте вкладку Configuration Manager для сервера Apache , нажав на кнопку Config , как показано ниже:

3. Найдите и откройте файл index.php в директории /var/www/webroot/ROOT и вставьте следующий код вместо содержимого по умолчанию:

Следующие значения в приведенном выше коде необходимо заменить вашими соответствующими данными:

• {replica_set_name} – введите имя вашей группы реплик.
• {db_username} – добавьте администратора выбранной основной базы данных (по умолчанию это admin).
• {db_password} – введите пароль администратора.
• {NodeID} – укажите идентификационный номер соответствующего узла. Вы можете найти его на панели управления CloudSigma PaaS.
• {environment_domain} – добавьте домен окружения. Вы также можете найти его на панели управления CloudSigma PaaS:

Убедитесь, что вы указали идентификаторы каждого узла в вашей группе реплик в соответствующем mongodbConnectionURI разделе.

Ввод соответствующих значений и запуск кода покажут вам набор строк, похожих на этот:

Убедитесь, что вы сохранили файл на этом этапе!

4. Для взаимодействия Apache с сервером MongoDB требуется специальный модуль. Вы можете добавить этот модуль в configs. Перейдите в папку etc и откройте php.ini файл. Найдите раздел [mongodb] . Здесь все, что вам нужно сделать, это удалить точку с запятой перед строкой extension=mongodb.so, чтобы включить это расширение:

      5. Примените новые конфигурации, нажав Сохранить в окне редактора. Как всегда, нам нужно перезапустить узлы, чтобы применить изменения. Нажмите на кнопку Restart Nodes рядом с Application Server, чтобы сделать это:

    6. Теперь нажмите кнопку Open in Browser , чтобы протестировать:

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

Поскольку мы использовали команду ping (строка 6 файла index.php ), первая строка отображает результат проверки доступности группы реплик:

Это означает, что группа реплик была успешно протестирована. 

Следующий блок в результатах показывает подробную информацию о хостах группы реплик. Эти данные получены благодаря функции getServers (строка 11 файла index.php). Аналогично, вы также можете проверить некоторые значения, присвоенные в процессе создания этой группы реплик:

• host – IP-адрес конкретной базы данных.

• port – это порт текущего члена репликации.

• [“is_primary”] и [“is_secondary”] – параметры, указывающие статус сервера. Соответствующие значения для выбранного основного сервера MongoDB — true, false, а для двух других серверов MongoDB — false, true соответственно.

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

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

Попробуйте PaaS бесплатно в течение 7 дней