MySQL Galera-cluster herstellen van een asynchrone slaaf

Inleiding

Bij het uitvoeren van Galera Cluster is het gebruikelijk om een ​​of meer asynchrone slaves in hetzelfde of in een ander datacenter toe te voegen. Dit biedt ons een noodplan met een lage RTO en lage bedrijfskosten. In het geval van een onherstelbaar probleem in ons cluster, kunnen we er snel een failover naar uitvoeren, zodat applicaties toegang kunnen blijven houden tot gegevens.

Bij gebruik van dit type setup kunnen we ons cluster niet zomaar opnieuw opbouwen vanaf een eerdere back-up. Aangezien de asynchrone slaaf nu de nieuwe bron van waarheid is, moeten we het cluster ervan opnieuw opbouwen.

Dit betekent niet dat we maar één manier hebben om het te doen, misschien is er zelfs een betere manier! Voel je vrij om ons je suggesties te geven in het opmerkingengedeelte aan het einde van dit bericht.

Topologie

Hierboven zien we een voorbeeldtopologie met Galera Cluster en een asynchrone replica/slave.

Vervolgens zullen we zien hoe we ons cluster opnieuw kunnen maken, beginnend bij de slaaf, in het geval dat we zoiets als dit vinden:

Als we naar de vorige afbeelding kijken, kunnen we zien dat onze 3 Galera-knooppunten niet beschikbaar zijn. Onze slave kan geen verbinding maken met de Galera-master, maar is in de status "Up and running".

Slaaf promoten

Omdat onze slaaf goed werkt, kunnen we hem promoveren tot master en onze applicaties ernaar verwijzen. Hiervoor moeten we de alleen-lezen parameter in onze slave uitschakelen en de slave-configuratie resetten.

In onze slaaf (mysql1):

mysql> SET GLOBAL read_only=0;
Query OK, 0 rows affected (0.00 sec)
mysql> STOP SLAVE;
Query OK, 0 rows affected (0.00 sec)
mysql> RESET SLAVE;
Query OK, 0 rows affected (0.18 sec)

Nieuw cluster maken

Om vervolgens het herstel van ons mislukte cluster te starten, zullen we een nieuw Galera-cluster maken. Dit kan eenvoudig via ClusterControl ClusterControl, scroll verder naar beneden in deze blog om te zien hoe.

Zodra we ons nieuwe Galera-cluster hebben geïmplementeerd, hebben we zoiets als het volgende:

Replicatie

We moeten ervoor zorgen dat we de replicatieparameters hebben geconfigureerd.

Voor Galera-knooppunten (galera1, galera2, galera3):

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin = /var/lib/mysql-binlog/binlog
log_slave_updates = ON
gtid_mode = ON
enforce_gtid_consistency = true
relay_log = relay-bin
expire_logs_days = 7

Voor hoofdknooppunt (mysql1):

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON
sync_binlog=1
report_host=<HOSTNAME or IP>    # Local server

Om ervoor te zorgen dat onze nieuwe slaaf (galera1) verbinding maakt met onze nieuwe master (mysql1), moeten we een gebruiker met replicatierechten in onze master maken.

In onze nieuwe master (mysql1):

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';

Opmerking:we kunnen het "%" vervangen door het IP-adres van het Galera-clusterknooppunt dat onze slaaf zal zijn, in ons voorbeeld galera1.

Back-up

Als we het niet hebben, moeten we een consistente back-up van onze master (mysql1) maken en deze in onze nieuwe Galera-cluster laden. Hiervoor kunnen we de XtraBackup-tool of mysqldump gebruiken. Laten we beide opties bekijken.

In ons voorbeeld gebruiken we de sakila-database die beschikbaar is om te testen.

XtraBackup-tool

We genereren de back-up in de nieuwe master (mysql1). In ons geval sturen we het naar de lokale map /root/backup:

$ innobackupex /root/backup/

We moeten de boodschap krijgen:

180705 22:08:14 completed OK!

We comprimeren de back-up en sturen deze naar het knooppunt dat onze slaaf zal zijn (galera1):

$ cd /root/backup
$ tar zcvf 2018-07-05_22-08-07.tar.gz 2018-07-05_22-08-07
$ scp /root/backup/2018-07-05_22-08-07.tar.gz galera1:/root/backup/

Pak in galera1 de back-up uit:

$ tar zxvf /root/backup/2018-07-05_22-08-07.tar.gz

We stoppen het cluster (als het is gestart). Hiervoor stoppen we de mysql-services van de 3 nodes:

$ service mysql stop

In galera1 hernoemen we de gegevensmap van mysql en laden de back-up:

$ mv /var/lib/mysql /var/lib/mysql.bak
$ innobackupex --copy-back /root/backup/2018-07-05_22-08-07

We moeten de boodschap krijgen:

180705 23:00:01 completed OK!

We wijzen de juiste rechten toe aan de gegevensmap:

$ chown -R mysql.mysql /var/lib/mysql

Dan moeten we het cluster initialiseren.

Zodra het eerste knooppunt is geïnitialiseerd, moeten we de MySQL-service starten voor de resterende knooppunten, waarbij alle eerdere kopieën van het bestand grastate.dat worden verwijderd, en vervolgens controleren of onze gegevens zijn bijgewerkt.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Opmerking:controleer of de gebruiker die door XtraBackup wordt gebruikt, is gemaakt in ons geïnitialiseerde knooppunt en hetzelfde is in elk knooppunt.

mysqldump

Over het algemeen raden we af om het met mysqldump te doen, omdat het met een grote hoeveelheid gegevens vrij traag kan zijn. Maar het is een alternatief om de taak uit te voeren.

We genereren de back-up in de nieuwe master (mysql1):

$ mysqldump -uroot -p --single-transaction --skip-add-locks --triggers --routines --events --databases sakila > /root/backup/sakila_dump.sql

We comprimeren het en sturen het naar onze slave-node (galera1):

$ gzip /root/backup/sakila_dump.sql
$ scp /root/backup/sakila_dump.sql.gz galera1:/root/backup/

We laden de dump in galera1.

$ gunzip /root/backup/sakila_dump.sql.gz
$ mysql -p < /root/backup/sakila_dump.sql

Wanneer de dump in galera1 is geladen, moeten we de MySQL-service opnieuw starten op de resterende knooppunten, het bestand grastate.dat verwijderen en controleren of onze gegevens zijn bijgewerkt.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Start replicatieslave

Ongeacht welke optie we kiezen, XtraBackup of mysqldump, als alles goed is gegaan, kunnen we in deze stap replicatie al inschakelen in het knooppunt dat onze slaaf zal zijn (galera1).

$ mysql> CHANGE MASTER TO MASTER_HOST = 'mysql1', MASTER_PORT = 3306, MASTER_USER = 'slave_user', MASTER_PASSWORD = 'slave_password', MASTER_AUTO_POSITION = 1;
$ mysql> START SLAVE;

We controleren of de slaaf werkt:

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

Op dit moment hebben we zoiets als het volgende:

Nadat NewGalera1 up-to-date is, kunnen we de toepassing opnieuw naar ons nieuwe Galera-cluster verwijzen en de asynchrone replicatie opnieuw configureren.

Clusterbeheer

Zoals we eerder vermeldden, kunnen we met ClusterControl verschillende van de hierboven genoemde taken in een paar simpele klikken uitvoeren. Het heeft ook automatische herstelopties, voor zowel de knooppunten als het cluster. Laten we eens kijken naar enkele taken waarmee het kan helpen.

Om een ​​implementatie uit te voeren, selecteert u eenvoudig de optie "Deploy Database Cluster" en volgt u de instructies die verschijnen.

We kunnen kiezen tussen verschillende soorten technologieën en leveranciers. We moeten Gebruiker, Sleutel of Wachtwoord en poort specificeren om via SSH verbinding te maken met onze servers. We hebben ook de naam nodig voor ons nieuwe cluster en als we willen dat ClusterControl de bijbehorende software en configuraties voor ons installeert.

Nadat we de SSH-toegangsinformatie hebben ingesteld, moeten we de knooppunten in ons cluster definiëren. We kunnen ook specificeren welke repository we moeten gebruiken. We moeten onze servers toevoegen aan het cluster dat we gaan maken.

We kunnen de status van het maken van ons nieuwe cluster volgen via de ClusterControl-activiteitenmonitor.

We kunnen ook een import van onze huidige cluster of database doen door dezelfde stappen te volgen. In dit geval zal ClusterControl de databasesoftware niet installeren, omdat er al een database actief is.

Om een ​​replicatieslave toe te voegen, moet u op Clusteracties klikken, Replicatieslave toevoegen selecteren en de SSH-toegangsinformatie van de nieuwe server toevoegen. ClusterControl maakt verbinding met de server om de benodigde configuraties voor deze actie te maken.

Om van een of meer Galera-knooppunten masterservers te maken (zoals in de zin van het maken van binlogs), gaat u naar Node-acties en selecteert u Binaire logboekregistratie inschakelen.

Back-ups kunnen worden geconfigureerd met XtraBackup (volledig of incrementeel) en mysqldump, en je hebt andere opties, zoals het uploaden van de back-up naar de cloud, codering, compressie, planning en meer.

Om de back-up te herstellen, gaat u naar het tabblad Back-up en kiest u de optie Herstellen, waarna u selecteert op welke server u wilt herstellen.

Als je een slave hebt en je wilt de master wijzigen of de replicatie opnieuw opbouwen, ga dan naar Node Actions en selecteer de optie.

Conclusie

Zoals we konden zien, hebben we verschillende manieren om ons doel te bereiken, sommige ingewikkelder, andere gebruiksvriendelijker, maar met elk ervan kun je een cluster opnieuw maken van een asynchrone slave. Xtrabackup zou sneller herstellen voor grotere datavolumes. Om je te beschermen tegen operatorfouten (bijvoorbeeld een foutieve DROP TABLE), kun je ook een vertraagde slave gebruiken, zodat je hopelijk tijd hebt om te voorkomen dat de verklaring zich verspreidt.

We hopen dat deze informatie nuttig is en dat u deze nooit in productie hoeft te gebruiken;)