Considerazioni sull'integrità dei dati e sulle prestazioni nella replica semisincrona di MySQL

La replica semisincrona di MySQL fornisce una migliore integrità dei dati perché quando un commit viene restituito correttamente, è noto che i dati esistono in almeno due posizioni:il master e il suo slave. In questo post del blog, esaminiamo alcune delle configurazioni di hosting MySQL che influenzano l'integrità dei dati e gli aspetti delle prestazioni della replica semisincrona. Utilizzeremo il motore di archiviazione InnoDB e la replica basata su GTID in un set di repliche a 3 nodi (master e 2 slave), che garantirà la ridondanza negli slave. Ciò significa che se ci sono problemi con uno schiavo, possiamo ricorrere all'altro.

Configurazioni applicabili sia ai nodi Master che Slave

• innodb_flust_log_at_trx_commit =1
• sync_binlog =1

Queste configurazioni garantiscono un'elevata durabilità e impostazioni di coerenza per i dati. Cioè, ogni transazione impegnata è garantita per essere presente nei registri binari e anche i registri vengono scaricati sul disco. Quindi, in caso di interruzione di corrente o di crash del sistema operativo, la consistenza dei dati di MySQL viene sempre preservata.

Configurazioni sul nodo principale.

• 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. Nel set di repliche a 3 nodi, consigliamo di impostarlo 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 dello slave prima di tornare alla modalità asincrona. Si consiglia di impostarlo su un numero elevato in modo che non vi sia un fallback alla modalità asincrona che quindi vanifichi il nostro obiettivo di integrità dei dati. Poiché operiamo con 2 slave e rpl_semi_sync_master_wait_for_slave_count è impostato su 1, possiamo presumere che almeno uno degli slave riconosca entro un ragionevole lasso di tempo, riducendo così al minimo l'impatto sulle prestazioni di questa impostazione.

Configurazioni sui nodi slave

Negli slave, è sempre importante tenere traccia di due posizioni in modo molto accurato:la posizione correntemente eseguita del thread SQL nel registro di inoltro e la posizione corrente del thread IO che indica fino a che punto il file binario mater viene letto e copiato nello slave. Le conseguenze del non mantenere queste posizioni sono abbastanza ovvie. Se si verifica un arresto anomalo e un riavvio dello slave, il thread SQL può iniziare a elaborare le transazioni da un offset errato o il thread IO può iniziare a estrarre i dati da una posizione sbagliata nei registri binari master. Entrambi questi casi porteranno al danneggiamento dei dati.

è importante garantire la sicurezza in caso di crash degli slave attraverso le seguenti configurazioni:

• relay_log_info_repository =TABELLA
• relay_log_recovery =ATTIVO

L'impostazione di relay_log_info_repository su TABLE garantirà che la posizione del thread SQL venga aggiornata insieme a ogni commit di transazione sullo slave. Tuttavia, è difficile mantenere la posizione esatta del thread IO e allinearlo al disco. Questo perché la lettura del registro binario master e la scrittura nel registro relè slave non si basano sulle transazioni. L'impatto sulle prestazioni è molto elevato se la posizione del thread IO deve essere aggiornata e scaricata su disco dopo ogni scrittura nei log di inoltro slave. Una soluzione più elegante sarebbe impostare relay_log_recovery =ON, nel qual caso, se si verifica un riavvio di MySQL, si presumerà che i log di inoltro correnti siano danneggiati e verranno estratti di recente dal master in base alla posizione del thread SQL.

Ultimo ma non meno importante, è importante notare che la replica semisincrona garantisce che i dati abbiano appena "raggiunto" uno degli slave prima che il master abbia eseguito il commit della transazione, e non significa che le transazioni sono commesse sullo slave. Pertanto, sarà utile assicurarsi che il thread SQL funzioni con buone prestazioni. Nel caso ideale, il thread SQL si muove di pari passo con il thread IO in modo da poter avere il vantaggio dello slave non solo di ricevere le transazioni, ma anche di eseguirle. Si consiglia di utilizzare una configurazione slave multi-thread in modo da poter ottenere prestazioni del thread SQL slave aumentate. Le configurazioni importanti per gli slave multi-thread sono:

• slave_parallel_workers : impostalo su> 1 per abilitare più thread worker SQL slave. In base al numero di thread scritti sul master, possiamo decidere un numero ottimale per questo in modo che lo slave non sia in ritardo.
• tipo-slave-parallelo =OROLOGIO_LOGICO
• slave-preserve-commit-order =1

Le configurazioni precedenti promettono parallelismo nello slave, preservando allo stesso tempo l'ordine delle transazioni visto sul master.

In sintesi, utilizzando le configurazioni di cui sopra sul nostro set di repliche MySQL, siamo in grado di mantenere un'elevata integrità dei dati insieme a prestazioni ottimali.

Come sempre, se hai domande, lasciaci un commento, contattaci su @scalegridio su Twitter o inviaci un'e-mail all'assistenza @scalegrid.io.