Comment lire la santé d'un cluster Galera en cinq variables d'état

Un cluster Galera (Percona XtraDB Cluster ou MariaDB Galera) peut sembler parfaitement en forme vu de l'application alors qu'il tourne discrètement sur deux jambes, se freine lui-même, ou garde un nœud qui aura besoin d'une copie complète pour rejoindre le cluster. Chacun de ces états se voit dans une poignée de variables d'état. Voici comment nous les lisons, et ce que chacune vous dit.

Le problème : « il répond aux requêtes » n'est pas un contrôle de santé

La plupart des supervisions d'une base de données en cluster vérifient la même chose que pour un serveur isolé : le port 3306 est-il ouvert, SELECT 1 répond-il. Un nœud Galera sorti du primary component accepte toujours des connexions. Un nœud synchronisé mais qui applique les écritures trop lentement répond toujours aux lectures. Un cluster de trois devenu discrètement un cluster de deux sert toujours le site, jusqu'au moment où le nœud suivant s'en va et où le quorum est perdu.

Le cluster sait tout cela de lui-même. Il suffit de le lui demander.

La seule requête à lancer sur chaque nœud

SHOW GLOBAL STATUS WHERE Variable_name IN (
  'wsrep_cluster_status',
  'wsrep_cluster_size',
  'wsrep_local_state_comment',
  'wsrep_ready',
  'wsrep_cluster_state_uuid',
  'wsrep_flow_control_paused',
  'wsrep_local_recv_queue_avg',
  'wsrep_local_send_queue_avg',
  'wsrep_local_cert_failures',
  'wsrep_local_bf_aborts'
);

Lancez-la sur chaque membre, pas seulement sur celui que votre load balancer atteint par hasard. Plusieurs de ces valeurs sont locales au nœud, et les pannes intéressantes sont celles où les nœuds ne sont pas d'accord.

Appartenance : ce nœud fait-il vraiment partie du cluster ?

wsrep_cluster_status doit valoir Primary. Toute autre valeur (Non-Primary, Disconnected) signifie que ce nœud a perdu le contact avec la majorité et refusera de servir des données cohérentes. Si votre contrôle de santé ne regarde pas cette valeur, un nœud isolé peut continuer à recevoir du trafic.

wsrep_cluster_size doit être égal au nombre de nœuds que vous avez construits. C'est la variable qui attrape « tourner sur deux jambes ». Un cluster de trois nœuds qui en rapporte deux sert toujours, est toujours en quorum, et n'a plus aucune tolérance. Déclenchez une alerte en avertissement dès qu'il descend sous la taille de conception, pas quand il atteint un.

wsrep_local_state_comment doit afficher Synced. Donor/Desynced signifie que le nœud alimente un joiner et peut être ralenti. Joining et Joined signifient qu'il est encore en train de rattraper. Un nœud dans tout état autre que Synced doit être sorti du pool de lecture par votre proxy jusqu'à son retour.

wsrep_cluster_state_uuid doit être identique sur chaque nœud. Deux valeurs différentes signifient que vous avez deux clusters qui pensent chacun être le cluster. Cela n'arrive qu'après que quelqu'un a amorcé le mauvais nœud, donc cela vaut une vérification après toute reprise manuelle.

wsrep_ready confirme simplement que le nœud acceptera les requêtes. S'il affiche OFF, les autres valeurs vous diront pourquoi.

Performances : le cluster se retient-il lui-même ?

La réplication Galera repose sur la certification : chaque nœud doit convenir qu'un write set n'entre pas en conflit avant qu'il soit validé. Cela rend le cluster aussi rapide que son applier le plus lent, et Galera l'impose par le flow control.

wsrep_flow_control_paused est la fraction du temps, depuis le dernier FLUSH STATUS, pendant laquelle la réplication a été mise en pause parce qu'un nœud ne suivait pas. Lisez-la comme un pourcentage. Proche de zéro, c'est sain. Toute valeur durablement au-dessus de quelques pour cent signifie que les écritures attendent un nœud lent, et c'est la latence d'écriture de votre application qui en paie le prix. Faites un flush, attendez un intervalle connu, relisez, pour que le chiffre décrive le présent et non le mois dernier.

wsrep_local_recv_queue_avg vous dit quel nœud est lent. Un nœud dont la moyenne de la file de réception se tient nettement au-dessus de zéro est celui qui déclenche le flow control. La cause est généralement locale : un stockage plus lent, un voisin bruyant, un rapport de longue durée, ou trop peu de threads applier (wsrep_applier_threads, ou wsrep_slave_threads sur les versions plus anciennes).

wsrep_local_send_queue_avg qui monte pointe dans l'autre direction : ce nœud peine à envoyer ses propres write sets, ce qui signifie généralement de la latence ou des pertes réseau entre membres. C'est la raison pour laquelle les membres du cluster doivent être sur le même fabric à faible latence, les copies hors site étant assurées par des réplicas asynchrones.

Conflits : écrivez-vous sur plus d'un nœud ?

wsrep_local_cert_failures et wsrep_local_bf_aborts comptent les transactions annulées parce qu'un autre nœud a validé en premier une modification en conflit. L'application les voit comme des erreurs de deadlock. Un filet régulier sur un cluster où chaque nœud accepte des écritures est la signature d'une contention multi-writer, et les plugins WordPress et e-commerce qui mettent à jour les mêmes lignes d'options ou de compteurs à chaque requête en produisent en volume.

La solution est architecturale, pas un bouton de réglage : envoyez toutes les écritures vers un seul nœud et répartissez les lectures. Avec ProxySQL, c'est une seule ligne :

INSERT INTO mysql_galera_hostgroups
  (writer_hostgroup, backup_writer_hostgroup, reader_hostgroup,
   offline_hostgroup, active, max_writers, writer_is_also_reader,
   max_transactions_behind)
VALUES (10, 20, 30, 40, 1, 1, 1, 100);
LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;

max_writers = 1 élit un writer, les autres deviennent readers et backup writers, et max_transactions_behind permet à ProxySQL de sortir automatiquement du pool de lecture un nœud en retard. Une fois les écritures dirigées vers un seul nœud, ces deux compteurs doivent rester presque immobiles.

Si les rédacteurs se plaignent ensuite qu'une sauvegarde a « disparu » au rechargement, la lecture est allée vers un nœud qui n'avait pas encore appliqué l'écriture. Régler wsrep_sync_wait pour ces sessions fait attendre la lecture jusqu'à ce que le nœud ait rattrapé, pour un petit coût en latence.

Retour dans le cluster : un nœud reviendra-t-il vite ou lentement ?

Un nœud qui part et revient reçoit soit les write sets manqués depuis le cache d'un donneur (IST, incrémental et rapide), soit une copie complète du jeu de données (SST, lent et lourd pour le donneur). Lequel vous obtenez dépend de la question de savoir si le cache de write sets du donneur, gcache.size dans wsrep_provider_options, contient encore tout ce que le joiner a manqué.

Vous pouvez le dimensionner à partir des compteurs du cluster lui-même. Lisez wsrep_replicated_bytes et wsrep_received_bytes à une heure d'intervalle. La somme des deltas est à peu près le volume de write sets par heure. Multipliez par la plus longue fenêtre de maintenance que vous attendez, ajoutez une marge, et c'est le gcache dont vous avez besoin. Un nœud peut alors être corrigé, redémarré, ou retenu pendant des heures de travaux matériels et rejoindre encore le cluster de façon incrémentale.

Quorum : l'arithmétique derrière « trois »

Le quorum est une majorité stricte. Trois membres tolèrent la perte d'un seul. Quatre membres n'en tolèrent aussi qu'un seul, parce que deux sur quatre n'est pas une majorité, donc le quatrième nœud achète de la capacité mais pas de résilience. Deux membres ne tolèrent rien : s'ils se perdent de vue, les deux s'arrêtent. Si vous n'avez vraiment que deux nœuds de données, ajoutez l'arbitre Galera (garbd) sur un troisième hôte indépendant pour qu'une majorité existe encore.

La même arithmétique s'applique à l'endroit où vivent les membres. Trois nœuds sur un hôte, ou trois nœuds dont les données reposent sur une seule baie de stockage, forment un seul domaine de panne portant trois noms. Sur Kubernetes, associez une anti-affinité de pods stricte à un PodDisruptionBudget minAvailable: 2, pour qu'une mise à jour glissante des nœuds ne puisse jamais emporter deux membres à la fois.

Ce qu'il faut vérifier sur votre propre cluster cette semaine

• Chaque nœud rapporte Primary, Synced, le même UUID d'état, et la taille de cluster que vous avez conçue.
• Votre contrôle de santé et votre proxy utilisent tous deux ces valeurs, pas seulement une connexion TCP.
• wsrep_flow_control_paused, mesuré sur un intervalle frais, est proche de zéro.
• Les échecs de certification ne montent pas. S'ils montent, les écritures atterrissent sur plus d'un nœud.
• Votre gcache couvre votre plus longue fenêtre de maintenance planifiée.
• Aucune paire de membres ne partage un hôte, une baie, ou (sur Kubernetes) une perturbation sans budget.

Un cluster Galera lu de cette façon surprend rarement quelqu'un. Si le vôtre le fait, nous serons heureux d'y jeter un œil.

cta: Parler à un ingénieur

Related

• /what-we-do/data-web/clustered-databases/
• /what-we-do/data-web/database-replication/
• /what-we-do/data-web/high-availability-platforms/