Dataintegritet och prestandaöverväganden i MySQL semisynkron replikering

MySQL semisynkron replikering ger förbättrad dataintegritet eftersom när en commit returneras framgångsrikt är det känt att data finns på minst två ställen – mastern och dess slav. I det här blogginlägget granskar vi några av MySQL-värdkonfigurationerna som påverkar dataintegriteten och prestandaaspekterna av semisynkron replikering. Vi kommer att använda InnoDB-lagringsmotor och GTID-baserad replikering i en replikuppsättning med 3 noder (master och 2 slavar), vilket kommer att säkerställa att det finns redundans i slavarna. Det betyder att om det finns problem med en slav kan vi falla tillbaka på den andra.

Konfigurationer som är tillämpliga på både master- och slavnoder

• innodb_flust_log_at_trx_commit =1
• sync_binlog =1

Dessa konfigurationer garanterar hög hållbarhet och konsistensinställningar för data. Det vill säga att varje genomförd transaktion garanterat finns i binära loggar och även loggarna spolas till disken. Därför, i fallet med ett strömavbrott eller operativsystemkrasch, bevaras datakonsistensen i MySQL alltid.

Konfigurationer på huvudnoden.

• 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 replikuppsättningen med 3 noder rekommenderar vi att du ställer in detta till 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å slavbekräftelse innan den växlar tillbaka till asynkront läge. Vi rekommenderar att du ställer in detta till ett stort antal så att det inte finns någon återgång till asynkront läge som då motverkar vårt dataintegritetsmål. Eftersom vi arbetar med 2 slavar och rpl_semi_sync_master_wait_for_slave_count är inställt på 1, kan vi anta att minst en av slavarna bekräftar inom rimlig tid, vilket minimerar prestandapåverkan av den här inställningen.

Konfigurationer på slavnoderna

I slavarna är det alltid viktigt att spåra två positioner mycket noggrant:den aktuella exekverade positionen för SQL-tråden i reläloggen och den aktuella positionen för IO-tråden som indikerar hur långt den binära materfilen läses och kopieras till slav. Konsekvenserna av att inte behålla dessa positioner är ganska uppenbara. Om det blir en slavkrasch och omstart kan SQL-tråden börja bearbeta transaktioner från en felaktig offset eller så kan IO-tråden börja dra data från en fel position i de binära masterloggarna. Båda dessa fall kommer att leda till datakorruption.

det är viktigt att säkerställa kraschsäkerhet för slavar genom följande konfigurationer:

• relay_log_info_repository =TABELL
• relay_log_recovery =PÅ

Att ställa in relay_log_info_repository till TABLE kommer att säkerställa att positionen för SQL-tråden uppdateras tillsammans med varje transaktionsbekräftelse på slaven. Det är dock svårt att upprätthålla den exakta positionen för IO-tråden och jämna till disken. Detta beror på att läsning av binär masterlogg och skrivning till slavrelälogg inte baseras på transaktioner. Inverkan på prestandan är mycket hög om IO-trådens position måste uppdateras och spolas till disken efter varje skrivning till slavreläloggar. En mer elegant lösning skulle vara att sätta relay_log_recovery =PÅ, i vilket fall, om det finns en MySQL-omstart, antas aktuella reläloggar vara korrupta och kommer att dras nyligen från mastern baserat på SQL-trådens position.

Sist men inte minst är det viktigt att notera att semisynkron replikering säkerställer att data precis har "nått" en av slavarna innan befälhavaren utförde transaktionen, och betyder inte att transaktionerna begås på slaven. Därför kommer det att vara bra att se till att SQL-tråden fungerar med bra prestanda. I det ideala fallet rör sig SQL-tråden hand i hand med IO-tråden så att vi kan ha fördelen av att slaven inte bara tar emot transaktionerna utan också begår dem. Det rekommenderas att använda en flertrådig slavkonfiguration så att vi kan få ökad prestanda för slav SQL-tråd. De viktiga konfigurationerna för flertrådiga slavar är:

• slave_parallel_workers : Ställ in detta till> 1 för att aktivera flera slav-SQL-trådarbetare. Baserat på antalet trådar som skrivs på mastern kan vi bestämma ett optimalt antal för detta så att slaven inte släpar efter.
• slav-parallell-typ =LOGICAL_CLOCK
• slave-bevara-förplikta-order =1

Ovanstående konfigurationer kommer att lova parallellitet i slaven, samtidigt som de bevarar transaktionsordningen som den ses på mastern.

Sammanfattningsvis, genom att använda ovanstående konfigurationer på vår MySQL-replikuppsättning, kan vi bibehålla hög dataintegritet tillsammans med optimal prestanda.

Som alltid, om du har några frågor, lämna oss en kommentar, kontakta oss på @scalegridio på Twitter eller skicka ett e-postmeddelande till support @scalegrid.io.