Quelle expérience avez-vous dans la configuration…

Il n'existe pas d'expérience dans la configuration d'un outil externe pour voter pour le leader dans un cluster Galera. Dans Galera, le leadership n'est pas déterminé par un outil externe ; tous les nœuds du cluster sont égaux et peuvent traiter simultanément des requêtes d'écriture (en respectant les règles de réplication). Le mécanisme pour choisir un "leader" ou un nœud primaire pour des tâches spécifiques (comme la surveillance ou les opérations administratives) est généralement implémenté au niveau de l'application, du répartiteur de charge ou à l'aide d'outils externes de surveillance et d'orchestration, mais pas comme une fonction intégrée pour voter pour le leader dans le contexte de Galera.

Pour gérer un cluster Galera et sélectionner des nœuds pour des tâches spécifiques, on peut utiliser :

ProxySQL / HAProxy : Balanceurs de charge pouvant diriger le trafic vers un nœud spécifique en fonction de son état.
Keepalived / Pacemaker : Outils pour assurer une haute disponibilité, pouvant attribuer une adresse IP virtuelle au nœud actif.
Outils de surveillance (par exemple, Prometheus + Alertmanager) : Permettent de surveiller l'état des nœuds et de prendre des décisions (comme changer le trafic).

Dans le contexte de Galera, il est plus important d'assurer :

Quorum pour éviter les scénarios de split-brain.
Une configuration correcte de wsrep_cluster_address et wsrep_sst_auth.
SST (State Snapshot Transfer) lors de l'ajout de nouveaux nœuds.

Si la tâche consiste à déterminer le nœud "le plus sain" pour des opérations administratives, cela relève davantage de la surveillance et de la sélection basée sur des métriques, et non d'un vote pour le leader dans Galera.

Exemple d'utilisation de ProxySQL pour diriger le trafic vers un nœud (pour des tâches spécifiques) :

-- Ajout de tous les nœuds Galera dans ProxySQL
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (10, 'node1', 3306), (10, 'node2', 3306), (10, 'node3', 3306);

-- Création d'une règle pour diriger les requêtes de lecture vers tous les nœuds (groupe d'hôtes 10)
INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup) VALUES (10, 10);

-- Création d'un groupe d'hôtes séparé pour le "nœud administratif" (par exemple, node1)
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (20, 'node1', 3306);

-- Règle pour diriger certaines requêtes (par exemple, SHOW STATUS) vers le "nœud administratif" (groupe d'hôtes 20)
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup) VALUES (1, 1, 'SHOW STATUS', 20);

-- Charger les changements en runtime et sauvegarder
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;

Dans cet exemple, nous ne "votons" pas pour le leader, mais utilisons ProxySQL pour router le trafic vers un nœud spécifique, ce qui peut être interprété comme la sélection d'un nœud pour effectuer des tâches spécifiques.

Exemple d'utilisation de Keepalived pour IP virtuelle :

#!/bin/bash
# Pseudo-code pour un script de vérification de santé de Keepalived
# Ce script s'exécuterait sur chaque nœud 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
  # Le nœud est synchronisé (4) et dans un composant primaire
  exit 0 # Sain
else
  exit 1 # Non sain
fi

# Pseudo-code pour la configuration de Keepalived (bloc vrrp_script)
vrrp_script check_galera {
  script "/etc/keepalived/scripts/check_galera.sh"
  interval 2 # vérifie toutes les 2 secondes
  timeout 3 # délai d'attente de 3 secondes
  weight 50 # augmente la priorité de 50 si le script réussit
}

vrrp_instance VI_1 {
  state BACKUP # État par défaut
  interface eth0 # interface réseau
  virtual_router_id 51 # ID unique pour l'instance VRRP
  priority 100 # priorité sur ce nœud (plus élevé = plus susceptible d'être le MASTER)
  advert_int 1 # intervalle d'annonce

  authentication {
    auth_type PASS
    auth_pass your_password
  }

  virtual_ipaddress {
    192.168.1.100 # L'adresse IP virtuelle
  }

  track_script {
    check_galera # Suivi du script de vérification
  }
}

Ici, Keepalived utilise un script pour vérifier l'état de Galera et attribue l'adresse IP virtuelle uniquement au nœud "sain" avec la priorité la plus élevée, ce qui permet d'avoir un point d'accès unique au cluster pour l'écriture, mais ce n'est pas un système de vote pour le leader dans Galera. C'est un système de sélection du nœud actif pour l'IP virtuelle.

Quelle expérience avez-vous dans la configuration d'un outil externe pour voter pour le leader dans un cluster Galera?