Часто задаваемые вопросы о высокой доступности

Этот документ содержит ответы на часто задаваемые вопросы о высокой доступности YMatrix 5.X.

Для документов, связанных с высокой доступностью, см.:
- Архитектура YMatrix
- Восстановление после сбоев

1. Развертывается ли etcd на каждом хосте?

Хранилище etcd можно рассматривать как полностью реплицированную таблицу, поэтому количество узлов не должно быть слишком большим. На практике рекомендуемая конфигурация — 1, 3, 5 или 7 узлов. Процесс установки и развертывания автоматически выберет и развернет несколько экземпляров etcd в зависимости от количества хостов.
Следовательно, если количество хостов в кластере четное или превышает 7, то на некоторых машинах etcd не будет развернут. Вы можете проверить наличие процессов etcd на текущем хосте с помощью команды ps.
Обычно узлы etcd размещаются на хостах Master и Standby.

2. Почему количество участников кластера etcd должно быть нечетным?

В etcd установка нечетного числа узлов обеспечивает стабильность и согласованность процесса выборов. В протоколе Raft выбор лидера основывается на принципе большинства. При нечетном числе узлов легче достичь консенсуса в процессе выборов: для избрания кандидата в лидеры необходимо, чтобы более половины узлов проголосовали за него. Например, при 5 узлах требуется согласие как минимум 3 узлов; при 7 узлах — как минимум 4.

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

3. Какие операционные задачи необходимо выполнять для etcd в повседневной эксплуатации?

Во-первых, необходимо развернуть мониторинг etcd. В настоящее время поддерживается мониторинг (Prometheus + Grafana) для развертывания etcd в версии 5.0.

4. Каков объем данных etcd? Требуются ли специальные операционные задачи?

В версии 5.X etcd автоматически очищает данные регулярно, поэтому размер каталога данных и объем памяти остаются в относительно стабильных пределах.
Однако при сбое узла и последующей операции восстановления данные etcd могут временно немного увеличиться. Если объем каталога данных etcd не превышает 1,5 ГБ, это считается нормальным. Рекомендуется отслеживать и регулярно проверять это с помощью мониторинга.

5. Какие изменения произошли в управлении кластером базы данных через графический интерфейс после введения etcd?

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

6. В версии 5.X реализована автоматическая смена мастера. Почему мастер не восстанавливается автоматически после выключения и переключения?

Здесь существует концептуальное недопонимание. Сегмент имеет два измерения:

Одно измерение — роль: Primary или Mirror
Второе измерение — состояние: Up или Down

В текущей версии функция автоматической смены мастера означает автоматическое переключение ролей узлов: после отключения мастера Standby автоматически становится новым мастером. Эта операция называется Promote или Failover.
Как только состояние сегмента изменяется с Up на Down, его необходимо вручную вернуть в состояние Up с помощью операции восстановления узла (mxrecover).

7. Сколько времени занимает автоматическое переключение мастера?

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

8. Нормально ли, что кластер аварийно завершает работу, если более половины процессов etcd стали неисправными (убиты или не могут запуститься)?

Да.

Работоспособность процесса postgres зависит от жизнеспособности аренды кластера etcd. При возникновении сбоя в самом сервисе etcd (когда более половины узлов etcd недоступны или потеряли связь), процесс postgres не может поддерживать свою работу, и остановка является неизбежным результатом. Поэтому строго рекомендуется развернуть мониторинг etcd и внимательно отслеживать его состояние здоровья. Мониторинг должен включать, но не ограничиваться: свободное место на диске, дисковый ввод-вывод, сетевую доступность, работоспособность процесса-надзирателя хоста и т.д.

← Предыдущая

архитектуре

установке

Русский English 简体中文