Replikace v MySQL existuje již dlouhou dobu a v průběhu let se neustále zlepšuje. Připomínalo to spíše evoluci než revoluci. To je naprosto pochopitelné, protože replikace je důležitou funkcí, na které mnozí závisí – musí fungovat.
V posledních verzích MySQL jsme viděli zlepšení výkonu replikace díky podpoře paralelního uplatňování transakcí. V MySQL 5.6 byla paralelizace provedena na úrovni schématu – všechny transakce, které byly provedeny v samostatných schématech, mohly být provedeny najednou. To bylo příjemné vylepšení pro ty pracovní zátěže, které měly více schémat na jednom serveru a zátěž byla rozdělena mezi schémata víceméně rovnoměrně.
V MySQL 5.7 byla přidána další metoda paralelizace, tzv. „logické hodiny“. To umožnilo získat určitou úroveň souběžnosti na slave, i když všechna vaše data byla uložena v jediném schématu. Stručně řečeno, bylo založeno na skutečnosti, že některé transakce se zavazují společně kvůli latenci přidané hardwarem. Tuto latenci můžete dokonce přidat ručně, abyste dosáhli lepší paralelizace na podřízených zařízeních pomocí binlog_group_commit_sync_delay.
Toto řešení bylo opravdu pěkné, ale ne bez nevýhod. Každé zpoždění v provedení transakce by mohlo nakonec ovlivnit uživatelské části aplikace. Jistě, můžete nastavit zpoždění v rozsahu několika milisekund, ale i tak je to další latence, která zpomaluje aplikaci.
Vylepšení výkonu replikace v MySQL 8.0
MySQL 8.0, který je od nynějška (srpen 2017) stále ve stavu beta, přináší několik pěkných vylepšení replikace. Původně byl vyvinut pro skupinovou replikaci (GR), ale protože GR používá pravidelnou replikaci pod kapotou, „normální“ replikace MySQL z toho těžila. Vylepšení, které jsme zmínili, jsou informace o sledování závislostí uložené v binárním protokolu. Co se stane, je, že MySQL 8.0 má nyní způsob, jak ukládat informace o tom, které řádky byly ovlivněny danou transakcí (tzv. writeset), a porovnává writesety z různých transakcí. To umožňuje identifikovat ty transakce, které nefungovaly na stejné podmnožině řádků, a proto je lze použít paralelně. To může umožnit několikanásobně zvýšit úroveň paralelizace ve srovnání s implementací z MySQL 5.7. Musíte mít na paměti, že nakonec podřízený uvidí jiný pohled na data, který se nikdy neobjevil na hlavním zařízení. Je to proto, že transakce mohou být aplikovány v jiném pořadí než na masteru. To by však neměl být problém. Současná implementace vícevláknové replikace v MySQL 5.7 může také způsobit tento problém, pokud výslovně nepovolíte slave-preserve-commit-order.
K ovládání tohoto nového chování slouží proměnná binlog_transaction_dependency_tracking byla zavedena. Může nabývat tří hodnot:
- COMMIT_ORDER:toto je výchozí, používá výchozí mechanismus dostupný v MySQL 5.7.
- WRITESET:Umožňuje lepší paralelizaci a master začne ukládat data zapisovací sady do binárního protokolu.
- WRITESET_SESSION:Tím je zajištěno, že transakce budou provedeny na podřízeném zařízení v pořadí a problém s podřízeným zařízením, který vidí stav databáze, který nikdy nebyl vidět na hlavním zařízení, bude odstraněn. Snižuje paralelizaci, ale stále může poskytovat lepší propustnost než výchozí nastavení.
Srovnávací
V červenci na mysqlhighavailability.com napsal Vitor Oliveira příspěvek, kde se pokusil změřit výkon nových režimů. K předvedení rozdílu mezi starými a novými režimy použil nejlepší scénář – žádnou životnost. Rozhodli jsme se použít stejný přístup, tentokrát v reálnějším nastavení:binární protokol povolený pomocí log_slave_updates. Nastavení trvanlivosti byla ponechána na výchozí (takže sync_binlog=1 – to je nové výchozí nastavení v MySQL 8.0, povolena vyrovnávací paměť pro dvojitý zápis, povoleny kontrolní součty InnoDB atd.) Jedinou výjimkou v trvanlivosti byl innodb_flush_log_at_trx_commit nastavený na 2.
Použili jsme instance m4.2xl, 32G, 8 jader (takže slave_parallel_workers bylo nastaveno na 8). Použili jsme také sysbench, skript oltp_read_write.lua. 16 milionů řádků ve 32 tabulkách bylo uloženo na 1000GB gp2 svazku (to je 3000 IOPS). Testovali jsme výkon všech režimů pro 1, 2, 4, 8, 16 a 32 souběžných připojení sysbench. Proces byl následující:zastavit slave, provést 100 000 transakcí, spustit slave a vypočítat, jak dlouho trvá odstranění zpoždění slave.
Za prvé, opravdu nevíme, co se stalo, když byl sysbench spuštěn pouze pomocí 1 vlákna. Každý test byl proveden pětkrát po zahřívacím běhu. Tato konkrétní konfigurace byla testována dvakrát – výsledky jsou stabilní:jednovláknové zatížení bylo nejrychlejší. Budeme se tím dále zabývat, abychom pochopili, co se stalo.
Kromě toho jsou ostatní výsledky v souladu s tím, co jsme očekávali. COMMIT_ORDER je nejpomalejší, zejména pro nízký provoz, 2–8 vláken. WRITESET_SESSION má obvykle lepší výkon než COMMIT_ORDER, ale je pomalejší než WRITESET pro málo souběžný provoz.
Jak mi to může pomoci?
První výhoda je zřejmá:pokud je vaše pracovní vytížení na pomalé straně, ale vaši podřízení mají tendenci ustupovat v replikaci, mohou těžit ze zlepšeného výkonu replikace, jakmile bude hlavní server upgradován na 8.0. Dvě poznámky:za prvé – tato funkce je zpětně kompatibilní a mohou z ní těžit i 5.7 slave. Za druhé – připomínáme, že 8.0 je stále ve stavu beta, nedoporučujeme vám používat beta software v produkci, i když je to naléhavá potřeba, je to možnost otestovat. Tato funkce vám může pomoci nejen tehdy, když vaši otroci zaostávají. Mohou být plně zachyceni, ale když vytvoříte nového otroka nebo obnovíte stávajícího, bude tento otrok zaostávat. Možnost používat režim „WRITESET“ výrazně urychlí proces poskytování nového hostitele.
Celkově vzato bude mít tato funkce mnohem větší dopad, než si možná myslíte. Vzhledem ke všem benchmarkům ukazujícím regrese ve výkonu, když MySQL zpracovává provoz s nízkou souběžností, je cokoli, co může pomoci urychlit replikaci v takových prostředích, obrovským zlepšením.
Pokud používáte středně pokročilé mastery, je to také funkce, kterou je třeba hledat. Jakýkoli prostřední master přidává určitou serializaci do toho, jak jsou transakce zpracovávány a prováděny – v reálném světě bude pracovní zátěž na prostředním masteru téměř vždy méně paralelní než na masteru. Využití zápisových sad k umožnění lepší paralelizace nejen zlepšuje paralelizaci na středním masteru, ale také může zlepšit paralelizaci na všech jeho podřízených. Je dokonce možné (ačkoli by to vyžadovalo seriózní testování, aby se ověřilo, že všechny části budou správně zapadat) použít střední master 8.0 ke zlepšení výkonu replikace vašich podřízených jednotek (pamatujte prosím, že podřízená jednotka MySQL 5.7 dokáže porozumět datům zapisovací sady a používat je, i když nemůže ji vygenerovat sama). Samozřejmě, replikace z 8.0 na 5.7 zní docela složitě (a není to jen proto, že 8.0 je stále beta). Za určitých okolností to může fungovat a může to urychlit využití CPU na vašich 5.7 slave.
Další změny v replikaci MySQL
Představení sad zápisů, i když je to nejzajímavější, není to jediná změna, která se stala s replikací MySQL v MySQL 8.0. Pojďme si projít některé další, také důležité změny. Pokud náhodou používáte master starší než MySQL 5.0, 8.0 nebude podporovat jeho binární formát protokolu. Neočekáváme, že uvidíme mnoho takových nastavení, ale pokud používáte velmi staré MySQL s replikací, je rozhodně čas na upgrade.
Výchozí hodnoty se změnily, aby bylo zajištěno, že replikace bude co možná nejbezpečnější:master_info_repository a relay_log_info_repository jsou nastaveny na TABLE. Expire_log_days byla také změněna – nyní je výchozí hodnota 30. Kromě expire_log_days , byla přidána nová proměnná binlog_expire_log_seconds , což umožňuje jemnější politiku rotace binlogů. Do binárního protokolu byla přidána některá další časová razítka pro zlepšení pozorovatelnosti replikačního zpoždění a zavedení mikrosekundové granularity.
V žádném případě se nejedná o úplný seznam změn a funkcí souvisejících s replikací MySQL. Pokud se chcete dozvědět více, můžete se podívat na seznamy změn MySQL. Ujistěte se, že jste zkontrolovali všechny z nich – dosud byly funkce přidány do všech verzí 8.0.
Jak můžete vidět, replikace MySQL se stále mění a zdokonaluje. Jak jsme řekli na začátku, musí to být pomalý proces, ale je opravdu skvělé vidět, co je před námi. Je také hezké vidět, jak práce pro replikaci skupin klesá a znovu se používá v „běžné“ replikaci MySQL.