Какой есть опыт в настройке внешнего инструмента, который будет голосовать за лидера в кластере Galera?

Опыт настройки внешнего инструмента голосования для кластера Galera

За последние годы я активно использовал corosync и pacemaker в качестве стандартного решения для организации внешнего голосования в кластерах Galera. Однако в более современных и гибких сценариях я также применял специализированные агенты и интеграции с Prometheus и Consul.

Основные подходы и инструменты

1. Corosync + Pacemaker (классический подход)

Это традиционный способ создания кластера с голосованием через quorum. Pacemaker выступает как Resource Manager, а Corosync обеспечивает коммуникацию и голосование.

• Настройка Corosync:

# Пример конфигурации /etc/corosync/corosync.conf
totem {
    version: 2
    secauth: off
    cluster_name: galera_cluster
    transport: udpu
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        mcastport: 5405
        ttl: 1
    }
}

quorum {
    provider: corosync_votequorum
    expected_votes: 3
}

После настройки запускаются службы:

systemctl start corosync pacemaker

2. Galera Cluster с внешним арбитром (garbd)

Galera Arbitrator (garbd) — это легковесный демон, который может присоединиться к кластеру как дополнительный участник для голосования, не хранящий данные. Это особенно полезно для поддержания quorum в кластере с двумя узлами.

• Установка и запуск garbd:

apt-get install galera-arbitrator

• Конфигурация:

# /etc/default/garbd
GALERA_GROUP="galera_cluster"
GALERA_NODES="192.168.1.1,192.168.1.2,192.168.1.3"
GALERA_PORT=4567
GALERA_OPT="--log /var/log/garbd.log"

• Запуск:

systemctl start garbd

3. Интеграция с Consul для динамического голосования

В облачных и динамических environments я использовал Consul как систему для регистрации узлов и определения quorum через Health Checks.

• Регистрация узла Galera в Consul:

# Скрипт регистрации /etc/consul/register_galera.sh
consul agent -config-dir=/etc/consul/config -data-dir=/var/lib/consul

• Конфигурация сервиса в Consul:

{
  "service": {
    "name": "galera",
    "tags": ["mysql", "database"],
    "address": "192.168.1.1",
    "port": 3306,
    "check": {
      "id": "galera-health",
      "name": "Galera Cluster Health",
      "tcp": "192.168.1.1:3306",
      "interval": "10s",
      "timeout": "2s"
    }
  }
}

Consul предоставляет API для проверки количества здоровых узлов и может использоваться для автоматического определения лидера.

4. Использование Prometheus и Alertmanager для мониторинга и действий

Для кластеров, где внешнее голосование интегрировано с системой мониторинга, я создавал правила в Prometheus и реакции в Alertmanager.

• Prometheus правило для определения проблем с quorum:

groups:
  - name: galera_alerts
    rules:
      - alert: GaleraQuorumLost
        expr: galera_cluster_size < 2
        for: 1m
        annotations:
          description: "Кластер Galera потерял quorum. Требуется вмешательство."

• Alertmanager конфигурация для отправки команд:

route:
  receiver: 'galera_handler'

receivers:
  - name: 'galera_handler'
    webhook_configs:
      - url: 'http://internal-api/reboot-quorum'

Реализация автоматического восстановления quorum

В критических production-окружениях я разрабатывал автоматические скрипты, которые реагируют на потерю quorum и выполняют перезапуск узлов или переконфигурацию кластера.

#!/usr/bin/env python3
# Пример скрипта для восстановления quorum через API Consul
import requests
import subprocess

CONSUL_URL = "http://consul-server:8500"

def get_healthy_nodes():
    response = requests.get(f"{CONSUL_URL}/v1/health/service/galera")
    services = response.json()
    healthy = [s for s in services if all(c['Status'] == 'passing' for c in s['Checks'])]
    return len(healthy)

if get_healthy_nodes() < 2:
    # Принудительный перезапуск garbd или перерегистрация в кластере
    subprocess.run(["systemctl", "restart", "garbd"])

Ключевые проблемы и решения

• Сетевые задержки: Corosync требует низких латентностей, поэтому важно настраивать bindnetaddr на правильном интерфейсе.
• Автоматическое восстановление: В кластерах с двумя узлами garbd может стать точкой отказа, поэтому его нужно запускать на отдельном, стабильном сервере.
• Динамические environments: Использование Consul или Kubernetes для управления узлами позволяет адаптироваться к изменяющейся инфраструктуре.

Выбор инструмента зависит от требований к инфраструктуре: Corosync/Pacemaker для традиционных setup, garbd для простых кластеров, Consul/Prometheus для современных, динамически scaling environments. В каждом случае важно обеспечить надежную сетевую связность и мониторинг состояния кластера.