Введение

В этом разделе мы рассмотрим задачи обслуживания кластера, изучим процесс реконфигурации СУБД Pangolin из режима standalone в полноценный кластер и разберем подключение дополнительных реплик.

Задачи обслуживания кластера

В процессе эксплуатации СУБД Pangolin могут встречаться задачи, связанные с неавтоматизированной установкой и изменением кластера:

• реконфигурация из СУБД Pangolin standalone в кластер под управлением Pangolin Manager;
• добавление новых узлов в кластер;
• удаление узлов из кластера.

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

Реконфигурация Pangolin standalone в кластер

Поскольку предполагается «реконфигурация», следовательно само ПО СУБД Pangolin уже установлено.

Процесс реконфигурации состоит из нескольких шагов:

1. Установка и настройка ПО etcd.
2. Установка ПО Pangolin Manager.
3. Добавление реплик.

Это лишь «высокоуровневый» взгляд на этот процесс, так как имеются и промежуточные (но совсем не простые) задачи. Например:

• генерация сертификатов SSL/TLS;
• настройка etcd на использование этих сертификатов;
• автоматизация конфигурации компонент кластера;
• изменение настроек файла конфигурации Pangolin Manager;
• создание ролей для работы кластера.

Более того, вероятно придется также настроить Pangolin Pooler.

Подключение дополнительных реплик

Для каждой подключаемой реплики необходимо (как минимум) выполнить следующие действия:

• установить сертификаты SSL/TLS;
• установить и настроить etcd;
• установка и настройка Pangolin Manager.

Если планируется включение сразу нескольких реплик, то разумно этот процесс минимально автоматизировать. Хотя бы с помощью скриптов Bash.

Арбитр — узел кластера, не выполняющий обслуживание клиентов СУБД. Арбитр требуется для работы кворума и обеспечения голосования при изменении топологии кластера: его основная задача заключается в том, чтобы общее количество узлов всегда было нечетным. Например, если кластер состоит из двух рабочих узлов (четное число), арбитр необходим для разрешения ситуации, когда обе половины кластера теряют связь друг с другом. Если мы имеем кластер из трех полноценных узлов, арбитр не нужен, так как нечетность уже обеспечена.

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

В целом добавление арбитра напоминает добавление реплики, хотя СУБД при этом не устанавливается.