Come leggere la salute di un cluster Galera in cinque variabili di stato

Un cluster Galera (Percona XtraDB Cluster o MariaDB Galera) può sembrare perfettamente a posto dall'applicazione mentre, in silenzio, gira su due gambe, si sta auto-limitando, o tiene un nodo che avrà bisogno di una copia completa per rientrare. Ognuno di questi stati è visibile in una manciata di variabili di stato. Ecco come le leggiamo, e cosa vi dice ciascuna.

Il problema: «risponde alle query» non è un health check

La maggior parte del monitoraggio di un database in cluster controlla le stesse cose che controllava per un server singolo: la porta 3306 è aperta, SELECT 1 risponde. Un nodo Galera uscito dal primary component accetta ancora connessioni. Un nodo sincronizzato ma che applica le scritture troppo lentamente risponde ancora alle letture. Un cluster di tre che è diventato in silenzio un cluster di due serve ancora il sito, fino al momento in cui il nodo successivo se ne va e il quorum è perso.

Il cluster sa tutto questo di sé stesso. Dovete solo chiederglielo.

L'unica query da eseguire su ogni nodo

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'
);

Eseguitela su ogni membro, non solo su quello che il vostro load balancer raggiunge per caso. Molti di questi valori sono locali al nodo, e i guasti interessanti sono quelli in cui i nodi non sono d'accordo.

Appartenenza: questo nodo fa davvero parte del cluster?

wsrep_cluster_status deve essere Primary. Qualunque altra cosa (Non-Primary, Disconnected) significa che il nodo ha perso il contatto con la maggioranza e rifiuterà di servire dati coerenti. Se il vostro health check non guarda questo valore, un nodo partizionato può continuare a ricevere traffico.

wsrep_cluster_size deve essere pari al numero di nodi che avete costruito. È la variabile che cattura il «gira su due gambe». Un cluster di tre nodi che ne riporta due sta ancora servendo, è ancora in quorum, e non ha più alcuna tolleranza. Fate scattare un avviso nel momento in cui scende sotto la dimensione di progetto, non quando arriva a uno.

wsrep_local_state_comment dovrebbe riportare Synced. Donor/Desynced significa che il nodo sta alimentando un joiner e potrebbe essere rallentato; Joining e Joined significano che sta ancora recuperando. Un nodo in qualsiasi stato diverso da Synced dovrebbe essere tolto dal pool di lettura dal vostro proxy finché non rientra.

wsrep_cluster_state_uuid deve essere identico su ogni nodo. Due valori diversi significano che avete due cluster che pensano entrambi di essere il cluster. Succede solo dopo che qualcuno ha fatto il bootstrap del nodo sbagliato, quindi vale la pena controllarlo dopo ogni recupero manuale.

wsrep_ready conferma semplicemente che il nodo accetterà query; se riporta OFF, gli altri valori vi diranno il perché.

Prestazioni: il cluster si sta frenando da solo?

La replica Galera è basata sulla certificazione: ogni nodo deve concordare che un write set non è in conflitto prima che venga eseguito il commit. Questo rende il cluster veloce quanto il suo applier più lento, e Galera lo impone con il flow control.

wsrep_flow_control_paused è la frazione di tempo, dall'ultimo FLUSH STATUS, in cui la replica è rimasta in pausa perché un nodo non riusciva a tenere il passo. Leggetela come percentuale. Vicino a zero è sano. Qualunque valore stabilmente sopra qualche punto percentuale significa che le scritture attendono un nodo lento, e la latenza in scrittura della vostra applicazione lo sta pagando. Fate il flush, aspettate un intervallo noto, rileggete, così il numero descrive il presente e non l'ultimo mese.

wsrep_local_recv_queue_avg vi dice quale nodo è lento. Un nodo la cui media della coda di ricezione resta ben sopra lo zero è quello che fa scattare il flow control. Di solito la causa è locale: storage più lento, un vicino rumoroso, un report a lunga esecuzione, o troppo pochi applier thread (wsrep_applier_threads, o wsrep_slave_threads sulle release più vecchie).

wsrep_local_send_queue_avg in crescita punta nell'altra direzione: questo nodo fatica a inviare i propri write set, il che di solito significa latenza o perdita di rete tra i membri. È il motivo per cui i membri di un cluster stanno sullo stesso fabric a bassa latenza, con le copie fuori sede gestite da repliche asincrone.

Conflitti: state scrivendo su più di un nodo?

wsrep_local_cert_failures e wsrep_local_bf_aborts contano le transazioni annullate perché un altro nodo ha eseguito per primo il commit di una modifica in conflitto. L'applicazione le vede come errori di deadlock. Un rivolo costante su un cluster dove ogni nodo accetta scritture è la firma della contesa multi-writer, e i plugin di WordPress e di e-commerce che aggiornano le stesse righe di opzioni o contatori a ogni richiesta la producono in quantità.

La soluzione è architetturale, non una manopola di tuning: mandate tutte le scritture a un nodo e distribuite le letture. Con ProxySQL è una singola riga:

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 elegge un writer, gli altri diventano reader e backup writer, e max_transactions_behind permette a ProxySQL di togliere automaticamente dal pool di lettura un nodo in ritardo. Una volta che le scritture vanno a un solo nodo, questi due contatori dovrebbero restare quasi fermi.

Se poi i redattori si lamentano che un salvataggio è «sparito» al ricaricamento, la lettura è andata a un nodo che non aveva ancora applicato la scrittura. Impostare wsrep_sync_wait per quelle sessioni fa attendere la lettura finché il nodo non recupera, a un piccolo costo di latenza.

Rientro: un nodo tornerà in fretta o lentamente?

Un nodo che esce e rientra riceve o i write set mancanti dalla cache di un donor (IST, incrementale e veloce) o una copia completa del dataset (SST, lenta e pesante per il donor). Quale dei due dipende dal fatto che la cache dei write set del donor, gcache.size in wsrep_provider_options, contenga ancora tutto ciò che il joiner si è perso.

Potete dimensionarla dai contatori stessi del cluster. Leggete wsrep_replicated_bytes e wsrep_received_bytes a un'ora di distanza; la somma dei delta è grosso modo il volume di write set per ora. Moltiplicate per la finestra di manutenzione più lunga che prevedete, aggiungete un margine, e quella è la gcache che vi serve. Un nodo può allora essere aggiornato, riavviato o fermato per ore di lavoro hardware e rientrare comunque in modo incrementale.

Quorum: l'aritmetica dietro il «tre»

Il quorum è una maggioranza stretta. Tre membri tollerano la perdita di uno. Quattro membri tollerano anch'essi solo uno, perché due su quattro non è una maggioranza, quindi il quarto nodo compra capacità ma non resilienza. Due membri non tollerano nulla: se si perdono di vista, si fermano entrambi. Se avete davvero solo due nodi dati, aggiungete l'arbitro Galera (garbd) su un terzo host indipendente, così una maggioranza continua a esistere.

La stessa aritmetica vale per dove vivono i membri. Tre nodi su un host, o tre nodi i cui dati stanno su un unico array di storage, sono un solo dominio di guasto con tre nomi. Su Kubernetes, abbinate una anti-affinity rigida dei pod a un PodDisruptionBudget con minAvailable: 2, così un aggiornamento a rotazione dei nodi non può mai togliere due membri insieme.

Cosa controllare sul vostro cluster questa settimana

• Ogni nodo riporta Primary, Synced, lo stesso state UUID e la dimensione di cluster che avete progettato.
• Il vostro health check e il vostro proxy usano entrambi quei valori, non solo una connessione TCP.
• wsrep_flow_control_paused, misurato su un intervallo fresco, è vicino a zero.
• I certification failure non stanno salendo; se salgono, le scritture arrivano su più di un nodo.
• La vostra gcache copre la finestra di manutenzione pianificata più lunga.
• Nessuna coppia di membri condivide un host, un array, o (su Kubernetes) una disruption senza budget.

Un cluster Galera letto in questo modo sorprende raramente qualcuno. Se il vostro lo fa, siamo lieti di dargli un'occhiata.

cta: Parla con un ingegnere

Related

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