¿Qué experiencia tiene en la configuración de una…

No existe experiencia en la configuración de una herramienta externa para votar por el líder en un clúster Galera. En Galera, el liderazgo no se determina mediante una herramienta externa; todos los nodos del clúster son iguales y pueden procesar solicitudes de escritura simultáneamente (cumpliendo las reglas de replicación). El mecanismo para elegir un "líder" o nodo primario para tareas específicas (como monitoreo o operaciones administrativas) generalmente se implementa a nivel de la aplicación, balanceador o mediante herramientas externas de monitoreo y orquestación, pero no como una función incorporada para votar por el líder en el contexto de Galera.

Para gestionar un clúster Galera y seleccionar nodos para tareas específicas, se pueden usar:

ProxySQL / HAProxy: Balanceadores de carga que pueden dirigir el tráfico a un nodo específico según su estado.
Keepalived / Pacemaker: Herramientas para garantizar alta disponibilidad, que pueden asignar una IP virtual al nodo activo.
Herramientas de monitoreo (por ejemplo, Prometheus + Alertmanager): Permiten monitorear el estado de los nodos y tomar decisiones (como cambiar el tráfico).

En el contexto de Galera, es más importante garantizar:

Quórum para evitar escenarios de split-brain.
Configuración correcta de wsrep_cluster_address y wsrep_sst_auth.
SST (State Snapshot Transfer) al agregar nuevos nodos.

Si la tarea es determinar el nodo "más saludable" para operaciones administrativas, esto es más una cuestión de monitoreo y selección basada en métricas, no de votar por el líder en Galera.

Ejemplo de uso de ProxySQL para dirigir el tráfico a un nodo (para tareas específicas):

-- Añadir todos los nodos Galera en ProxySQL
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (10, 'node1', 3306), (10, 'node2', 3306), (10, 'node3', 3306);

-- Crear regla para dirigir las consultas de lectura a todos los nodos (hostgroup 10)
INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup) VALUES (10, 10);

-- Crear un hostgroup separado para el "nodo administrativo" (por ejemplo, node1)
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (20, 'node1', 3306);

-- Regla para dirigir ciertas consultas (por ejemplo, SHOW STATUS) al "nodo administrativo" (hostgroup 20)
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup) VALUES (1, 1, 'SHOW STATUS', 20);

-- Cargar cambios en tiempo de ejecución y guardar
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;

En este ejemplo, no "votamos" por el líder, sino que usamos ProxySQL para enrutar el tráfico a un nodo específico, lo cual puede interpretarse como la selección de un nodo para realizar tareas específicas.

Ejemplo de uso de Keepalived para IP virtual:

#!/bin/bash
# Pseudo-código para un script de verificación de salud de Keepalived
# Este script se ejecutaría en cada nodo de 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 sincronizado (4) y en componente primario
  exit 0 # Saludable
else
  exit 1 # No saludable
fi

# Pseudo-código para configuración de Keepalived (bloque vrrp_script)
vrrp_script check_galera {
  script "/etc/keepalived/scripts/check_galera.sh"
  interval 2 # verificar cada 2 segundos
  timeout 3 # tiempo de espera de 3 segundos
  weight 50 # aumentar prioridad en 50 si el script tiene éxito
}

vrrp_instance VI_1 {
  state BACKUP # Estado predeterminado
  interface eth0 # interfaz de red
  virtual_router_id 51 # ID único para la instancia VRRP
  priority 100 # prioridad en este nodo (más alto = más probable ser MASTER)
  advert_int 1 # intervalo de anuncios

  authentication {
    auth_type PASS
    auth_pass your_password
  }

  virtual_ipaddress {
    192.168.1.100 # La IP virtual
  }

  track_script {
    check_galera # rastrear el script de verificación
  }
}

Aquí, Keepalived usa un script para verificar el estado de Galera y asigna la IP virtual solo al nodo "saludable" con la prioridad más alta, permitiendo tener un punto de acceso único al clúster para escritura, pero esto no es un sistema de votación por el líder dentro de Galera. Es un sistema para seleccionar el nodo activo para la IP virtual.

¿Qué experiencia tiene en la configuración de una herramienta externa para votar por el líder en un clúster de Galera?