Úvahy o integritě dat a výkonu v semisynchronní replikaci MySQL

Semisynchronní replikace MySQL poskytuje vylepšenou integritu dat, protože když se potvrzení úspěšně vrátí, je známo, že data existují alespoň na dvou místech – na hlavním a podřízeném. V tomto příspěvku na blogu se podíváme na některé konfigurace hostování MySQL, které ovlivňují integritu dat a výkonnostní aspekty semisynchronní replikace. Budeme používat úložný modul InnoDB a replikaci založenou na GTID v sadě replik se 3 uzly (hlavní a 2 podřízené), což zajistí, že v podřízených zařízeních bude redundance. To znamená, že pokud dojde k problémům s jedním otrokem, můžeme se vrátit k druhému.

Konfigurace použitelné pro hlavní i podřízené uzly

• innodb_flust_log_at_trx_commit =1
• sync_binlog =1

Tyto konfigurace zaručují vysokou odolnost a konzistenci nastavení pro data. To znamená, že je zaručeno, že každá potvrzená transakce bude přítomna v binárních protokolech a také se protokoly vyprázdní na disk. V případě výpadku napájení nebo zhroucení operačního systému je tedy konzistence dat MySQL vždy zachována.

Konfigurace na hlavním uzlu.

• rpl_semi_sync_master_wait_for_slave_count:

Tato možnost se používá ke konfiguraci počtu podřízených jednotek, které musí odeslat potvrzení, než může semisynchronní hlavní server provést transakci. V sadě replik se 3 uzly doporučujeme nastavit toto na 1, abychom měli vždy jistotu, že data jsou dostupná alespoň v jednom slave zařízení a zároveň se vyhneme jakémukoli dopadu na výkon spojeným s čekáním na potvrzení od obou slave.

• rpl_semi_sync_master_timeout:

Tato možnost se používá ke konfiguraci doby, po kterou semisynchronní master čeká na potvrzení slave před přepnutím zpět do asynchronního režimu. Doporučujeme toto nastavit na velké číslo, aby nedocházelo k žádnému návratu do asynchronního režimu, který by pak zmařil náš cíl integrity dat. Protože pracujeme se 2 podřízenými zařízeními a rpl_semi_sync_master_wait_for_slave_count je nastaveno na 1, můžeme předpokládat, že alespoň jeden z podřízených zařízení potvrdí během přiměřené doby, čímž se minimalizuje dopad tohoto nastavení na výkon.

Konfigurace na podřízených uzlech

U podřízených jednotek je vždy důležité velmi přesně sledovat dvě pozice:aktuální pozici vlákna SQL v protokolu přenosu a aktuální pozici vlákna IO, která ukazuje, jak daleko binární soubor mater se přečte a zkopíruje do podřízeného zařízení. Důsledky neudržení těchto pozic jsou zcela zřejmé. Pokud dojde k selhání podřízeného zařízení a restartu, vlákno SQL může začít zpracovávat transakce z nesprávného offsetu nebo vlákno IO může začít stahovat data z nesprávné pozice v hlavních binárních protokolech. Oba tyto případy povedou k poškození dat.

je důležité zajistit bezpečnost otroků při havárii prostřednictvím následujících konfigurací:

• relay_log_info_repository =TABLE
• relay_log_recovery =ON

Nastavení relay_log_info_repository na TABLE zajistí aktualizaci pozice SQL vlákna spolu s každým potvrzením transakce na slave. Je však obtížné udržet přesnou polohu IO vlákna a zarovnat s diskem. Je to proto, že čtení hlavního binárního protokolu a zápis do protokolu podřízeného relé není založeno na transakcích. Dopad na výkon je velmi vysoký, pokud musí být pozice IO vlákna aktualizována a vyprázdněna na disk po každém zápisu do protokolů slave relay. Elegantnějším řešením by bylo nastavit relay_log_recovery =ON, v takovém případě, pokud dojde k restartu MySQL, budou aktuální protokoly přenosu považovány za poškozené a budou čerstvě staženy z hlavního serveru na základě pozice vlákna SQL.

V neposlední řadě je důležité poznamenat, že semisynchronní replikace zajišťuje, že data právě „došla“ k jednomu z podřízených jednotek dříve, než master provede transakci, a neznamená to, že transakce jsou provedeny na podřízeném zařízení. Proto bude dobré zajistit, aby vlákno SQL fungovalo s dobrým výkonem. V ideálním případě se vlákno SQL pohybuje ruku v ruce s vláknem IO, takže můžeme mít výhodu, že slave transakce nejen přijímá, ale také je provádí. Doporučuje se použít vícevláknovou podřízenou konfiguraci, abychom mohli získat vyšší výkon podřízených podprocesů SQL. Důležité konfigurace pro vícevláknové podřízené jednotky jsou:

• slave_parallel_workers : Nastavte toto na> 1, chcete-li povolit více podřízených pracovníků podprocesů SQL. Na základě počtu vláken zapsaných na masteru můžeme určit optimální počet, aby se slave nezdržoval.
• slave-parallel-type =LOGICKÉ_HODINY
• slave-preserve-commit-order =1

Výše uvedené konfigurace slibují paralelismus v podřízeném zařízení a zároveň zachovávají pořadí transakcí, jak je vidět na hlavním serveru.

Shrnuto, pomocí výše uvedených konfigurací na naší sadě replik MySQL jsme schopni udržet vysokou integritu dat spolu s optimálním výkonem.

Jako vždy, pokud máte nějaké dotazy, zanechte nám komentář, kontaktujte nás na @scalegridio na Twitteru nebo nám pošlete e-mail na podporu @scalegrid.io.