Nella parte I, abbiamo introdotto un framework High Availability (HA) per l'hosting MySQL e discusso vari componenti e le loro funzionalità. Ora, nella Parte II, discuteremo i dettagli della replica semisincrona di MySQL e le relative impostazioni di configurazione che ci aiutano a garantire la ridondanza e la coerenza dei dati nella nostra configurazione HA. Assicurati di controllare di nuovo la Parte III, dove esamineremo vari scenari di errore che potrebbero verificarsi e il modo in cui il framework risponde e si riprende da queste condizioni.
Che cos'è la replica semisincrona di MySQL?
In parole povere, in una configurazione di replica semisincrona MySQL, il master esegue il commit delle transazioni sul motore di archiviazione solo dopo aver ricevuto il riconoscimento da almeno uno degli slave. Gli slave fornirebbero il riconoscimento solo dopo che gli eventi sono stati ricevuti e copiati nei registri del relè e anche scaricati sul disco. Ciò garantisce che per tutte le transazioni impegnate e restituite al client, i dati esistano su almeno 2 nodi. Il termine "semi" in semisincrono (replica) è dovuto al fatto che il master esegue il commit delle transazioni una volta ricevuti gli eventi e scaricati nel registro di inoltro, ma non necessariamente nei file di dati sullo slave. Ciò è in contrasto con la replica completamente sincrona, in cui la transazione sarebbe stata confermata sia sullo slave che sul master prima che la sessione ritorni al client.
La replica semisincrona, disponibile in modo nativo in MySQL, aiuta il framework HA a garantire la coerenza e la ridondanza dei dati per le transazioni impegnate. In caso di guasto del master, tutte le transazioni commesse sul master sarebbero state replicate su almeno uno degli slave (salvate nei log di inoltro). Di conseguenza, il failover su quello slave sarebbe senza perdite perché lo slave è aggiornato (dopo che i registri dei relè dello slave sono stati completamente svuotati).
Replica e impostazioni correlate semisincrone
Discutiamo alcune delle impostazioni chiave di MySQL utilizzate per garantire un comportamento ottimale per un'elevata disponibilità e coerenza dei dati nel nostro framework.
Gestire la velocità di esecuzione degli schiavi
La prima considerazione è gestire il comportamento 'semi' della replica semisincrona che garantisce solo che i dati siano stati ricevuti e scaricati nei log di inoltro dal thread I/O del slave, ma non necessariamente eseguito dal thread SQL. Per impostazione predefinita, il thread SQL in uno slave MySQL è a thread singolo e non sarà in grado di tenere il passo con il master che è multi-thread. L'ovvio impatto di ciò è che, in caso di errore del master, lo slave non sarà aggiornato poiché il suo thread SQL sta ancora elaborando gli eventi nel registro di inoltro. Ciò ritarderà il processo di failover poiché il nostro framework prevede che lo slave sia completamente aggiornato prima che possa essere promosso. Ciò è necessario per preservare la coerenza dei dati. Per risolvere questo problema, consentiamo agli slave multithread con l'opzione slave_parallel_workers di impostare il numero di thread SQL paralleli per elaborare gli eventi nei log di inoltro.
Inoltre, configuriamo le impostazioni seguenti che assicurano che lo slave non entri in nessuno stato in cui non si trovava il master:
- tipo-slave-parallelo =OROLOGIO_LOGICO
- slave_preserve_commit_order =1
Questo ci fornisce una maggiore coerenza dei dati. Con queste impostazioni, saremo in grado di ottenere una migliore parallelizzazione e velocità sullo slave, ma se ci sono troppi thread paralleli, anche l'overhead coinvolto nel coordinamento tra i thread aumenterà e purtroppo può compensare i vantaggi.
Un'altra configurazione che possiamo usare per aumentare l'efficienza dell'esecuzione parallela sugli slave è quella di ottimizzare binlog_group_commit_sync_delay sul master. Impostando questo su master, le voci di log binari sul master e quindi le voci di log di inoltro sullo slave avranno batch di transazioni che possono essere elaborate parallelamente dai thread SQL. Questo è spiegato in dettaglio nel blog di J-F Gagné dove si riferisce a questo comportamento come "rallentare il padrone per accelerare lo schiavo" .
Se gestisci le tue implementazioni MySQL tramite la console ScaleGrid, hai la possibilità di monitorare e ricevere continuamente avvisi in tempo reale sul ritardo di replica degli slave. Consente inoltre di regolare dinamicamente i parametri di cui sopra per garantire che gli slave lavorino di pari passo con il master, riducendo così al minimo il tempo necessario per un processo di failover.
Spiegazione di MySQL High Availability Framework - Parte IIFai clic per twittare
Opzioni importanti di replica semisincrona
La replica semisincrona di MySQL, in base alla progettazione, può tornare alla modalità asincrona in base alle impostazioni del timeout di riconoscimento dello slave o in base al numero di slave con capacità semisincrona disponibili in qualsiasi momento. La modalità asincrona, per definizione, non fornisce garanzie che le transazioni commesse vengano replicate sullo slave e quindi una perdita del master comporterebbe la perdita dei dati che non sono stati replicati. La progettazione predefinita del framework ScaleGrid HA consiste nell'evitare di tornare alla modalità asincrona. Esaminiamo le configurazioni che influenzano questo comportamento.
-
rpl_semi_sync_master_wait_for_slave_count
Questa opzione viene utilizzata per configurare il numero di slave che devono inviare una conferma prima che un master semisincrono possa eseguire il commit della transazione. Nella configurazione master-slave a 3 nodi, lo impostiamo su 1 in modo da avere sempre la certezza che i dati siano disponibili in almeno uno slave evitando qualsiasi impatto sulle prestazioni dovuto all'attesa del riconoscimento da parte di entrambi gli slave.
-
rpl_semi_sync_master_timeout
Questa opzione viene utilizzata per configurare la quantità di tempo che un master semisincrono attende per il riconoscimento da uno slave prima di tornare alla modalità asincrona. Lo impostiamo su un valore di timeout relativamente alto in modo che non vi sia alcun ritorno alla modalità asincrona.
Dato che stiamo operando con 2 slave e rpl_semi_sync_master_wait_for_slave_count è impostato su 1, abbiamo notato che almeno uno degli slave riconosce entro un ragionevole lasso di tempo e il master non passa alla modalità asincrona durante interruzioni temporanee della rete.
-
rpl_semi_sync_master_wait_no_slave
Questo controlla se il master attende la scadenza del periodo di timeout configurato da rpl_semi_sync_master_timeout, anche se il conteggio degli slave scende a meno del numero di slave configurati da rpl_semi_sync_master_wait_for_slave_count durante il periodo di timeout. Manteniamo il valore predefinito di ON in modo che il master non ricada sulla replica asincrona.
Impatto della perdita di tutti gli schiavi semisincroni
Come abbiamo visto sopra, il nostro framework impedisce al master di passare alla replica asincrona se tutti gli slave si disattivano o diventano irraggiungibili dal master. L'impatto diretto di ciò è che le scritture si bloccano sul master influendo sulla disponibilità del servizio. Questo è essenzialmente come descritto dal teorema CAP sui limiti di qualsiasi sistema distribuito. Il teorema afferma che, in presenza di una partizione di rete, dovremo scegliere o disponibilità o consistenza, ma non entrambe. La partizione di rete, in questo caso, può essere considerata come slave MySQL disconnessi dal master perché inattiva o irraggiungibile.
Il nostro obiettivo di coerenza è garantire che per tutte le transazioni impegnate, i dati siano disponibili su almeno 2 nodi. Di conseguenza, in questi casi, il framework ScaleGrid HA favorisce la coerenza rispetto alla disponibilità. Ulteriori scritture non saranno accettate dai client anche se il master MySQL continuerà a servire le richieste di lettura. Questa è una decisione di progettazione consapevole che abbiamo preso come comportamento predefinito che è, ovviamente, configurabile in base ai requisiti dell'applicazione.
Assicurati di iscriverti al blog ScaleGrid in modo da non perdere la Parte III in cui discuteremo più scenari di errore e capacità di ripristino del framework MySQL HA . Restate sintonizzati!!
