Asynchrone replicatie instellen van Galera Cluster naar standalone MySQL-server met GTID

Hybride replicatie, d.w.z. het combineren van Galera en asynchrone MySQL-replicatie in dezelfde opstelling, werd veel eenvoudiger sinds GTID werd geïntroduceerd in MySQL 5.6. Hoewel het vrij eenvoudig was om van een standalone MySQL-server naar een Galera Cluster te repliceren, was het een beetje uitdagender om het andersom te doen (Galera → standalone MySQL). In ieder geval tot de komst van GTID.

Er zijn een paar goede redenen om een ​​asynchrone slave aan een Galera Cluster te koppelen. Ten eerste kunnen langlopende rapportage/OLAP-query's op een Galera-knooppunt een hele cluster vertragen, als de rapportagebelasting zo intensief is dat het knooppunt veel moeite moet doen om ermee om te gaan. Rapportagevragen kunnen dus naar een zelfstandige server worden gestuurd, waardoor Galera effectief wordt geïsoleerd van de rapportagelast. Bij een benadering met riemen en bretels kan een asynchrone slaaf ook dienen als een live back-up op afstand.

In deze blogpost laten we u zien hoe u een Galera-cluster repliceert naar een MySQL-server met GTID en hoe u een failover uitvoert voor de replicatie in het geval dat het hoofdknooppunt faalt.

Hybride replicatie in MySQL 5.5

In MySQL 5.5 moet u voor het hervatten van een verbroken replicatie het laatste binaire logbestand en de laatste positie bepalen, die verschillend zijn op alle Galera-knooppunten als binaire logging is ingeschakeld. We kunnen deze situatie illustreren met de volgende figuur:

Als de MySQL-master uitvalt, wordt de replicatie onderbroken en moet de slave overschakelen naar een andere master. U moet een nieuwe Galera-node kiezen en handmatig een nieuw binair logbestand bepalen en de positie van de laatste transactie die door de slave is uitgevoerd. Een andere optie is om de gegevens van het nieuwe masterknooppunt te dumpen, het op slave te herstellen en de replicatie met het nieuwe masterknooppunt te starten. Deze opties zijn natuurlijk te doen, maar niet erg praktisch in productie.

Hoe GTID het probleem oplost

GTID (Global Transaction Identifier) ​​biedt een betere toewijzing van transacties tussen knooppunten en wordt ondersteund in MySQL 5.6. In Galera Cluster zullen alle nodes verschillende binlog-bestanden genereren. De binlog-gebeurtenissen zijn hetzelfde en in dezelfde volgorde, maar de binlog-bestandsnamen en offsets kunnen variëren. Met GTID kunnen slaves een unieke transactie zien binnenkomen van verschillende masters en dit kan gemakkelijk worden toegewezen aan de slave-uitvoeringslijst als het opnieuw moet worden gestart of de replicatie moet worden hervat.

Alle benodigde informatie voor het synchroniseren met de master wordt direct uit de replicatiestroom gehaald. Dit betekent dat wanneer u GTID's gebruikt voor replicatie, u geen MASTER_LOG_FILE- of MASTER_LOG_POS-opties hoeft op te nemen in de CHANGE MASTER TO-instructie. In plaats daarvan is het alleen nodig om de MASTER_AUTO_POSITION optie in te schakelen. U kunt meer details over de GTID vinden op de MySQL-documentatiepagina.

Hybride replicatie handmatig instellen

Zorg ervoor dat de Galera-knooppunten (masters) en slave(s) op MySQL 5.6 draaien voordat u doorgaat met deze installatie. We hebben een database met de naam sbtest in Galera, die we zullen repliceren naar de slave-node.

1. Schakel de vereiste replicatie-opties in door de volgende regels op te geven in my.cnf van elk DB-knooppunt (inclusief het slave-knooppunt):

Voor hoofdknooppunten (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

Voor slave-knooppunt:

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. Voer een cluster rolling herstart van de Galera Cluster uit (vanuit ClusterControl UI> Manage> Upgrade> Rolling Restart). Hierdoor wordt elk knooppunt opnieuw geladen met de nieuwe configuraties en wordt GTID ingeschakeld. Start ook de slave opnieuw.

3. Maak een slave-replicatiegebruiker aan en voer de volgende instructie uit op een van de Galera-knooppunten:

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

4. Log in op de slave en dump database sbtest vanaf een van de Galera-knooppunten:

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

5. Herstel het dumpbestand op de slave-server:

$ mysql -uroot -p < sbtest.sql

6. Start replicatie op de slave-node:

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;

Om te controleren of de replicatie correct wordt uitgevoerd, bekijkt u de uitvoer van de slave-status:

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

Hybride replicatie instellen met ClusterControl

In de vorige paragraaf hebben we alle noodzakelijke stappen beschreven om de binaire logboeken in te schakelen, het clusterknooppunt voor knooppunt opnieuw te starten, de gegevens te kopiëren en vervolgens replicatie in te stellen. De procedure is een vervelende taak en u kunt gemakkelijk fouten maken in een van deze stappen. In ClusterControl hebben we alle noodzakelijke stappen geautomatiseerd.

1. Voor ClusterControl-gebruikers kunt u naar de knooppunten op de pagina Knooppunten gaan en binaire logboekregistratie inschakelen.

Dit opent een dialoog waarin je de binaire logboekvervaldag kunt instellen, GTID kunt inschakelen en automatisch opnieuw kunt opstarten.

Dit initieert een taak die deze wijzigingen veilig in de configuratie schrijft, replicatiegebruikers met de juiste machtigingen maakt en het knooppunt veilig herstart.

Herhaal dit proces voor elke Galera-node in het cluster, totdat alle nodes aangeven dat ze master zijn.

2. Voeg de asynchrone replicatieslave toe aan het cluster

En dit is alles wat je hoeft te doen. Het gehele proces beschreven in de vorige paragraaf is geautomatiseerd door ClusterControl.

Van meester veranderen

Als de aangewezen master uitvalt, zal de slave opnieuw proberen opnieuw verbinding te maken met de waarde slave_net_timeout (onze instelling is 60 seconden - standaard is 1 uur). U zou de volgende foutmelding over de slave-status moeten zien:

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

Aangezien we Galera gebruiken met GTID ingeschakeld, wordt master-failover ondersteund via ClusterControl wanneer Cluster en Node Auto Recovery is ingeschakeld. Of de master nu zou mislukken vanwege netwerkconnectiviteit of een andere reden, ClusterControl zal automatisch een failover uitvoeren naar het meest geschikte andere masterknooppunt in het cluster.

Als u de failover handmatig wilt uitvoeren, wijzigt u eenvoudig het hoofdknooppunt als volgt:

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;

In sommige gevallen kunt u een fout "Dubbele invoer .. voor sleutel" tegenkomen nadat het hoofdknooppunt is gewijzigd:

       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

In oudere versies van MySQL kunt u gewoon SET GLOBAL SQL_SLAVE_SKIP_COUNTER =n gebruiken om instructies over te slaan, maar het werkt niet met GTID. Miguel uit Percona schreef een geweldige blogpost over hoe je dit kunt repareren door lege transacties te injecteren.

Een andere benadering, voor kleinere databases, zou ook kunnen zijn om gewoon een verse dump van een van de beschikbare Galera-knooppunten te halen, deze te herstellen en de RESET MASTER-instructie te gebruiken:

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;

U kunt ook pt-table-checksum gebruiken om de replicatie-integriteit te verifiëren, meer informatie in deze blogpost.

Opmerking:aangezien in MySQL-replicatie de slave-applier standaard nog steeds single-threaded is, moet u niet verwachten dat de asynchrone replicatieprestaties hetzelfde zijn als de parallelle replicatie van Galera. Voor MySQL 5.6 en 5.7 zijn er opties om de asynchrone replicatie parallel uit te voeren op de slave-knooppunten, maar in principe is deze replicatie nog steeds afhankelijk van de juiste volgorde van transacties binnen hetzelfde schema. Als de replicatiebelasting intensief en continu is, zal de slave-lag alleen maar blijven groeien. We hebben gevallen gezien waarin de slaaf de meester nooit kon inhalen.