MySQL neomezuje počet slave serverů, které se můžete připojit k hlavnímu serveru v topologii replikace. Jak se však počet podřízených jednotek zvyšuje, budou mít daň na hlavních zdrojích, protože binární protokoly budou muset být doručeny různým podřízeným, kteří pracují různými rychlostmi. Pokud je objem dat na masteru vysoký, samotné podávání binárních protokolů by mohlo zahltit síťové rozhraní masteru.
Klasickým řešením tohoto problému je nasazení binlog serveru – prostředního proxy serveru, který je umístěn mezi master a jeho podřízenými. Server binlog je nastaven jako slave k masteru a naopak funguje jako master k původní sadě slave. Přijímá binární log události od master, tyto události neaplikuje, ale podává je všem ostatním slave. Tímto způsobem je výrazně sníženo zatížení hlavního serveru a zároveň server binlog obsluhuje binlogy efektivněji podřízeným, protože nemusí provádět žádné další zpracování databázovým serverem.
Ripple je open source binlog server vyvinutý Pavlem Ivanovem. Blogový příspěvek od Percona s názvem MySQL Ripple:První dojem ze serveru MySQL Binlog Server poskytuje velmi dobrý úvod do nasazení a používání Ripple. Měl jsem příležitost prozkoumat Ripple podrobněji a chtěl jsem se podělit o svá pozorování prostřednictvím tohoto příspěvku.
1. Podpora replikace založené na GTID
Ripple podporuje pouze režim GTID, nikoli replikaci založenou na souborech a pozicích. Pokud váš hlavní server běží v režimu bez GTID, zobrazí se tato chyba z Ripple:
Nepodařilo se přečíst paket:Při čtení paketu ze serveru došlo k chybě:Vlákno odesílatele replikace nelze spustit v režimu AUTO_POSITION:tento server má GTID_MODE =OFF namísto ON.
Můžete zadat Server_id a UUID pro server HDO pomocí možností řádku cmd: -ripple_server_id a -ripple_server_uuid
Oba jsou volitelné parametry, a pokud nejsou specifikovány, Ripple použije výchozí server_id=112211 a uuid se vygeneruje automaticky.
2. Připojení k hlavnímu serveru pomocí replikačního uživatele a hesla
Při připojování k hlavnímu serveru můžete zadat uživatele a heslo replikace pomocí možností příkazového řádku:
-ripple_master_user a -ripple_master_password
3. Koncový bod připojení pro server Ripple
Můžete použít volby příkazového řádku -ripple_server_ports a -ripple_server_address k určení koncových bodů připojení pro server Ripple. Nezapomeňte zadat síťově přístupný název hostitele nebo IP adresu vašeho serveru Ripple jako -adresa_serveru_rippple. V opačném případě se ve výchozím nastavení Ripple naváže na localhost, a proto se k němu nebudete moci připojit vzdáleně.
4. Nastavení slave serveru Ripple
Příkaz CHANGE MASTER TO můžete použít k připojení svých otroků k replikaci ze serveru Ripple.
Abyste zajistili, že Ripple dokáže ověřit heslo, které používáte pro připojení k němu, musíte spustit Ripple zadáním možnosti -ripple_server_password_hash
Pokud například spustíte ripple server příkazem:
rippled -ripple_datadir=./binlog_server -ripple_master_address=
pro připojení z podřízeného zařízení můžete použít následující příkaz CHANGE MASTER TO:
CHANGE MASTER TO master_host='172.31.23.201', master_port=15000, master_password=’XpKWeZRNH5#satCI’, master_user=’rep’
Všimněte si, že hash hesla zadaný pro server Ripple odpovídá textovému heslu použitému v příkazu CHANGE MASTER TO. V současné době se Ripple neověřuje na základě uživatelských jmen a přijímá jakékoli uživatelské jméno, které není prázdné, pokud se heslo shoduje.
Prozkoumání MySQL Binlog Server – RippleClick To Tweet5. Správa serveru Ripple
Server Ripple je možné monitorovat a spravovat pomocí protokolu MySQL z libovolného standardního klienta MySQL. Existuje omezená sada podporovaných příkazů, které můžete vidět přímo ve zdrojovém kódu na stránce mysql-ripple GitHub.
Některé z užitečných příkazů jsou:
SELECT @@global.gtid_executed;– Chcete-li zobrazit SET GTID serveru Ripple na základě jeho stažených binárních protokolů.STOP SLAVE;– Odpojení serveru Ripple od hlavního serveru.START SLAVE;– Pro připojení serveru Ripple k hlavnímu serveru.
Známé problémy a návrhy na zlepšení
1. Neviděl jsem možnost nastavit kanál replikace SSL ze serveru Ripple na hlavní server
V důsledku toho se server Ripple nebude moci připojit k hlavnímu serveru, který vyžaduje šifrovaná připojení. Pokus o připojení bude mít za následek chybu:
0322 09:01:36.555124 14942 mysql_master_session.cc:164] Nepodařilo se připojit k hostiteli:
2. Nepodařilo se mi zprovoznit server Ripple s možností semi-synchronizace
Spustil jsem server Ripple pomocí volby -ripple_semi_sync_slave_enabled=true
Při připojení byl hlavní server schopen detekovat server Ripple jako podřízený server s povolenou semi-synchronizací.
mysql> zobrazuje stav jako 'rpl%';
--------------------------------- ---------------------
| Název_proměnné | Hodnota |
-------------------------------------------- ----------
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | ON |
| Rpl_semi_sync_slave_status | VYPNUTO |
-------------------------------------------- ----------
Při pokusu o provedení transakce v semi-synchronizovaném režimu se však čekalo na rpl_semi_sync_master_timeout, což bylo 180 000
mysql> vytvořit databázi d12;
Dotaz je v pořádku, ovlivněn 1 řádek (3 min 0,01 s)
Viděl jsem, že se polosynchronizace na hlavním serveru vypnula:
mysql> zobrazuje stav jako 'rpl%';
+-------------------------------- ------------+-------+
| Název_proměnné | Hodnota |
+------------------------------------------- -+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | VYPNUTO |
| Rpl_semi_sync_slave_status | VYPNUTO |
+------------------------------------------- -+-------+
Odpovídající úryvek z chybových protokolů mysql:
2020-03-21T10:05:56.000612Z 52 [Poznámka] Spustit binlog_dump na master_thread_id(52) slave_server(112211), pos(, 4)
2020-03-21T627Z05:05 Poznámka] Spustit semi-synchronizaci binlog_dump to slave (id_serveru:112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Varování] Časový limit čekání na odpověď binlogu (soubor:mysql-bin .000010, poz:350), polosynchronizace až do souboru , pozice 4.
2020-03-21T10:08:55.874044Z 2 [Poznámka] Polosynchronizovaná replikace vypnuta.
Na stránce MySQL Ripple Github byl hlášen problém podobným způsobem.
3. Problém při použití paralelní replikace pro podřízené servery Ripple
Viděl jsem, že vlákno SQL na slave se často zastaví s chybou:
Last_SQL_Error:Nelze spustit aktuální skupinu událostí v paralelním režimu. Došlo k události Gtid, název protokolu přenosu /mysql_data/relaylogs/relay-log.000005, pozice 27023962, která brání provedení této skupiny událostí v paralelním režimu. Důvod:Hlavní událost má logicky nesprávné časové razítko.
Analýza protokolu přenosu a pozice výše odhalila, že „sekvenční číslo“ transakce bylo v tomto okamžiku resetováno na 1. Vypátral jsem příčinu rotace binlogu na původní mistr. U přímých podřízených jednotek obvykle dochází k události rotace, kvůli které by se protokoly relé také otáčely na základě rotace hlavního binárního protokolu. Moje hodnocení je, že takové stavy lze detekovat a reset pořadového čísla lze zvládnout paralelními vlákny. Ale když se pořadové číslo změní bez rotace protokolů relé, vidíme, že paralelní vlákna selhávají.
Toto pozorování je hlášeno jako problém:selhání podřízeného paralelního vlákna při synchronizaci ze serveru binlog #26
4. Nástroj mysqlbinlog nefunguje na binárních protokolech vytvořených serverem Ripple
Při pokusu o spuštění nástroje mysqlbinlog v binárním protokolu došlo k chybě:
CHYBA:Chyba v Log_event::read_log_event():'Nalezena neplatná událost v binárním protokolu', data_len:43, event_type:-106
Tento problém je nastolen zde:Nelze otevřít binární soubory protokolu pomocí nástroje mysqlbinlog. #25
Autor to uznává jako známý problém. Domnívám se, že by bylo užitečné podporovat tento nástroj pro účely ladění.
To je prozatím zpráva z mého rychlého testování. Plánuji aktualizovat tento blogový příspěvek, jakmile narazím na další poznatky o Ripple. Celkově jsem zjistil, že je jednoduchý a přímočarý na použití a má potenciál stát se standardem pro binlog servery v prostředí MySQL.
|