Dataintegritet og præstationsovervejelser i MySQL semisynkron replikering

MySQL semisynkron replikering giver forbedret dataintegritet, fordi når en commit returnerer med succes, er det kendt, at dataene findes på mindst to steder - masteren og dens slave. I dette blogindlæg gennemgår vi nogle af MySQL-hostingkonfigurationerne, der påvirker dataintegriteten og ydeevneaspekterne af semisynkron replikering. Vi vil bruge InnoDB-lagringsmotor og GTID-baseret replikering i et 3-node replikasæt (master og 2 slaver), som sikrer, at der er redundans i slaverne. Det betyder, at hvis der er problemer med den ene slave, kan vi falde tilbage på den anden.

Konfigurationer, der gælder for både master- og slavenoder

• innodb_flust_log_at_trx_commit =1
• sync_binlog =1

Disse konfigurationer garanterer høj holdbarhed og konsistensindstillinger for data. Det vil sige, at hver forpligtet transaktion garanteres at være til stede i binære logfiler, og også logfilerne skylles til disken. Derfor bevares datakonsistensen af ​​MySQL altid i tilfælde af strømsvigt eller operativsystemnedbrud.

Konfigurationer på Master Node.

• rpl_semi_sync_master_wait_for_slave_count:

Denne mulighed bruges til at konfigurere antallet af slaver, der skal sende en bekræftelse, før en semisynkron master kan udføre transaktionen. I 3-node replika-sættet anbefaler vi at sætte dette til 1, så vi altid har en forsikring om, at dataene er tilgængelige i mindst én slave, mens vi undgår enhver præstationspåvirkning involveret i at vente på bekræftelse fra begge slaver.

• rpl_semi_sync_master_timeout:

Denne mulighed bruges til at konfigurere mængden af ​​tid, som en semisynkron master venter på slavebekræftelse, før den skifter tilbage til asynkron tilstand. Vi anbefaler at indstille dette til et stort antal, så der ikke er noget tilbagefald til asynkron tilstand, som så besejrer vores dataintegritetsmål. Da vi arbejder med 2 slaver, og rpl_semi_sync_master_wait_for_slave_count er sat til 1, kan vi antage, at mindst én af slaverne anerkender inden for et rimeligt tidsrum, og derved minimerer virkningen af ​​denne indstillings ydeevne.

Konfigurationer på slaveknuderne

I slaverne er det altid vigtigt at spore to positioner meget nøjagtigt:den aktuelle udførte position af SQL-tråden i relæloggen og den aktuelle position af IO-tråden, som angiver hvor langt den binære mater-fil læses og kopieres til slave. Konsekvenserne af ikke at fastholde disse positioner er ret indlysende. Hvis der er et slavenedbrud og genstart, kan SQL-tråden begynde at behandle transaktioner fra en forkert offset, eller IO-tråden kan begynde at trække data fra en forkert position i de binære masterlogfiler. Begge disse tilfælde vil føre til datakorruption.

det er vigtigt at sikre nedbrudssikkerhed for slaver gennem følgende konfigurationer:

• relay_log_info_repository =TABEL
• relay_log_recovery =TIL

Indstilling af relay_log_info_repository til TABLE vil sikre, at SQL-trådens position opdateres sammen med hver transaktions-commit på slaven. Det er dog svært at fastholde den nøjagtige position af IO-tråden og flush til disken. Dette skyldes, at læsning af master binær log og skrivning til slave relæ log ikke er baseret på transaktioner. Indvirkningen på ydeevnen er meget høj, hvis IO-trådspositionen skal opdateres og skylles til disk efter hver skrivning til slaverelæ-logfiler. En mere elegant løsning ville være at indstille relay_log_recovery =ON, i hvilket tilfælde, hvis der er en MySQL-genstart, antages de aktuelle relælogfiler at være ødelagte og vil blive friske trukket fra masteren baseret på SQL-trådens position.

Sidst, men ikke mindst, er det vigtigt at bemærke, at semisynkron replikering sikrer, at dataene lige har 'nået' en af ​​slaverne, før masteren begår transaktionen, og betyder ikke, at transaktionerne er begået på slaven. Derfor vil det være godt at sikre, at SQL-tråden fungerer med god ydeevne. I det ideelle tilfælde bevæger SQL-tråden sig hånd i hånd med IO-tråden, så vi kan have fordelen af, at slave ikke kun modtager transaktionerne, men også begår dem. Det anbefales at gå med en multi-threaded slave konfiguration, så vi kan få øget slave SQL tråd ydeevne. De vigtige konfigurationer for multi-threaded slaves er:

• slave_parallel_workers : Sæt denne til> 1 for at aktivere flere slave-SQL-trådsarbejdere. Baseret på antallet af tråde, der skrives på masteren, kan vi bestemme et optimalt antal for dette, så slaven ikke halter.
• slave-parallel-type =LOGICAL_CLOCK
• slave-preserve-commit-order =1

Ovenstående konfigurationer vil love parallelitet i slaven, samtidig med at den bevarer rækkefølgen af ​​transaktioner som set på masteren.

For at opsummere, ved at bruge ovenstående konfigurationer på vores MySQL replikasæt, er vi i stand til at opretholde høj dataintegritet sammen med en optimal ydeevne.

Som altid, hvis du har spørgsmål, kan du efterlade os en kommentar, kontakte os på @scalegridio på Twitter eller sende os en e-mail på support @scalegrid.io.