Jakie masz doświadczenie w konfigurowaniu zewnętrznego narzędzia do głosowania na lidera w klastrze Galera?

Nie ma doświadczenia w konfigurowaniu zewnętrznego narzędzia do głosowania na lidera w klastrze Galera. W Galera liderstwo nie jest ustalane przez zewnętrzne narzędzie; wszystkie węzły klastra są równorzędne i mogą jednocześnie obsługiwać żądania zapisu (przy przestrzeganiu zasad replikacji). Mechanizm wyboru "lidera" lub węzła głównego do określonych zadań (np. monitorowania lub operacji administracyjnych) jest zwykle realizowany na poziomie aplikacji, load balancera lub za pomocą zewnętrznych narzędzi monitorujących i orkiestracyjnych, ale nie jako wbudowane narzędzie do głosowania na lidera w kontekście Galera.

Do zarządzania klastrem Galera i wyboru węzła do określonych zadań można używać:

• ProxySQL / HAProxy: Równoważniki obciążenia, które mogą kierować ruch do określonego węzła na podstawie jego stanu.
• Keepalived / Pacemaker: Narzędzia zapewniające wysoką dostępność, które mogą przypisywać wirtualny adres IP do aktywnego węzła.
• Narzędzia monitorujące (np. Prometheus + Alertmanager): Pozwalają na śledzenie stanu węzłów i podejmowanie decyzji (np. o zmianie kierunku ruchu).

W kontekście Galera ważniejsze jest zapewnienie:

• Kworum, aby uniknąć scenariuszy split-brain.
• Poprawnej konfiguracji wsrep_cluster_address i wsrep_sst_auth.
• SST (State Snapshot Transfer) przy dodawaniu nowych węzłów.

Jeśli celem jest określenie "najzdrowszego" węzła do operacji administracyjnych, jest to raczej kwestia monitorowania i wyboru na podstawie metryk, a nie głosowania na lidera.

---

Przykład użycia ProxySQL do kierowania ruchem na określony węzeł (do określonych zadań):

-- Dodanie wszystkich węzłów Galera do ProxySQL
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (10, 'node1', 3306), (10, 'node2', 3306), (10, 'node3', 3306);

-- Utworzenie reguły kierowania zapytań odczytu na wszystkie węzły (hostgroup 10)
INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup) VALUES (10, 10);

-- Utworzenie osobnej grupy hostów dla "administracyjnego" węzła (np. node1)
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (20, 'node1', 3306);

-- Reguła kierowania określonych zapytań (np. SHOW STATUS) na "administracyjny" węzeł (hostgroup 20)
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup) VALUES (1, 1, 'SHOW STATUS', 20);

-- Załadowanie zmian w czasie działania i zapisanie
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;
LOAD MYSQL REPLICATION HOSTGROUPS TO RUNTIME;
SAVE MYSQL REPLICATION HOSTGROUPS TO DISK;

W tym przykładzie nie "głosujemy" na lidera, lecz używamy ProxySQL do kierowania ruchu do określonego węzła, co można interpretować jako wybór węzła do wykonania określonych zadań.

---

Przykład użycia Keepalived dla IP wirtualnego:

#!/bin/bash
# Pseudo-kod dla skryptu sprawdzającego stan Keepalived
# Skrypt ten uruchamiałby się na każdym węźle Galera

GALERA_STATUS=$(mysql -h 127.0.0.1 -e "SHOW STATUS LIKE 'wsrep_local_state';" | grep wsrep_local_state | awk '{print $2}')
GALERA_QUORUM=$(mysql -h 127.0.0.1 -e "SHOW STATUS LIKE 'wsrep_cluster_status';" | grep wsrep_cluster_status | awk '{print $2}')

if [ "$GALERA_STATUS" -eq 4 ] && [ "$GALERA_QUORUM" == "Primary" ]; then
  # Węzeł jest zsynchronizowany (4) i w głównym składzie
  exit 0 # Zdrowy
else
  exit 1 # Niezdrowy
fi

# Pseudo-kod dla konfiguracji Keepalived (blok vrrp_script)
vrrp_script check_galera {
  script "/etc/keepalived/scripts/check_galera.sh"
  interval 2 # co 2 sekundy
  timeout 3 # po 3 sekundach
  weight 50 # zwiększ priorytet o 50, jeśli skrypt się powiedzie
}

vrrp_instance VI_1 {
  state BACKUP # Domyślny stan
  interface eth0 # interfejs sieciowy
  virtual_router_id 51 # Unikalny identyfikator VRRP
  priority 100 # Priorytet na tym węźle (wyższy = bardziej prawdopodobny, że będzie MASTER)
  advert_int 1 # interwał ogłoszeń

  authentication {
    auth_type PASS
    auth_pass your_password
  }

  virtual_ipaddress {
    192.168.1.100 # Wirtualny adres IP
  }

  track_script {
    check_galera # Śledzenie skryptu zdrowotnego
  }
}

Tutaj Keepalived używa skryptu do sprawdzania stanu Galera i przypisuje wirtualny adres IP tylko "zdrowemu" węzłowi z najwyższym priorytetem, co pozwala na posiadanie jednolitego punktu dostępu do klastra do zapisu, ale nie jest to system głosowania na lidera wewnątrz Galera. To jest system wyboru aktywnego węzła dla wirtualnego IP.