Quale esperienza ha nella configurazione di uno…

Non esiste esperienza nella configurazione di uno strumento esterno per votare per il leader in un cluster Galera. In Galera, la leadership non è determinata da uno strumento esterno; tutti i nodi del cluster sono uguali e possono elaborare richieste di scrittura contemporaneamente (rispettando le regole di replica). Il meccanismo per scegliere un "leader" o nodo primario per compiti specifici (come monitoraggio o operazioni amministrative) viene generalmente implementato a livello di applicazione, bilanciatore di carico o utilizzando strumenti esterni di monitoraggio e orchestrazione, ma non come uno strumento integrato per votare per il leader nel contesto di Galera.

Per gestire un cluster Galera e selezionare nodi per compiti specifici, si possono usare:

ProxySQL / HAProxy: Bilanciatori di carico che possono indirizzare il traffico a un nodo specifico in base al suo stato.
Keepalived / Pacemaker: Strumenti per garantire alta disponibilità, che possono assegnare un indirizzo IP virtuale al nodo attivo.
Strumenti di monitoraggio (ad esempio, Prometheus + Alertmanager): Permettono di monitorare lo stato dei nodi e prendere decisioni (ad esempio, cambiare il traffico).

Nel contesto di Galera, è più importante garantire:

Quorum per evitare scenari di split-brain.
La corretta configurazione di wsrep_cluster_address e wsrep_sst_auth.
SST (State Snapshot Transfer) quando si aggiungono nuovi nodi.

Se l'obiettivo è determinare il nodo "più sano" per operazioni amministrative, si tratta più di una questione di monitoraggio e scelta basata su metriche, non di votare per il leader in Galera.

Esempio di utilizzo di ProxySQL per indirizzare il traffico a un nodo (per compiti specifici):

-- Aggiunta di tutti i nodi Galera in ProxySQL
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (10, 'node1', 3306), (10, 'node2', 3306), (10, 'node3', 3306);

-- Creazione di una regola per indirizzare le query di lettura a tutti i nodi (hostgroup 10)
INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup) VALUES (10, 10);

-- Creazione di un hostgroup separato per il "nodo amministrativo" (ad esempio, node1)
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (20, 'node1', 3306);

-- Regola per indirizzare determinate query (ad esempio, SHOW STATUS) al "nodo amministrativo" (hostgroup 20)
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup) VALUES (1, 1, 'SHOW STATUS', 20);

-- Caricare le modifiche in runtime e salvarle
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 questo esempio, non "votiamo" per il leader, ma usiamo ProxySQL per instradare il traffico a un nodo specifico, il che può essere interpretato come la scelta di un nodo per eseguire compiti specifici.

Esempio di utilizzo di Keepalived per IP virtuale:

#!/bin/bash
# Pseudo-codice per uno script di verifica dello stato di Keepalived
# Questo script verrebbe eseguito su ogni nodo 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
  # Nodo sincronizzato (4) e in componente primaria
  exit 0 # Sano
else
  exit 1 # Non sano
fi

# Pseudo-codice per la configurazione di Keepalived (blocco vrrp_script)
vrrp_script check_galera {
  script "/etc/keepalived/scripts/check_galera.sh"
  interval 2 # verifica ogni 2 secondi
  timeout 3 # timeout dopo 3 secondi
  weight 50 # aumenta la priorità di 50 se lo script ha successo
}

vrrp_instance VI_1 {
  state BACKUP # Stato di default
  interface eth0 # Interfaccia di rete
  virtual_router_id 51 # ID unico per l'istanza VRRP
  priority 100 # Priorità su questo nodo (più alto = più probabile che sia MASTER)
  advert_int 1 # Intervallo di annuncio

  authentication {
    auth_type PASS
    auth_pass your_password
  }

  virtual_ipaddress {
    192.168.1.100 # L'indirizzo IP virtuale
  }

  track_script {
    check_galera # Traccia lo script di verifica
  }
}

Qui, Keepalived utilizza uno script per verificare lo stato di Galera e assegna l'indirizzo IP virtuale solo al nodo "sano" con la priorità più alta, consentendo di avere un punto di accesso unico al cluster per la scrittura, ma questo non è un sistema di voto per il leader all'interno di Galera. È un sistema di selezione del nodo attivo per l'IP virtuale.

Quale esperienza ha nella configurazione di uno strumento esterno per votare il leader in un cluster Galera?