YMatrix — это высокодоступная распределённая база данных, поддерживающая восстановление после отказа узлов. Предпосылкой высокой доступности является избыточное развертывание: узел-мастер должен иметь резервный узел (Standby), а для узла данных (Segment) основной узел (Primary) должен иметь соответствующий зеркальный узел (Mirror).
Схема развертывания системы с высокой доступностью выглядит следующим образом:
При отказе узла в кластере вы можете получить информацию о статусе узла через графический интерфейс (MatrixUI). В примере кластера мастер — mdw, Standby — smdw, сегменты — sdw1 и sdw2, каждый из которых имеет соответствующий Mirror.
Статус развертывания:
Данный метод развертывания предотвращает недоступность системы при отказе одного хоста и распределяет нагрузку по кластеру.
Далее кратко описаны принципы автоматического обслуживания кластера YMatrix и решения для различных сценариев отказа узлов разных ролей.
YMatrix поддерживает службу кластера для автоматизации обслуживания. Эта служба включает две основные функции: Failover и Failback, реализованные с помощью инструмента mxrecover. Используя эти функции, можно полностью восстановить работу после отказа узла.
Автоматический отказ (failover) — это механизм в системе автоматического обслуживания, который переключает работу с отказавшего узла на резервный, используя диагностическую информацию о состоянии узлов из кластера etcd. Кластер etcd является ключевым компонентом службы состояния кластера YMatrix и отвечает за управление статусом всех узлов. При отказе любого узла в кластере система автоматически выполняет переключение без вмешательства оператора.
После завершения автоматического отказа соответствующий узел имеет только Primary/Master, но отсутствует здоровый резервный узел. При повторном сбое восстановление невозможно. Поэтому необходимо использовать инструмент mxrecover для создания новых здоровых Mirror/Standby для нового Primary/Master.
Инструмент mxrecover предоставляет следующие возможности:
Примечание!
Подробности использования инструмента mxrecover см. в документации: mxrecover.
Когда система обнаруживает, что Mirror / Standby недоступен, статус узла в графическом интерфейсе изменяется на down.
Примечание!
Отказ Mirror не приводит к недоступности кластера, поэтому система не активирует Mirror автоматически.
Для активации Mirror необходимо использовать инструментmxrecover. Подробности ниже.
Если интервал простоя короткий, а объем данных на отказавшем узле невелик, рекомендуется сначала попробовать инкрементальное восстановление. Инкрементальный режим используется, когда после команды mxrecover не указаны параметры или указан только -c. Если инкрементальное восстановление не удается, необходимо выполнить полное копирование данных — используйте команду mxrecover -F.
Когда система обнаруживает отказ Primary, соответствующий Mirror автоматически повышается до роли Primary.
На рисунке ниже показан отказ мастера (Master) и завершенное переключение на резервный узел. Красный цвет слева от прямоугольника указывает на отказ узла, желтый — на успешное выполнение failover.
Следующие два рисунка демонстрируют отказ узла данных (Segment) и завершенное переключение мастер-слейв.
После автоматического повышения Mirror/Standby до роли Primary выполните mxrecover, чтобы создать соответствующий Mirror/Standby для нового Primary/Master и синхронизировать данные узла полностью или инкрементально, восстановив отказавший узел. Выполните mxrecover для немедленной активации отказавшего Mirror/Standby и инкрементального восстановления данных. Как указано выше, если требуется полное восстановление, используйте команду mxrecover -F.
[mxadmin@mdw ~]$ mxrecoverХотя mxrecover создал новый Mirror для нового Primary-узла, это привело к новой проблеме: распределение Primary-узлов изменилось, и оба Primary-узла теперь находятся на sdw2. Это вызовет неравномерное распределение ресурсов хоста, и sdw2 будет нести повышенную нагрузку.
Команда для перераспределения:
[mxadmin@mdw ~]$ mxrecover -rПосле выполнения mxrecover -r вы можете проверить результат на странице управления кластером графического интерфейса.
Автоматический отказ Master происходит в двух случаях:
Ниже описано влияние автоматического отказа Master на различные компоненты и рекомендуемые действия в этих сценариях.
В этом случае автоматически выполняется отказ Master и переключение на Standby для управления кластером.
В этот момент пользователь должен подключиться к графическому интерфейсу на узле Standby, как указано в подсказке. Стандартный адрес: http://<standbyIP>:8240.
Вы можете войти в систему с паролем базы данных mxadmin или суперпаролем /etc/matrixdb5/auth.conf на узле Standby:
Все функции работают нормально после входа.
В этом случае кластер больше недоступен. Тем не менее, вы можете проверить статус кластера через графический интерфейс, подключившись к Master, но функции запросов к базе данных будут ограничены.
Примечание!
Если при установке кластера Standby не был настроен, но позже добавлен с помощью инструмента mxinitstandby, это не отличается от случая, когда Standby был настроен изначально.
Примечание!
Рекомендуется настраивать Standby в продакшн-средах.
В этом случае автоматически выполняется отказ Master и переключение на Standby для управления кластером.
Здесь возможны два сценария:
В этом случае MatrixGate должен работать на хосте Master, но поскольку Master недоступен, кластер полностью недоступен.
В этом сценарии процесс MatrixGate можно считать завершившимся вместе с хостом или изолированным от сети других узлов на выключенном хосте.
В этот момент MatrixGate автоматически переключится на запись данных в Standby, и данные мониторинга будут продолжать сохраняться без вмешательства оператора.
Если необходимо просмотреть страницу мониторинга Grafana, необходимо вручную изменить источник данных и указать адрес Standby.
В этом случае сервис MatrixGate, отвечающий за мониторинг, завершил работу, и новые данные мониторинга больше не генерируются.