Sådan konfigureres asynkron replikering fra Galera Cluster til selvstændig MySQL-server med GTID

Hybridreplikering, dvs. at kombinere Galera og asynkron MySQL-replikering i samme opsætning, blev meget lettere, siden GTID blev introduceret i MySQL 5.6. Selvom det var ret ligetil at replikere fra en selvstændig MySQL-server til en Galera Cluster, var det lidt mere udfordrende at gøre det omvendt (Galera → selvstændig MySQL). I hvert fald indtil ankomsten af ​​GTID.

Der er et par gode grunde til at knytte en asynkron slave til en Galera Cluster. For det første kan langvarige forespørgsler af rapportering/OLAP-type på en Galera-node bremse en hel klynge, hvis rapporteringsbelastningen er så intensiv, at noden skal bruge en betydelig indsats på at klare det. Så rapporteringsforespørgsler kan sendes til en selvstændig server, hvilket effektivt isolerer Galera fra rapporteringsbelastningen. I en tilgang med bælter og seler kan en asynkron slave også fungere som en ekstern live backup.

I dette blogindlæg viser vi dig, hvordan du replikerer en Galera Cluster til en MySQL-server med GTID, og ​​hvordan du failover replikationen, hvis masternoden fejler.

Hybrid replikering i MySQL 5.5

I MySQL 5.5 kræver genoptagelse af en ødelagt replikering, at du bestemmer den sidste binære logfil og position, som er forskellige på alle Galera-noder, hvis binær logning er aktiveret. Vi kan illustrere denne situation med følgende figur:

Hvis MySQL-masteren fejler, bryder replikeringen, og slaven bliver nødt til at skifte til en anden master. Du skal vælge en ny Galera-node og manuelt bestemme en ny binær logfil og positionen for den sidste transaktion udført af slaven. En anden mulighed er at dumpe dataene fra den nye masterknude, gendanne dem på slave og starte replikering med den nye masterknude. Disse muligheder er selvfølgelig gennemførlige, men ikke særlig praktiske i produktionen.

Hvordan GTID løser problemet

GTID (Global Transaction Identifier) ​​giver en bedre transaktionskortlægning på tværs af noder og understøttes i MySQL 5.6. I Galera Cluster vil alle noder generere forskellige binlog-filer. Binlog-begivenhederne er de samme og i samme rækkefølge, men binlog-filnavnene og forskydninger kan variere. Med GTID kan slaver se en unik transaktion, der kommer ind fra flere mastere, og denne kan nemt blive mappet til slaveudførelseslisten, hvis den skal genstarte eller genoptage replikering.

Al nødvendig information til synkronisering med masteren hentes direkte fra replikeringsstrømmen. Dette betyder, at når du bruger GTID'er til replikering, behøver du ikke inkludere MASTER_LOG_FILE eller MASTER_LOG_POS muligheder i CHANGE MASTER TO-sætningen. I stedet er det kun nødvendigt at aktivere MASTER_AUTO_POSITION-indstillingen. Du kan finde flere detaljer om GTID'et på MySQL-dokumentationssiden.

Opsætning af hybridreplikering i hånden

Sørg for, at Galera-knuderne (mastere) og slave(r) kører på MySQL 5.6, før du fortsætter med denne opsætning. Vi har en database kaldet sbtest i Galera, som vi vil replikere til slavenoden.

1. Aktiver nødvendige replikeringsmuligheder ved at angive følgende linjer inde i hver DB-nods my.cnf (inklusive slaveknuden):

For master (Galera) noder:

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

For slaveknude:

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. Udfør en cluster rullende genstart af Galera Cluster (fra ClusterControl UI> Administrer> Opgrader> Rullende genstart). Dette vil genindlæse hver node med de nye konfigurationer og aktivere GTID. Genstart også slaven.

3. Opret en slave-replikeringsbruger og kør følgende sætning på en af ​​Galera-knuderne:

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

4. Log ind på slaven og dump databasen sbtest fra en af ​​Galera-knuderne:

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

5. Gendan dumpfilen på slaveserveren:

$ mysql -uroot -p < sbtest.sql

6. Start replikering på slavenoden:

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;

For at kontrollere, at replikering kører korrekt, skal du undersøge outputtet af slavestatus:

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

Opsætning af hybridreplikering ved hjælp af ClusterControl

I det foregående afsnit beskrev vi alle de nødvendige trin for at aktivere de binære logfiler, genstarte klyngen node for node, kopiere dataene og derefter opsætte replikering. Proceduren er en kedelig opgave, og du kan nemt lave fejl i et af disse trin. I ClusterControl har vi automatiseret alle de nødvendige trin.

1. For ClusterControl-brugere kan du gå til noderne på siden Nodes og aktivere binær logning.

Dette åbner en dialog, der giver dig mulighed for at indstille den binære log-udløb, aktivere GTID og automatisk genstart.

Dette starter et job, som sikkert vil skrive disse ændringer til konfigurationen, oprette replikeringsbrugere med de rigtige tildelinger og genstarte noden sikkert.

Gentag denne proces for hver Galera-node i klyngen, indtil alle noder angiver, at de er master.

2. Tilføj den asynkrone replikeringsslave til klyngen

Og det er alt, du skal gøre. Hele processen beskrevet i det foregående afsnit er blevet automatiseret af ClusterControl.

Ændring af master

Hvis den udpegede master går ned, vil slaven forsøge igen at oprette forbindelse igen i slave_net_timeout værdi (vores opsætning er 60 sekunder - standard er 1 time). Du skulle se følgende fejl på slavestatus:

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

Da vi bruger Galera med GTID aktiveret, understøttes master failover via ClusterControl, når Cluster and Node Auto Recovery er blevet aktiveret. Uanset om masteren ville svigte på grund af netværksforbindelse eller en anden årsag, vil ClusterControl automatisk fejle over til den mest egnede anden masterknude i klyngen.

Hvis du ønsker at udføre failoveren manuelt, skal du blot ændre masternoden som følger:

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 nogle tilfælde kan du støde på en "Duplicate entry .. for key"-fejl, efter at masternoden er ændret:

       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 af MySQL kan du bare bruge SET GLOBAL SQL_SLAVE_SKIP_COUNTER =n at springe udsagn over, men det virker ikke med GTID. Miguel fra Percona skrev et godt blogindlæg om, hvordan man reparerer dette ved at injicere tomme transaktioner.

En anden tilgang, for mindre databaser, kunne også være at få et nyt dump fra en hvilken som helst af de tilgængelige Galera-noder, gendanne den og bruge RESET MASTER-sætning:

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 også bruge pt-table-checksum til at verificere replikeringsintegriteten, mere information i dette blogindlæg.

Bemærk:Da slaveapplikationen i MySQL-replikering som standard stadig er enkelt-trådet, skal du ikke forvente, at den asynkrone replikeringsydelse er den samme som Galeras parallelle replikering. For MySQL 5.6 og 5.7 er der muligheder for at få den asynkrone replikering til at udføres parallelt på slaveknuderne, men i princippet er denne replikering stadig afhængig af den korrekte rækkefølge af transaktioner inde i det samme skema. Hvis replikationsbelastningen er intensiv og kontinuerlig, vil slaveforsinkelsen bare blive ved med at vokse. Vi har set tilfælde, hvor slave aldrig kunne indhente mesteren.