Sådan gendannes MySQL Galera Cluster fra en asynkron slave

Introduktion

Når du kører Galera Cluster, er det almindelig praksis at tilføje en eller flere asynkrone slaver i det samme eller i et andet datacenter. Dette giver os en beredskabsplan med lav RTO og lave driftsomkostninger. I tilfælde af et uopretteligt problem i vores klynge, kan vi hurtigt failover til det, så applikationer fortsat kan have adgang til data.

Når vi bruger denne type opsætning, kan vi ikke lige derefter genopbygge vores klynge fra en tidligere backup. Da asynkronslaven nu er den nye kilde til sandhed, er vi nødt til at genopbygge klyngen fra den.

Det betyder ikke, at vi kun har én måde at gøre det på, måske er der endda en bedre måde! Du er velkommen til at give os dine forslag i kommentarfeltet i slutningen af ​​dette indlæg.

Topologi

Ovenfor kan vi se et eksempel på topologi med Galera Cluster og en asynkron replika/slave.

Dernæst vil vi se, hvordan vi kan genskabe vores klynge, startende fra slaven, i tilfælde af at finde noget som dette:

Hvis vi ser på det forrige billede, kan vi se, at vores 3 Galera-noder er nede. Vores slave er ikke i stand til at oprette forbindelse til Galera-masteren, men den er i tilstanden "Op og kører".

Promover slave

Da vores slave fungerer korrekt, kan vi fremme den for at mestre og pege vores applikationer til den. Til dette skal vi deaktivere den skrivebeskyttede parameter i vores slave og nulstille slavekonfigurationen.

I vores slave (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)

Opret ny klynge

Dernæst, for at starte genopretning af vores mislykkede klynge, vil vi oprette en ny Galera-klynge. Dette kan nemt gøres gennem ClusterControl ClusterControl, rul venligst længere ned i denne blog for at se hvordan.

Når vi har implementeret vores nye Galera-klynge, vil vi have noget i stil med følgende:

Replikering

Vi skal sikre, at vi har konfigureret replikeringsparametrene.

For Galera-noder (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

For Master node (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

For at vores nye slave (galera1) kan oprette forbindelse til vores nye master (mysql1), skal vi oprette en bruger med replikeringstilladelser i vores master.

I vores nye master (mysql1):

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

Bemærk:Vi kan erstatte "%" med IP'en for Galera Cluster noden, der vil være vores slave, i vores eksempel, galera1.

Sikkerhedskopi

Hvis vi ikke har det, skal vi lave en konsekvent backup af vores master (mysql1) og indlæse den i vores nye Galera Cluster. Til dette kan vi bruge XtraBackup-værktøjet eller mysqldump. Lad os se begge muligheder.

I vores eksempel bruger vi sakila-databasen, der er tilgængelig til test.

XtraBackup-værktøj

Vi genererer sikkerhedskopien i den nye master (mysql1). I vores tilfælde sender vi det til den lokale mappe /root/backup:

$ innobackupex /root/backup/

Vi skal have beskeden:

180705 22:08:14 completed OK!

Vi komprimerer sikkerhedskopien og sender den til den node, der vil være vores slave (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/

I galera1 skal du udtrække sikkerhedskopien:

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

Vi stopper klyngen (hvis den er startet). Til dette stopper vi mysql-tjenesterne for de 3 noder:

$ service mysql stop

I galera1 omdøber vi databiblioteket for mysql og indlæser sikkerhedskopien:

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

Vi skal have beskeden:

180705 23:00:01 completed OK!

Vi tildeler de korrekte tilladelser til databiblioteket:

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

Så skal vi initialisere klyngen.

Når den første node er initialiseret, skal vi starte MySQL-tjenesten for de resterende noder, fjerne enhver tidligere kopi af filen grastate.dat og derefter kontrollere, at vores data er opdateret.

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

Bemærk:Bekræft, at den bruger, der bruges af XtraBackup, er oprettet i vores initialiserede node og er den samme i hver node.

mysqldump

Generelt anbefaler vi ikke at gøre det med mysqldump, fordi det kan være ret langsomt med en stor mængde data. Men det er et alternativ til at udføre opgaven.

Vi genererer sikkerhedskopien i den nye master (mysql1):

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

Vi komprimerer det og sender det til vores slaveknude (galera1):

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

Vi indlæser lossepladsen i galera1.

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

Når dumpet er indlæst i galera1, skal vi genstarte MySQL-tjenesten på de resterende noder, fjerne filen grastate.dat og bekræfte, at vi har opdateret vores data.

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

Start replikeringsslave

Uanset hvilken mulighed vi vælger, XtraBackup eller mysqldump, hvis alt gik godt, kan vi i dette trin allerede slå replikering til i den node, der vil være vores slave (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;

Vi bekræfter, at slaven virker:

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

På dette tidspunkt har vi noget i stil med følgende:

Når NewGalera1 er opdateret, kan vi pege applikationen til vores nye galera-klynge igen og omkonfigurere den asynkrone replikering.

ClusterControl

Som vi nævnte tidligere, kan vi med ClusterControl udføre flere af de ovennævnte opgaver med et par enkle klik. Den har også automatiske gendannelsesmuligheder for både noderne og klyngen. Lad os se nogle opgaver, som den kan hjælpe med.

For at udføre en implementering skal du blot vælge muligheden "Deploy Database Cluster" og følge instruktionerne, der vises.

Vi kan vælge mellem forskellige slags teknologier og leverandører. Vi skal angive bruger, nøgle eller adgangskode og port for at forbinde med SSH til vores servere. Vi har også brug for navnet på vores nye klynge, og hvis vi ønsker, at ClusterControl skal installere den tilsvarende software og konfigurationer for os.

Efter opsætning af SSH-adgangsoplysningerne skal vi definere noderne i vores klynge. Vi kan også angive, hvilket lager der skal bruges. Vi skal tilføje vores servere til den klynge, som vi skal oprette.

Vi kan overvåge status for oprettelsen af ​​vores nye klynge fra ClusterControl-aktivitetsmonitoren.

Vi kan også importere vores nuværende klynge eller database ved at følge de samme trin. I dette tilfælde vil ClusterControl ikke installere databasesoftwaren, fordi der allerede kører en database.

For at tilføje en replikeringsslave skal du klikke på Klyngehandlinger, vælge Tilføj replikeringsslave og tilføje SSH-adgangsoplysningerne for den nye server. ClusterControl vil oprette forbindelse til serveren for at foretage de nødvendige konfigurationer til denne handling.

For at omdanne en eller flere Galera-noder til masterservere (som i betydningen at producere binlogs), kan du gå til Node Actions og vælge Aktiver binær logning.

Sikkerhedskopier kan konfigureres med XtraBackup (fuld eller inkrementel) og mysqldump, og du har andre muligheder som at uploade sikkerhedskopien til skyen, kryptering, komprimering, tidsplan og mere.

For at gendanne sikkerhedskopien skal du gå til fanen Sikkerhedskopiering og vælge Gendan mulighed, så vælger du på hvilken server du vil gendanne.

Hvis du har en slave, og du vil ændre masteren eller genopbygge replikeringen, kan du gå til Node Actions og vælge muligheden.

Konklusion

Som vi kunne se, har vi flere måder at nå vores mål på, nogle mere komplekse, andre mere brugervenlige, men med enhver af dem kan du genskabe en klynge fra en asynkron slave. Xtrabackup ville gendanne hurtigere for større datamængder. For at beskytte dig mod operatørfejl (f.eks. en fejlagtig DROP TABLE), kan du også bruge en forsinket slave, så du forhåbentlig har tid til at stoppe erklæringen i at udbrede sig.

Vi håber, at disse oplysninger er nyttige, og at du aldrig behøver at bruge dem i produktionen;)