In questa serie di blog in tre parti, abbiamo introdotto un Framework ad alta disponibilità (HA) per l'hosting MySQL nella Parte I e discusso i dettagli della replica semisincrona di MySQL nella Parte II. Ora, nella parte III, esaminiamo il modo in cui il framework gestisce alcuni degli importanti scenari di errore di MySQL e esegue il ripristino per garantire un'elevata disponibilità.
Scenari di errore MySQL
Scenario 1 – Master MySQL va giù
- Il framework Corosync e Pacemaker rileva che il MySQL master non è più disponibile. Pacemaker retrocede la risorsa master e tenta di eseguire il ripristino con un riavvio del servizio MySQL, se possibile.
- A questo punto, a causa della natura semisincrona della replica, tutte le transazioni commesse sul master sono state ricevute da almeno uno degli slave.
- Pacemaker attende che tutte le transazioni ricevute siano applicate agli slave e lascia che gli slave riportino i loro punteggi di promozione. Il calcolo del punteggio avviene in modo tale che il punteggio sia '0' se uno slave è completamente sincronizzato con il master, altrimenti sia un numero negativo.
- Pacemaker seleziona lo slave che ha riportato il punteggio 0 e promuove quello slave che ora assume il ruolo di master MySQL su cui sono consentite le scritture.
- Dopo la promozione slave, Resource Agent attiva un modulo di reindirizzamento DNS. Il modulo aggiorna la voce DNS del proxy con l'indirizzo IP del nuovo master, facilitando così il reindirizzamento di tutte le scritture dell'applicazione al nuovo master.
- Pacemaker imposta anche gli slave disponibili per iniziare a replicare da questo nuovo master.
Quindi, ogni volta che un MySQL master si interrompe (a causa di un arresto anomalo di MySQL, del sistema operativo, del riavvio del sistema, ecc.), il nostro framework HA lo rileva e promuove uno slave adatto a assumere il ruolo di maestro. Ciò garantisce che il sistema continui a essere disponibile per le applicazioni.
Spiegazione del framework per l'alta disponibilità #MySQL - Parte III:Scenari di erroreFai clic per twittare
Scenario 2 – MySQL slave va giù
- Il framework Corosync e Pacemaker rileva che lo slave MySQL non è più disponibile.
- Pacemaker tenta di recuperare la risorsa provando a riavviare MySQL sul nodo. Se viene visualizzato, viene aggiunto di nuovo al master corrente come slave e la replica continua.
- Se il ripristino non riesce, Pacemaker segnala che la risorsa è inattiva, in base alla quale è possibile generare avvisi o notifiche. Se necessario, il team di supporto di ScaleGrid si occuperà del ripristino di questo nodo.
- In questo caso, non vi è alcun impatto sulla disponibilità dei servizi MySQL.
Scenario 3 – Partizione di rete – La connettività di rete si interrompe tra i nodi master e slave
Questo è un problema classico in qualsiasi sistema distribuito in cui ogni nodo pensa che gli altri nodi siano inattivi, mentre in realtà solo la comunicazione di rete tra i nodi è interrotta. Questo scenario è più comunemente noto come scenario split-brain e, se non gestito correttamente, può portare a più di un nodo che afferma di essere un MySQL master, il che a sua volta porta a incoerenze e danneggiamento dei dati.
Utilizziamo un esempio per rivedere come il nostro framework gestisce gli scenari split brain nel cluster. Assumiamo che, a causa di problemi di rete, il cluster sia stato partizionato in due gruppi:master in un gruppo e 2 slave nell'altro gruppo, e lo indicheremo come [(M), (S1,S2)].
- Corosync rileva che il nodo master non è in grado di comunicare con i nodi slave e che i nodi slave possono comunicare tra loro, ma non con il master .
- Il nodo master non sarà in grado di eseguire il commit di alcuna transazione poiché la replica semisincrona si aspetta il riconoscimento da almeno uno degli slave prima che il master possa eseguire il commit. Allo stesso tempo, Pacemaker chiude MySQL sul nodo master a causa della mancanza di quorum in base all'impostazione di Pacemaker "no-quorum-policy =stop". Quorum qui significa la maggior parte dei nodi, o due su tre in una configurazione di cluster a 3 nodi. Poiché in questa partizione del cluster è in esecuzione un solo nodo master, viene attivata l'impostazione no-quorum-policy che porta all'arresto del master MySQL.
- Ora, Pacemaker sulla partizione [(S1), (S2)] rileva che non è disponibile alcun master nel cluster e avvia un processo di promozione. Supponendo che S1 sia aggiornato con il master (come garantito dalla replica semisincrona), viene quindi promosso come nuovo master.
- Il traffico dell'applicazione verrà reindirizzato a questo nuovo nodo MySQL principale e lo slave S2 inizierà a replicarsi dal nuovo master.
Quindi, vediamo che il framework MySQL HA gestisce in modo efficace gli scenari split-brain, garantendo sia la coerenza dei dati che la disponibilità nel caso in cui la connettività di rete si interrompa tra i nodi master e slave.
Questo conclude la nostra serie di blog in 3 parti sul framework MySQL High Availability (HA) utilizzando la replica semisincrona e lo stack Corosync plus Pacemaker. In ScaleGrid, offriamo hosting a disponibilità elevata per MySQL su AWS e MySQL su Azure che viene implementato in base ai concetti spiegati in questa serie di blog. Visita la Console ScaleGrid per una prova gratuita delle nostre soluzioni.
