I del I introducerade vi ett ramverk för hög tillgänglighet (HA) för MySQL-värd och diskuterade olika komponenter och deras funktionalitet. Nu i del II kommer vi att diskutera detaljerna i MySQL semisynkron replikering och de relaterade konfigurationsinställningarna som hjälper oss att säkerställa redundans och konsistens av data i vår HA-inställning. Se till att checka in igen för del III där vi kommer att granska olika felscenarier som kan uppstå och hur ramverket reagerar och återställer sig från dessa tillstånd.
Vad är MySQL semisynkron replikering?
Enkelt uttryckt, i en MySQL semisynkron replikeringskonfiguration, överför mastern transaktioner till lagringsmotorn endast efter att ha mottagit bekräftelse från minst en av slavarna. Slavarna skulle ge bekräftelse först efter att händelserna har tagits emot och kopierats till reläloggarna och även spolas till disken. Detta garanterar att för alla transaktioner som begåtts och returneras till klienten, finns data på minst 2 noder. Termen "semi" i semisynkron (replikering) beror på det faktum att befälhavaren begår transaktionerna när händelserna väl har tagits emot och spolas till reläloggen, men inte nödvändigtvis ansluten till datafilerna på slaven. Detta i motsats till helt synkron replikering, där transaktionen skulle ha genomförts på både slaven och mastern innan sessionen återvänder till klienten.
Halvsynkron replikering, som är inbyggt tillgänglig i MySQL, hjälper HA-ramverket att säkerställa datakonsistens och redundans för engagerade transaktioner. I händelse av ett masterfel skulle alla transaktioner som begåtts på mastern ha replikerats till minst en av slavarna (sparade i reläloggarna). Som ett resultat skulle failover till den slaven vara förlustfri eftersom slaven är uppdaterad (efter att slavens reläloggar är helt tömda).
replikering och semisynkrona relaterade inställningar
Låt oss diskutera några av de viktigaste MySQL-inställningarna som används för att säkerställa optimalt beteende för hög tillgänglighet och datakonsistens i vårt ramverk.
Hantera exekveringshastigheten för slavarna
Det första övervägandet är att hantera det "semi"-beteendet för semisynkron replikering, vilket endast garanterar att data har tagits emot och spolas till reläloggarna av I/O-tråden i slav, men begås inte nödvändigtvis av SQL-tråden. Som standard är SQL-tråden i en MySQL-slav enkeltrådad och kommer inte att kunna hålla jämna steg med mastern som är flertrådad. Den uppenbara effekten av detta är att i händelse av ett masterfel kommer slaven inte att vara uppdaterad eftersom dess SQL-tråd fortfarande bearbetar händelserna i reläloggen. Detta kommer att försena failover-processen eftersom vårt ramverk förväntar sig att slaven ska vara helt uppdaterad innan den kan marknadsföras. Detta är nödvändigt för att bevara datakonsistensen. För att lösa det här problemet aktiverar vi flertrådiga slavar med alternativet slave_parallel_workers för att ställa in antalet parallella SQL-trådar för att bearbeta händelser i reläloggarna.
Dessutom konfigurerar vi inställningarna nedan som säkerställer att slaven inte går in i något tillstånd som mastern inte var i:
- slav-parallell-typ =LOGICAL_CLOCK
- slave_preserve_commit_order =1
Detta ger oss en starkare datakonsistens. Med dessa inställningar kommer vi att kunna få bättre parallellisering och hastighet på slaven, men om det finns för många parallella trådar så kommer även overheaden som är involverad i koordineringen mellan trådarna att öka och kan tyvärr kompensera för fördelarna.
En annan konfiguration vi kan använda för att öka effektiviteten av parallell exekvering på slavarna är att ställa in binlog_group_commit_sync_delay på mastern. Genom att ställa in detta på master kommer de binära loggposterna på mastern och därmed reläloggposterna på slaven att ha batcher av transaktioner som kan behandlas parallellt av SQL-trådarna. Detta förklaras i detalj i J-F Gagnés blogg där han hänvisar till detta beteende som "att sakta ner befälhavaren för att påskynda slaven" .
Om du hanterar dina MySQL-distributioner via ScaleGrid-konsolen har du möjligheten att kontinuerligt övervaka och ta emot realtidsvarningar om replikeringsfördröjningen för slavarna. Det låter dig också dynamiskt justera ovanstående parametrar för att säkerställa att slavarna arbetar hand i hand med mastern, vilket minimerar din tid involverad i en failover-process.
MySQL High Availability Framework Explained - Del IIClick To Tweet
Viktiga semisynkrona replikeringsalternativ
MySQL semisynkron replikering, genom design, kan falla tillbaka till asynkront läge baserat på inställningarna för slavbekräftelse timeout eller baserat på antalet semisynkrona kapabla slavar som är tillgängliga vid vilken tidpunkt som helst. Asynkront läge ger per definition inga garantier för att begångna transaktioner replikeras till slaven och följaktligen skulle en masterförlust leda till att data som inte har replikerats förloras. Standarddesignen för ScaleGrid HA-ramverket är att undvika att falla tillbaka till asynkront läge. Låt oss granska de konfigurationer som påverkar detta beteende.
-
rpl_semi_sync_master_wait_for_slave_count
Det här alternativet används för att konfigurera antalet slavar som måste skicka en bekräftelse innan en semisynkron master kan utföra transaktionen. I 3-nods master-slave-konfigurationen ställer vi in detta på 1 så att vi alltid har en försäkran om att data är tillgänglig i minst en slav samtidigt som vi undviker prestandapåverkan i väntan på bekräftelse från båda slavarna.
-
rpl_semi_sync_master_timeout
Det här alternativet används för att konfigurera hur lång tid en semisynkron master väntar på bekräftelse från en slav innan den växlar tillbaka till asynkront läge. Vi ställer in detta på ett relativt högt timeout-värde så att det inte finns någon återgång till asynkront läge.
Eftersom vi arbetar med 2 slavar och rpl_semi_sync_master_wait_for_slave_count är satt till 1, har vi märkt att åtminstone en av slavarna bekräftar inom rimlig tid och mastern växlar inte över till asynkront läge under tillfälliga nätverksavbrott.
-
rpl_semi_sync_master_wait_no_slave
Detta styr om mastern väntar på att timeoutperioden som konfigurerats av rpl_semi_sync_master_timeout löper ut, även om antalet slavar sjunker till mindre än antalet slavar som konfigurerats av rpl_semi_sync_master_wait_for_slave_count under timeoutperioden. Vi behåller standardvärdet ON så att mastern inte faller tillbaka till asynkron replikering.
Konsekvensen av att förlora alla halvsynkrona slavar
Som vi såg ovan, förhindrar vårt ramverk mastern från att byta till asynkron replikering om alla slavar går ner eller blir oåtkomliga från mastern. Den direkta effekten av detta är att skrivningar stannar på mastern och påverkar tillgängligheten för tjänsten. Detta är i huvudsak som beskrivs av CAP-satsen om begränsningarna för alla distribuerade system. Teoremet säger att i närvaro av en nätverkspartition måste vi välja antingen tillgänglighet eller konsistens, men inte båda. Nätverkspartitionen, i det här fallet, kan betraktas som MySQL-slavar som är bortkopplade från mastern eftersom de antingen är nere eller inte går att nå.
Vårt konsistensmål är att säkerställa att för alla genomförda transaktioner är data tillgänglig på minst 2 noder. Som ett resultat i sådana fall, gynnar ScaleGrid HA-ramverket konsekvens framför tillgänglighet. Ytterligare skrivningar kommer inte att accepteras från klienter även om MySQL-mastern fortfarande kommer att betjäna läsbegäran. Detta är ett medvetet designbeslut som vi har tagit som standardbeteende som naturligtvis är konfigurerbart baserat på applikationskraven.
Se till att prenumerera på ScaleGrid-bloggen så att du inte missar del III där vi kommer att diskutera fler felscenarier och återställningsmöjligheter för MySQL HA-ramverket . Håll utkik!!
