Jak nastavit asynchronní replikaci z Galera Cluster na samostatný server MySQL s GTID

Hybridní replikace, tedy kombinace Galery a asynchronní replikace MySQL ve stejném nastavení, se stala mnohem snazší od zavedení GTID v MySQL 5.6. Přestože replikace ze samostatného serveru MySQL do clusteru Galera byla poměrně přímočará, udělat to obráceně (Galera → samostatný MySQL) bylo trochu náročnější. Minimálně do příchodu GTID.

Existuje několik dobrých důvodů pro připojení asynchronního slave zařízení ke clusteru Galera. Za prvé, dlouhotrvající dotazy typu reporting/OLAP na uzlu Galera mohou zpomalit celý cluster, pokud je zatížení sestavování tak intenzivní, že uzel musí vynaložit značné úsilí na jeho zvládnutí. Dotazy na hlášení lze tedy odesílat na samostatný server, čímž je Galera efektivně izolována od zátěže hlášení. V přístupu na opasky a podvazky může asynchronní slave sloužit také jako vzdálená živá záloha.

V tomto příspěvku na blogu vám ukážeme, jak replikovat Galera Cluster na server MySQL s GTID a jak převzít replikaci při selhání v případě, že hlavní uzel selže.

Hybridní replikace v MySQL 5.5

V MySQL 5.5 vyžaduje obnovení přerušené replikace, abyste určili poslední binární soubor protokolu a pozici, které jsou odlišné na všech uzlech Galera, pokud je povoleno binární protokolování. Tuto situaci můžeme ilustrovat na následujícím obrázku:

Pokud hlavní server MySQL selže, replikace se přeruší a slave se bude muset přepnout na jiného hlavního serveru. Budete muset vybrat nový uzel Galera a ručně určit nový binární soubor protokolu a pozici poslední transakce provedené podřízeným zařízením. Další možností je vypsat data z nového hlavního uzlu, obnovit je na podřízeném uzlu a spustit replikaci s novým hlavním uzlem. Tyto možnosti jsou samozřejmě proveditelné, ale ve výrobě nejsou příliš praktické.

Jak GTID řeší problém

GTID (Global Transaction Identifier) ​​poskytuje lepší mapování transakcí mezi uzly a je podporován v MySQL 5.6. V Galera Cluster budou všechny uzly generovat různé soubory binlog. Události binlog jsou stejné a ve stejném pořadí, ale názvy souborů binlog a posuny se mohou lišit. S GTID mohou podřízení vidět jedinečnou transakci přicházející od několika masterů, a to by se mohlo snadno namapovat do seznamu provedení slave, pokud bude potřeba restartovat nebo obnovit replikaci.

Všechny potřebné informace pro synchronizaci s masterem jsou získávány přímo z replikačního streamu. To znamená, že když pro replikaci používáte GTID, nemusíte do příkazu CHANGE MASTER TO zahrnout možnosti MASTER_LOG_FILE nebo MASTER_LOG_POS. Místo toho je nutné pouze povolit volbu MASTER_AUTO_POSITION. Další podrobnosti o GTID naleznete na stránce Dokumentace MySQL.

Ruční nastavení hybridní replikace

Než budete pokračovat s tímto nastavením, ujistěte se, že uzly Galera (hlavní) a podřízené (slave) běží na MySQL 5.6. V Galeře máme databázi nazvanou sbtest, kterou replikujeme do slave uzlu.

1. Povolte požadované možnosti replikace zadáním následujících řádků v my.cnf každého uzlu DB (včetně podřízeného uzlu):

Pro hlavní uzly (Galera):

gtid_mode=ON
log_bin=binlog
log_slave_updates=1
enforce_gtid_consistency
expire_logs_days=7
server_id=1         # 1 for master1, 2 for master2, 3 for master3
binlog_format=ROW

Pro podřízený uzel:

gtid_mode=ON
log_bin=binlog
log_slave_updates=1
enforce_gtid_consistency
expire_logs_days=7
server_id=101         # 101 for slave
binlog_format=ROW
replicate_do_db=sbtest
slave_net_timeout=60

2. Proveďte opakovaný restart clusteru Galera Cluster (z uživatelského rozhraní ClusterControl> Správa> Upgrade> Rolling Restart). Tím se znovu načte každý uzel s novými konfiguracemi a povolí se GTID. Restartujte také slave.

3. Vytvořte uživatele slave replikace a spusťte následující příkaz na jednom z uzlů Galera:

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%' IDENTIFIED BY 'slavepassword';

4. Přihlaste se do slave a výpisu databáze sbtest z jednoho z uzlů Galera:

$ mysqldump -uroot -p -h192.168.0.201 --single-transaction --skip-add-locks --triggers --routines --events sbtest > sbtest.sql

5. Obnovte soubor výpisu na podřízený server:

$ mysql -uroot -p < sbtest.sql

6. Spusťte replikaci na podřízeném uzlu:

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.201', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

Chcete-li ověřit, zda replikace běží správně, prozkoumejte výstup stavu slave:

mysql> SHOW SLAVE STATUS\G
       ...
       Slave_IO_Running: Yes
       Slave_SQL_Running: Yes
       ...

Nastavení hybridní replikace pomocí ClusterControl

V předchozím odstavci jsme popsali všechny nezbytné kroky k povolení binárních protokolů, restartování uzlu clusteru po uzlu, zkopírování dat a následnému nastavení replikace. Postup je zdlouhavý a v jednom z těchto kroků se můžete snadno dopustit chyby. V ClusterControl jsme zautomatizovali všechny potřebné kroky.

1. Pro uživatele ClusterControl můžete přejít na uzly na stránce Nodes a povolit binární protokolování.

Otevře se dialog, který vám umožní nastavit expiraci binárního protokolu, povolit GTID a auto restart.

Tím se spustí úloha, která bezpečně zapíše tyto změny do konfigurace, vytvoří uživatele replikace se správnými oprávněními a bezpečně restartuje uzel.

Opakujte tento proces pro každý uzel Galera v clusteru, dokud všechny uzly neoznačí, že jsou hlavní.

2. Přidejte slave asynchronní replikaci do klastru

A to je vše, co musíte udělat. Celý proces popsaný v předchozím odstavci byl automatizován pomocí ClusterControl.

Změna mistra

Pokud určený master selže, slave se pokusí znovu připojit v hodnotě slave_net_timeout (naše nastavení je 60 sekund - výchozí je 1 hodina). Ve stavu slave byste měli vidět následující chybu:

       Last_IO_Errno: 2003
       Last_IO_Error: error reconnecting to master '[email protected]:3306' - retry-time: 60  retries: 1

Protože používáme Galera s povoleným GTID, hlavní převzetí služeb při selhání je podporováno prostřednictvím ClusterControl, když Automatické obnovení clusteru a uzlů bylo povoleno. Ať už by hlavní uzel selhal kvůli síťové konektivitě nebo z jakéhokoli jiného důvodu, ClusterControl automaticky přejde na jiný nejvhodnější hlavní uzel v clusteru.

Pokud chcete provést převzetí služeb při selhání ručně, jednoduše změňte hlavní uzel následovně:

mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.202', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

V některých případech se po změně hlavního uzlu můžete setkat s chybou „Duplicitní záznam .. pro klíč“:

       Last_Errno: 1062
       Last_Error: Could not execute Write_rows event on table sbtest.sbtest; Duplicate entry '1089775' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysqld-bin.000009, end_log_pos 85789000

Ve starších verzích MySQL stačí použít SET GLOBAL SQL_SLAVE_SKIP_COUNTER =n přeskočit příkazy, ale nefunguje to s GTID. Miguel z Percony napsal skvělý blogový příspěvek o tom, jak to napravit vložením prázdných transakcí.

Dalším přístupem pro menší databáze by také mohlo být získat nový výpis z libovolného z dostupných uzlů Galera, obnovit jej a použít příkaz RESET MASTER:

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> DROP SCHEMA sbtest; CREATE SCHEMA sbtest; USE sbtest;
mysql> SOURCE /root/sbtest_from_galera2.sql; -- repeat step #4 above to get this dump
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.202', MASTER_PORT = 3306, MASTER_USER = 'slave', MASTER_PASSWORD = 'slavepassword', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;

K ověření integrity replikace můžete také použít pt-table-checksum, více informací v tomto příspěvku na blogu.

Poznámka:Vzhledem k tomu, že při replikaci MySQL je slave aplikace ve výchozím nastavení stále jednovláknová, neočekávejte, že výkon asynchronní replikace bude stejný jako u paralelní replikace Galery. Pro MySQL 5.6 a 5.7 existují možnosti, jak provést asynchronní replikaci paralelně na podřízených uzlech, ale v zásadě tato replikace stále závisí na správném pořadí transakcí uvnitř stejného schématu. Pokud je zatížení replikace intenzivní a nepřetržité, zpoždění podřízeného zařízení bude stále narůstat. Viděli jsme případy, kdy otrok nikdy nemohl dohnat pána.