Come controllare il failover della replica per MySQL e MariaDB

Il failover automatizzato è praticamente un must per molte applicazioni:il tempo di attività è dato per scontato. È piuttosto difficile accettare che un'applicazione sia inattiva per 20 o 30 minuti perché è necessario eseguire il paging di qualcuno per accedere e indagare sulla situazione prima di agire.

Nel mondo reale, le configurazioni di replica tendono a crescere nel tempo fino a diventare complesse, a volte disordinate. E ci sono dei vincoli. Ad esempio, non tutti i nodi di una configurazione sono un buon candidato master. Forse l'hardware è diverso e alcune repliche hanno hardware meno potente in quanto sono dedicate a gestire alcuni tipi specifici del carico di lavoro? Forse sei nel mezzo della migrazione a una nuova versione di MySQL e alcuni degli slave sono già stati aggiornati? Preferiresti non avere un master nella versione più recente che replica su vecchie repliche, poiché ciò può interrompere la replica. Se si dispone di due data center, uno attivo e uno per il ripristino di emergenza, è possibile che si preferisca selezionare i candidati master solo nel data center attivo, per mantenere il master vicino agli host dell'applicazione. Queste sono solo situazioni di esempio, in cui potresti trovarti ad aver bisogno di un intervento manuale durante il processo di failover. Fortunatamente, molti strumenti di failover hanno un'opzione per assumere il controllo del processo utilizzando whitelist e blacklist. In questo post del blog, vorremmo mostrarti alcuni esempi di come puoi influenzare l'algoritmo di ClusterControl per selezionare i candidati master.

Configurazione whitelist e blacklist

ClusterControl offre un'opzione per definire sia la whitelist che la blacklist delle repliche. Una whitelist è un elenco di repliche destinate a diventare candidati master. Se nessuno di essi è disponibile (perché sono inattivi, ci sono transazioni errate o ci sono altri ostacoli che ne impediscono la promozione), il failover non verrà eseguito. In questo modo puoi definire quali host sono disponibili per diventare un candidato master. Le blacklist, invece, definiscono quali repliche non sono adatte a diventare un candidato master.

Entrambi questi elenchi possono essere definiti nel file di configurazione cmon per un determinato cluster. Ad esempio, se il tuo cluster ha l'ID "1", vuoi modificare "/etc/cmon.d/cmon_1.cnf". Per la whitelist utilizzerai la variabile "replication_failover_whitelist", per la blacklist sarà una "replication_failover_blacklist". Entrambi accettano un elenco separato da virgole di "host:port".

Consideriamo la seguente configurazione di replica. Abbiamo un master attivo (10.0.0.141) che ha due repliche (10.0.0.142 e 10.0.0.143), entrambi agiscono come master intermedi e hanno una replica ciascuno (10.0.0.144 e 10.0.0.147). Abbiamo anche un master standby in un datacenter separato (10.0.0.145) che ha una replica (10.0.0.146). Questi host sono destinati ad essere utilizzati in caso di disastro. Le repliche 10.0.0.146 e 10.0.0.147 fungono da host di backup. Vedi sotto lo screenshot.

Dato che il secondo datacenter è destinato solo al ripristino di emergenza, non vogliamo che nessuno di questi host venga promosso come master. Nella peggiore delle ipotesi, adotteremo un'azione manuale. L'infrastruttura del secondo datacenter non è ridimensionata in base alle dimensioni del datacenter di produzione (ci sono tre repliche in meno nel datacenter di ripristino di emergenza), quindi sono comunque necessarie azioni manuali prima di poter promuovere un host nel datacenter di ripristino di emergenza. Inoltre, non vorremmo che una replica di backup (10.0.0.147) fosse promossa. Né vogliamo che una terza replica della catena venga ritirata come master (anche se potrebbe essere eseguita con GTID).

Configurazione whitelist

Possiamo configurare una whitelist o una blacklist per assicurarci che il failover venga gestito a nostro piacimento. In questa particolare configurazione, l'utilizzo della whitelist potrebbe essere più adatto:definiremo quali host possono essere utilizzati per il failover e se qualcuno aggiunge un nuovo host alla configurazione, non verrà preso in considerazione come candidato principale finché qualcuno non deciderà manualmente che è ok per usarlo e aggiungerlo alla whitelist. Se usiamo la lista nera, l'aggiunta di una nuova replica da qualche parte nella catena potrebbe significare che tale replica potrebbe teoricamente essere utilizzata automaticamente per il failover a meno che qualcuno non dica esplicitamente che non può essere utilizzata. Andiamo sul sicuro e definiamo una whitelist nel nostro file di configurazione del cluster (in questo caso è /etc/cmon.d/cmon_1.cnf dato che abbiamo un solo cluster):

replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306

Dobbiamo assicurarci che il processo cmon sia stato riavviato per applicare le modifiche:

service cmon restart

Supponiamo che il nostro master si sia arrestato in modo anomalo e non possa essere raggiunto da ClusterControl. Verrà avviato un processo di failover:

La topologia sarà simile alla seguente:

Come puoi vedere, il vecchio master è disabilitato e ClusterControl non tenterà di ripristinarlo automaticamente. Spetta all'utente verificare cosa è successo, copiare tutti i dati che potrebbero non essere stati replicati sul candidato master e ricostruire il vecchio master:

Quindi si tratta di alcune modifiche alla topologia e possiamo riportare la topologia allo stato originale, semplicemente sostituendo 10.0.0.141 con 10.0.0.142:

Configurazione lista nera

Ora vedremo come funziona la lista nera. Abbiamo detto che, nel nostro esempio, potrebbe non essere l'opzione migliore, ma la proveremo a scopo illustrativo. Metteremo nella lista nera tutti gli host tranne 10.0.0.141, 10.0.0.142 e 10.0.0.143 poiché questi sono gli host che vogliamo vedere come candidati master.

replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306

Riavvieremo anche il processo cmon per applicare le modifiche alla configurazione:

service cmon restart

Il processo di failover è simile. Anche in questo caso, una volta rilevato l'arresto anomalo del master, ClusterControl avvierà un processo di failover.

Quando una replica potrebbe non essere un buon candidato master

In questa breve sezione, vorremmo discutere più in dettaglio alcuni dei casi in cui potresti non voler promuovere una determinata replica per diventare un nuovo maestro. Si spera che questo ti dia alcune idee sui casi in cui potresti dover considerare di indurre un maggiore controllo manuale del processo di failover.

Diversa versione di MySQL

Innanzitutto, se la tua replica utilizza una versione MySQL diversa da quella master, non è una buona idea promuoverla. In generale, una versione più recente è sempre un divieto poiché la replica dalla nuova alla vecchia versione di MySQL non è supportata e potrebbe non funzionare correttamente. Ciò è rilevante principalmente per le versioni principali (ad esempio, dalla 8.0 alla 5.7) ma è buona norma evitare del tutto questa configurazione, anche se stiamo parlando di piccole differenze di versione (5.7.x+1 -> 5.7.x). È supportata la replica dalla versione inferiore a quella superiore/più recente in quanto è un must per il processo di aggiornamento, ma si preferisce comunque evitarlo (ad esempio, se il proprio master è su 5.7.x+1 si preferisce non sostituirlo con una replica su 5.7.x).

Ruoli diversi

Puoi assegnare ruoli diversi alle tue repliche. Puoi sceglierne uno in modo che sia disponibile per gli sviluppatori per testare le loro query su un set di dati di produzione. È possibile utilizzarne uno per il carico di lavoro OLAP. Puoi usarne uno per i backup. Non importa cosa sia, in genere non vorresti promuovere tale replica da padroneggiare. Tutti questi carichi di lavoro aggiuntivi non standard possono causare problemi di prestazioni a causa del sovraccarico aggiuntivo. Una buona scelta per un candidato master è una replica che gestisce un carico "normale", più o meno lo stesso tipo di carico del master corrente. Puoi quindi essere certo che gestirà il carico principale dopo il failover se lo ha gestito prima.

Diverse specifiche hardware

Abbiamo menzionato ruoli diversi per le repliche. Non è raro vedere anche specifiche hardware diverse, specialmente in combinazione con ruoli diversi. Ad esempio, molto probabilmente uno slave di backup non deve essere potente come una replica normale. Gli sviluppatori possono anche testare le loro query su un database più lento rispetto a quello di produzione (soprattutto perché non ti aspetteresti lo stesso livello di concorrenza sul database di sviluppo e produzione) e, ad esempio, il conteggio dei core della CPU può essere ridotto. Le impostazioni di ripristino di emergenza possono anche essere ridotte di dimensioni se il loro ruolo principale fosse quello di tenere il passo con la replica e si prevede che l'installazione di DR dovrà essere ridimensionata (sia verticalmente, ridimensionando l'istanza che orizzontalmente, aggiungendo più repliche) prima che il traffico possa essere reindirizzato ad esso.

Repliche ritardate

Alcune delle repliche potrebbero subire ritardi:è un ottimo modo per ridurre i tempi di ripristino se i dati sono andati persi, ma li rende pessimi candidati master. Se una replica viene ritardata di 30 minuti, perderai quei 30 minuti di transazioni o dovrai attendere (probabilmente non 30 minuti poiché, molto probabilmente, la replica può recuperare più velocemente) affinché la replica applichi tutte le transazioni ritardate. ClusterControl consente di scegliere se si desidera attendere o se si desidera eseguire il failover immediatamente, ma funzionerebbe bene per un ritardo molto piccolo, al massimo decine di secondi. Se il failover dovrebbe richiedere minuti, non ha senso utilizzare una tale replica e quindi è una buona idea inserirla nella blacklist.

Centro dati diverso

Abbiamo menzionato configurazioni di ripristino di emergenza ridotte, ma anche se il tuo secondo data center è ridimensionato in base alle dimensioni della produzione, potrebbe comunque essere una buona idea mantenere i failover all'interno di un solo controller di dominio. Per cominciare, gli host delle applicazioni attive potrebbero trovarsi nel centro dati principale, quindi lo spostamento del master su un controller di dominio di standby aumenterebbe notevolmente la latenza per le query di scrittura. Inoltre, in caso di divisione della rete, potresti voler gestire manualmente questa situazione. MySQL non ha un meccanismo di quorum integrato, quindi è piuttosto complicato gestire correttamente (in modo automatico) la perdita di rete tra due datacenter.