Semisynchrone replicatie van MySQL biedt verbeterde gegevensintegriteit, omdat wanneer een commit succesvol terugkeert, bekend is dat de gegevens op ten minste twee plaatsen bestaan:de master en de slave. In deze blogpost bespreken we enkele van de MySQL-hostingconfiguraties die van invloed zijn op de gegevensintegriteit en prestatieaspecten van semisynchrone replicatie. We gebruiken de InnoDB-opslagengine en op GTID gebaseerde replicatie in een replicaset met 3 knooppunten (master en 2 slaves), die ervoor zorgen dat er redundantie is in de slaven. Dit betekent dat als er problemen zijn met de ene slaaf, we kunnen terugvallen op de andere.
Configuraties die van toepassing zijn op zowel master- als slave-knooppunten
- innodb_flust_log_at_trx_commit =1
- sync_binlog =1
Deze configuraties garanderen hoge duurzaamheids- en consistentie-instellingen voor gegevens. Dat wil zeggen dat elke vastgelegde transactie gegarandeerd aanwezig is in binaire logs en dat de logs ook naar de schijf worden gewist. In het geval van een stroomstoring of een crash van het besturingssysteem blijft de gegevensconsistentie van MySQL dus altijd behouden.
Configuraties op de Master Node.
- rpl_semi_sync_master_wait_for_slave_count:
Deze optie wordt gebruikt om het aantal slaves te configureren dat een bevestiging moet sturen voordat een semi-synchrone master de transactie kan uitvoeren. In de replicaset met 3 knooppunten raden we aan om dit op 1 in te stellen, zodat we altijd de zekerheid hebben dat de gegevens beschikbaar zijn in ten minste één slave, terwijl we elke prestatie-impact vermijden die gepaard gaat met het wachten op bevestiging van beide slaven.
- rpl_semi_sync_master_timeout:
Deze optie wordt gebruikt om de hoeveelheid tijd in te stellen die een halfsynchrone master wacht op bevestiging van de slave voordat hij terugschakelt naar de asynchrone modus. We raden aan om dit op een groot aantal in te stellen, zodat er geen terugval is naar de asynchrone modus die dan onze doelstelling voor gegevensintegriteit verslaat. Aangezien we met 2 slaves werken en rpl_semi_sync_master_wait_for_slave_count is ingesteld op 1, kunnen we aannemen dat ten minste één van de slaves binnen een redelijke tijd bevestigt, waardoor de prestatie-impact van deze instelling wordt geminimaliseerd.
#MySQL-zelfstudie:overwegingen met betrekking tot gegevensintegriteit en prestatie bij semisynchrone replicatieKlik om te tweetenConfiguraties op de Slave-knooppunten
In de slaves is het altijd belangrijk om twee posities zeer nauwkeurig te volgen:de huidige uitgevoerde positie van de SQL-thread in het relaislogboek en de huidige positie van de IO-thread die aangeeft hoe ver het mater binaire bestand wordt gelezen en gekopieerd naar slave. De gevolgen van het niet handhaven van deze posities zijn vrij duidelijk. Als er een slave-crash is en opnieuw wordt opgestart, kan de SQL-thread beginnen met het verwerken van transacties vanaf een verkeerde offset of kan de IO-thread beginnen met het ophalen van gegevens van een verkeerde positie in de master binaire logs. Beide gevallen leiden tot gegevenscorruptie.
het is belangrijk om de crashveiligheid van slaves te waarborgen door middel van de volgende configuraties:
- relay_log_info_repository =TABEL
- relay_log_recovery =AAN
Als u relay_log_info_repository instelt op TABLE, wordt de positie van de SQL-thread geüpdatet samen met elke transactie-commit op de slave. Het is echter moeilijk om de exacte positie van de IO-thread en gelijk met de schijf te behouden. Dit komt omdat het lezen van het binaire masterlogboek en het schrijven naar het slaverelaislogboek niet is gebaseerd op transacties. De impact op de prestaties is erg groot als de IO-threadpositie moet worden bijgewerkt en naar schijf moet worden gewist na elke schrijfbewerking naar slave-relaislogboeken. Een elegantere oplossing zou zijn om relay_log_recovery =ON in te stellen, in welk geval, als er een MySQL-herstart is, wordt aangenomen dat de huidige relay-logboeken beschadigd zijn en vers van de master worden opgehaald op basis van de SQL-threadpositie.
Last but not least is het belangrijk op te merken dat semi-synchrone replicatie ervoor zorgt dat de gegevens net een van de slaves hebben 'bereikt' voordat de master de transactie uitvoert, en dat dit niet betekent dat de transacties worden gepleegd op de slaaf. Daarom is het goed om ervoor te zorgen dat de SQL-thread goed werkt. In het ideale geval beweegt de SQL-thread hand in hand met de IO-thread, zodat we het voordeel kunnen hebben dat slave niet alleen de transacties ontvangt, maar ook uitvoert. Het wordt aanbevolen om met een multi-threaded slave-configuratie te gaan, zodat we betere slave-SQL-threadprestaties kunnen krijgen. De belangrijke configuraties voor multi-threaded slaves zijn:
- slave_parallel_workers : Stel dit in op> 1 om meerdere slave-SQL-threadworkers in te schakelen. Op basis van het aantal threads dat op de master schrijft, kunnen we hiervoor een optimaal aantal bepalen, zodat de slave niet achterblijft.
- slave-parallel-type =LOGICAL_CLOCK
- slave-preserve-commit-order =1
De bovenstaande configuraties beloven parallelliteit in de slave, terwijl ze tegelijkertijd de volgorde van transacties behouden zoals te zien is op de master.
Kortom, door de bovenstaande configuraties op onze MySQL-replicaset te gebruiken, kunnen we een hoge gegevensintegriteit behouden, samen met optimale prestaties.
Als je vragen hebt, laat dan zoals altijd een reactie achter, neem contact met ons op via @scalegridio op Twitter of stuur een e-mail naar support @scalegrid.io.
