Welche Erfahrung haben Sie in der Einrichtung eines…

Es gibt keine Erfahrung in der Konfiguration eines externen Tools für die Abstimmung des Leaders in einem Galera-Cluster. In Galera wird die Führungsrolle nicht durch ein externes Tool bestimmt; alle Knoten im Cluster sind gleichberechtigt und können gleichzeitig Schreibanfragen verarbeiten (unter Einhaltung der Replikationsregeln). Der Mechanismus zur Auswahl eines "Leaders" oder Primärknotens für bestimmte Aufgaben (z.B. Überwachung oder administrative Operationen) wird in der Regel auf Anwendungsebene, durch Load Balancer oder durch externe Überwachungs- und Orchestrierungstools implementiert, aber nicht als integriertes Tool für Abstimmungen über den Leader im Galera-Kontext.

Zur Verwaltung eines Galera-Clusters und zur Auswahl von Knoten für spezifische Aufgaben können verwendet werden:

ProxySQL / HAProxy: Lastverteiler, die den Datenverkehr basierend auf dem Zustand an einen bestimmten Knoten leiten können.
Keepalived / Pacemaker: Tools zur Gewährleistung hoher Verfügbarkeit, die eine virtuelle IP-Adresse an den aktiven Knoten vergeben können.
Überwachungstools (z.B. Prometheus + Alertmanager): Ermöglichen die Überwachung des Knotenzustands und das Treffen von Entscheidungen (z.B. Umschalten des Traffics).

Im Kontext von Galera ist es wichtiger:

Quorum sicherzustellen, um Split-Brain-Szenarien zu vermeiden.
Die korrekte Konfiguration von wsrep_cluster_address und wsrep_sst_auth.
SST (State Snapshot Transfer) beim Hinzufügen neuer Knoten.

Wenn die Aufgabe darin besteht, den "gesündesten" Knoten für administrative Operationen zu bestimmen, ist dies eher eine Frage der Überwachung und der Auswahl anhand von Metriken, nicht des Abstimmens für den Leader in Galera.

Beispiel für die Verwendung von ProxySQL zur Traffic-Weiterleitung an einen Knoten (für spezifische Aufgaben):

-- Hinzufügen aller Galera-Knoten zu ProxySQL
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (10, 'node1', 3306), (10, 'node2', 3306), (10, 'node3', 3306);

-- Erstellen einer Regel, um Leseanfragen an alle Knoten (Hostgroup 10) zu leiten
INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup) VALUES (10, 10);

-- Erstellen einer separaten Hostgroup für den "administrativen" Knoten (z.B. node1)
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (20, 'node1', 3306);

-- Regel, um bestimmte Anfragen (z.B. SHOW STATUS) an den "administrativen" Knoten (Hostgroup 20) zu leiten
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup) VALUES (1, 1, 'SHOW STATUS', 20);

-- Änderungen in Runtime laden und speichern
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;

In diesem Beispiel "abstimmen" wir nicht für den Leader, sondern verwenden ProxySQL, um den Datenverkehr an einen bestimmten Knoten zu leiten, was als Auswahl eines Knotens für bestimmte Aufgaben interpretiert werden kann.

Beispiel für die Verwendung von Keepalived für eine virtuelle IP:

#!/bin/bash
# Pseudo-Code für ein Keepalived-Healthcheck-Skript
# Dieses Skript würde auf jedem Galera-Knoten laufen

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
  # Knoten ist synchronisiert (4) und im primären Zustand
  exit 0 # Gesund
else
  exit 1 # Krank
fi

# Pseudo-Code für die Keepalived-Konfiguration (vrrp_script-Block)
vrrp_script check_galera {
  script "/etc/keepalived/scripts/check_galera.sh"
  interval 2 # alle 2 Sekunden prüfen
  timeout 3 # Timeout nach 3 Sekunden
  weight 50 # Priorität um 50 erhöhen, wenn das Skript erfolgreich ist
}

vrrp_instance VI_1 {
  state BACKUP # Standardzustand
  interface eth0 # Netzwerkschnittstelle
  virtual_router_id 51 # Eindeutige ID für VRRP-Instanz
  priority 100 # Priorität auf diesem Knoten (höher = wahrscheinlicher MASTER)
  advert_int 1 # Ankündigungsintervall

  authentication {
    auth_type PASS
    auth_pass your_password
  }

  virtual_ipaddress {
    192.168.1.100 # Die virtuelle IP-Adresse
  }

  track_script {
    check_galera # Überwachungs-Skript verfolgen
  }
}

Hier verwendet Keepalived ein Skript, um den Zustand von Galera zu prüfen, und weist nur dem "gesunden" Knoten mit der höchsten Priorität die virtuelle IP zu, was einen einzigen Zugangspunkt zum Cluster für Schreiboperationen ermöglicht. Dies ist jedoch kein System für die Abstimmung über den Leader innerhalb von Galera. Es ist ein System zur Auswahl des aktiven Knotens für die virtuelle IP.

Welche Erfahrung haben Sie in der Einrichtung eines externen Tools zur Abstimmung für den Anführer in einem Galera-Cluster?