Hur man ställer in asynkron replikering från Galera Cluster till Fristående MySQL-server med GTID

Hybridreplikering, det vill säga att kombinera Galera och asynkron MySQL-replikering i samma setup, blev mycket enklare sedan GTID introducerades i MySQL 5.6. Även om det var ganska enkelt att replikera från en fristående MySQL-server till ett Galera-kluster, var det lite mer utmanande att göra det tvärtom (Galera → fristående MySQL). Åtminstone fram till ankomsten av GTID.

Det finns några goda skäl att koppla en asynkron slav till ett Galera-kluster. För det första kan långvariga förfrågningar av rapportering/OLAP-typ på en Galera-nod sakta ner ett helt kluster, om rapporteringsbelastningen är så intensiv att noden måste lägga ner avsevärd ansträngning på att hantera den. Så rapporteringsfrågor kan skickas till en fristående server, vilket effektivt isolerar Galera från rapporteringsbelastningen. I ett angrepp med bälten och hängslen kan en asynkron slav också fungera som en fjärrstyrd direktbackup.

I det här blogginlägget kommer vi att visa dig hur du replikerar ett Galera-kluster till en MySQL-server med GTID, och hur du failover replikeringen om masternoden misslyckas.

Hybridreplikering i MySQL 5.5

I MySQL 5.5 kräver att du återupptar en trasig replikering att du bestämmer den sista binära loggfilen och positionen, som är distinkta på alla Galera-noder om binär loggning är aktiverad. Vi kan illustrera denna situation med följande figur:

Om MySQL-mastern misslyckas, avbryts replikeringen och slaven måste byta över till en annan master. Du måste välja en ny Galera-nod och manuellt bestämma en ny binär loggfil och positionen för den senaste transaktionen som utfördes av slaven. Ett annat alternativ är att dumpa data från den nya masternoden, återställa den på slav och starta replikering med den nya masternoden. Dessa alternativ är naturligtvis genomförbara, men inte särskilt praktiska i produktionen.

Hur GTID löser problemet

GTID (Global Transaction Identifier) ​​ger en bättre transaktionskartläggning över noder och stöds i MySQL 5.6. I Galera Cluster kommer alla noder att generera olika binlogfiler. Binlog-händelserna är desamma och i samma ordning, men binlogfilnamnen och förskjutningarna kan variera. Med GTID kan slavar se en unik transaktion som kommer in från flera masters och denna kan lätt mappas till slavexekveringslistan om den behöver starta om eller återuppta replikeringen.

All nödvändig information för synkronisering med mastern erhålls direkt från replikeringsströmmen. Det betyder att när du använder GTID för replikering behöver du inte inkludera MASTER_LOG_FILE eller MASTER_LOG_POS alternativ i CHANGE MASTER TO-satsen. Istället är det bara nödvändigt att aktivera alternativet MASTER_AUTO_POSITION. Du kan hitta mer information om GTID på MySQL-dokumentationssidan.

Ställa in hybridreplikering för hand

Se till att Galera-noderna (masters) och slav(ar) körs på MySQL 5.6 innan du fortsätter med den här installationen. Vi har en databas som heter sbtest i Galera, som vi kommer att replikera till slavnoden.

1. Aktivera nödvändiga replikeringsalternativ genom att ange följande rader i varje DB-nods my.cnf (inklusive slavnoden):

För huvudnoder (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

För slavnod:

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. Utför en rullande klusterstart av Galera Cluster (från ClusterControl UI> Hantera> Uppgradera> Rullande omstart). Detta kommer att ladda om varje nod med de nya konfigurationerna och aktivera GTID. Starta om slaven också.

3. Skapa en slavreplikeringsanvändare och kör följande sats på en av Galera-noderna:

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

4. Logga in på slaven och dump databasen sbtest från en av Galera-noderna:

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

5. Återställ dumpfilen till slavservern:

$ mysql -uroot -p < sbtest.sql

6. Starta replikering på slavnoden:

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;

För att verifiera att replikeringen körs korrekt, undersök utdata för slavstatus:

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

Konfigurera hybridreplikering med ClusterControl

I föregående stycke beskrev vi alla nödvändiga steg för att aktivera de binära loggarna, starta om klusternod för nod, kopiera data och sedan ställa in replikering. Proceduren är en tråkig uppgift och du kan lätt göra fel i ett av dessa steg. I ClusterControl har vi automatiserat alla nödvändiga steg.

1. För ClusterControl-användare kan du gå till noderna på sidan Noder och aktivera binär loggning.

Detta öppnar en dialog som låter dig ställa in den binära loggens utgång, aktivera GTID och automatisk omstart.

Detta initierar ett jobb som säkert kommer att skriva dessa ändringar till konfigurationen, skapa replikeringsanvändare med rätt tillstånd och starta om noden på ett säkert sätt.

Upprepa denna process för varje Galera-nod i klustret, tills alla noder indikerar att de är master.

2. Lägg till den asynkrona replikeringsslaven till klustret

Och det här är allt du behöver göra. Hela processen som beskrivs i föregående stycke har automatiserats av ClusterControl.

Ändra master

Om den angivna mastern går ner kommer slaven att försöka återansluta igen i slave_net_timeout-värdet (vår inställning är 60 sekunder - standard är 1 timme). Du bör se följande fel på slavstatus:

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

Eftersom vi använder Galera med GTID aktiverat, stöds master failover via ClusterControl när Cluster and Node Auto Recovery har aktiverats. Oavsett om mastern skulle misslyckas på grund av nätverksanslutning eller någon annan anledning, kommer ClusterControl automatiskt att misslyckas till den mest lämpliga andra masternoden i klustret.

Om du vill utföra failover manuellt, ändra helt enkelt huvudnoden enligt följande:

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;

I vissa fall kan du stöta på ett "Duplicate entry .. for key"-fel efter att huvudnoden ändrats:

       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

I äldre versioner av MySQL kan du bara använda SET GLOBAL SQL_SLAVE_SKIP_COUNTER =n att hoppa över uttalanden, men det fungerar inte med GTID. Miguel från Percona skrev ett bra blogginlägg om hur man reparerar detta genom att injicera tomma transaktioner.

Ett annat tillvägagångssätt, för mindre databaser, kan också vara att bara hämta en ny dump från någon av de tillgängliga Galera-noderna, återställa den och använda RESET MASTER-satsen:

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;

Du kan också använda pt-table-checksum för att verifiera replikeringsintegriteten, mer information i det här blogginlägget.

Obs:Eftersom slavapplikatorn i MySQL-replikering som standard fortfarande är entrådad, förvänta dig inte att prestanda för asynkronreplikering är densamma som Galeras parallella replikering. För MySQL 5.6 och 5.7 finns det alternativ att få den asynkrona replikeringen att exekveras parallellt på slavnoderna, men i princip är denna replikering fortfarande beroende av att den korrekta ordningen av transaktioner inom samma schema ska ske. Om replikeringsbelastningen är intensiv och kontinuerlig kommer slavfördröjningen bara att fortsätta växa. Vi har sett fall där slav aldrig kunde komma ikapp befälhavaren.