I del I introducerede vi en High Availability (HA)-ramme for MySQL-hosting og diskuterede forskellige komponenter og deres funktionalitet. Nu i del II vil vi diskutere detaljerne i MySQL semisynkron replikering og de relaterede konfigurationsindstillinger, der hjælper os med at sikre redundans og konsistens af dataene i vores HA-opsætning. Sørg for at tjekke ind igen til del III, hvor vi vil gennemgå forskellige fejlscenarier, der kunne opstå, og den måde, som rammeværket reagerer på og genopretter efter disse forhold.
Hvad er MySQL semisynkron replikering?
Simpelt sagt, i en MySQL semisynkron replikeringskonfiguration, forpligter masteren først transaktioner til lagermotoren efter at have modtaget en bekræftelse fra mindst én af slaverne. Slaverne ville kun give en bekræftelse, efter at hændelserne er modtaget og kopieret til relæloggene og også skyllet til disken. Dette garanterer, at for alle transaktioner, der er begået og returneret til klienten, findes data på mindst 2 noder. Udtrykket 'semi' i semisynkron (replikering) skyldes det faktum, at masteren forpligter transaktionerne, når hændelserne er modtaget og tømt til relælog, men ikke nødvendigvis forpligtet til datafilerne på slaven. Dette er i modsætning til fuldt synkron replikering, hvor transaktionen ville være blevet begået på både slaven og masteren, før sessionen vender tilbage til klienten.
Semisynkron replikering, som er naturligt tilgængelig i MySQL, hjælper HA-rammen med at sikre datakonsistens og redundans for forpligtede transaktioner. I tilfælde af en masterfejl ville alle transaktioner begået på masteren være blevet replikeret til mindst én af slaverne (gemt i relæloggene). Som følge heraf ville failover til den pågældende slave være tabsfri, fordi slaven er opdateret (efter at slavens relælogfiler er fuldstændig drænet).
replikering og semisynkrone relaterede indstillinger
Lad os diskutere nogle af de vigtigste MySQL-indstillinger, der bruges til at sikre optimal adfærd for høj tilgængelighed og datakonsistens i vores rammer.
Administration af slavernes eksekveringshastighed
Den første overvejelse er at håndtere den 'semi'-adfærd af semisynkron replikering, som kun garanterer, at dataene er blevet modtaget og tømt til relælogfilerne af I/O-tråden i slave, men ikke nødvendigvis begået af SQL-tråden. Som standard er SQL-tråden i en MySQL-slave single-threaded og vil ikke være i stand til at holde trit med masteren, som er multi-threaded. Den åbenlyse virkning af dette er, at i tilfælde af en masterfejl, vil slaven ikke være opdateret, da dens SQL-tråd stadig behandler hændelserne i relæloggen. Dette vil forsinke failover-processen, da vores rammer forventer, at slaven er fuldt opdateret, før den kan promoveres. Dette er nødvendigt for at bevare datakonsistensen. For at løse dette problem aktiverer vi multitrådede slaver med muligheden slave_parallel_workers for at indstille antallet af parallelle SQL-tråde til at behandle hændelser i relælogfilerne.
Derudover konfigurerer vi nedenstående indstillinger, som sikrer, at slaven ikke går i en tilstand, som masteren ikke var i:
- slave-parallel-type =LOGICAL_CLOCK
- slave_preserve_commit_order =1
Dette giver os en stærkere datakonsistens. Med disse indstillinger vil vi være i stand til at få bedre parallelisering og hastighed på slaven, men hvis der er for mange parallelle tråde, vil overheaden involveret i koordineringen mellem trådene også stige og kan desværre opveje fordelene.
En anden konfiguration vi kan bruge til at øge effektiviteten af parallel eksekvering på slaverne er at indstille binlog_group_commit_sync_delay på masteren. Ved at sætte dette på master vil de binære logindgange på masteren og dermed relælogposterne på slaven have batches af transaktioner, der kan behandles parallelt af SQL-trådene. Dette er forklaret i detaljer i J-F Gagnés blog, hvor han omtaler denne adfærd som "at bremse mesteren for at sætte farten op for slaven" .
Hvis du administrerer dine MySQL-implementeringer gennem ScaleGrid-konsollen, har du mulighed for løbende at overvåge og modtage realtidsadvarsler om replikeringsforsinkelsen for slaverne. Det giver dig også mulighed for dynamisk at justere ovenstående parametre for at sikre, at slaverne arbejder hånd i hånd med masteren, hvilket minimerer din tid involveret i en failover-proces.
MySQL High Availability Framework Forklaret - Del IIClik for at tweete
Vigtige semisynkrone replikeringsmuligheder
MySQL semisynkron replikering kan designmæssigt falde tilbage til asynkron tilstand baseret på slavebekræftelsens timeoutindstillinger eller baseret på antallet af semisynkron-kompatible slaver, der er tilgængelige på ethvert tidspunkt. Asynkron tilstand giver pr. definition ikke garantier for, at forpligtede transaktioner replikeres til slaven, og et mastertab vil derfor føre til tab af data, der ikke er blevet replikeret. Standarddesignet af ScaleGrid HA-rammeværket er at undgå at falde tilbage til asynkron tilstand. Lad os gennemgå de konfigurationer, der påvirker denne adfærd.
-
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 master-slave-konfigurationen indstiller vi 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å bekræftelse fra en slave, før den skifter tilbage til asynkron tilstand. Vi indstiller dette til en relativt høj timeoutværdi, så der ikke er noget tilbagefald til asynkron tilstand.
Da vi arbejder med 2 slaver og rpl_semi_sync_master_wait_for_slave_count er sat til 1, har vi bemærket, at mindst én af slaverne anerkender inden for en rimelig tid og masteren skifter ikke til asynkron tilstand under midlertidige netværksafbrydelser.
-
rpl_semi_sync_master_wait_no_slave
Dette styrer, om masteren venter på, at timeoutperioden konfigureret af rpl_semi_sync_master_timeout udløber, selvom slaveantallet falder til mindre end antallet af slaver, der er konfigureret af rpl_semi_sync_master_wait_for_slave_count i timeoutperioden. Vi beholder standardværdien ON, så masteren ikke falder tilbage til asynkron replikering.
Konsekvensen af at miste alle de semisynkrone slaver
Som vi så ovenfor, forhindrer vores framework masteren i at skifte til asynkron replikering, hvis alle slaverne går ned eller bliver utilgængelige fra masteren. Den direkte indvirkning af dette er, at skrivninger går i stå på masteren, hvilket påvirker tilgængeligheden af tjenesten. Dette er i det væsentlige som beskrevet af CAP-sætningen om begrænsningerne af ethvert distribueret system. Sætningen siger, at i nærværelse af en netværkspartition, bliver vi nødt til at vælge enten tilgængelighed eller konsistens, men ikke begge dele. Netværkspartition kan i dette tilfælde betragtes som MySQL-slaver, der er afbrudt fra masteren, fordi de enten er nede eller ikke kan nås.
Vores konsekvensmål er at sikre, at for alle forpligtede transaktioner er dataene tilgængelige på mindst 2 noder. Som et resultat i sådanne tilfælde favoriserer ScaleGrid HA-rammen konsistens frem for tilgængelighed. Yderligere skrivninger vil ikke blive accepteret fra klienter, selvom MySQL-masteren stadig vil betjene læseanmodningerne. Dette er en bevidst designbeslutning, vi har truffet som standardadfærd, som naturligvis kan konfigureres baseret på applikationskravene.
Sørg for at abonnere på ScaleGrid-bloggen, så du ikke går glip af del III, hvor vi vil diskutere flere fejlscenarier og gendannelsesevner i MySQL HA-rammeværket . Følg med!
