Hur man återställer MySQL Galera Cluster från en asynkron slav

Introduktion

När du kör Galera Cluster är det vanligt att lägga till en eller flera asynkrona slavar i samma eller i ett annat datacenter. Detta ger oss en beredskapsplan med låg RTO och med låg driftskostnad. I fallet med ett oåterställbart problem i vårt kluster kan vi snabbt failover till det så att applikationer kan fortsätta ha tillgång till data.

När vi använder den här typen av inställningar kan vi inte just då bygga om vårt kluster från en tidigare säkerhetskopia. Eftersom asynkronslaven nu är den nya källan till sanning, måste vi bygga om klustret från det.

Det betyder inte att vi bara har ett sätt att göra det, kanske finns det till och med ett bättre sätt! Ge oss gärna dina förslag i kommentarsfältet i slutet av det här inlägget.

Topologi

Ovan kan vi se ett exempel på topologi med Galera Cluster och en asynkron replika/slav.

Därefter kommer vi att se hur vi kan återskapa vårt kluster, med utgångspunkt från slaven, i fallet med att hitta något i stil med detta:

Om vi ​​tittar på föregående bild kan vi se att våra 3 Galera-noder är nere. Vår slav kan inte ansluta till Galera-mästaren, men den är i ett "igång"-läge.

Marknadsför slav

Eftersom vår slav fungerar korrekt, kan vi marknadsföra den för att bemästra och peka våra applikationer till den. För detta måste vi inaktivera den skrivskyddade parametern i vår slav och återställa slavkonfigurationen.

I vår slav (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)

Skapa nytt kluster

Därefter, för att starta återställningen av vårt misslyckade kluster, kommer vi att skapa ett nytt Galera-kluster. Detta kan enkelt göras genom ClusterControl ClusterControl, scrolla längre ner i den här bloggen för att se hur.

När vi väl har distribuerat vårt nya Galera-kluster skulle vi ha något i stil med följande:

Replikering

Vi måste se till att vi har replikeringsparametrarna konfigurerade.

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

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

För att vår nya slav (galera1) ska kunna ansluta till vår nya master (mysql1), måste vi skapa en användare med replikeringsbehörigheter i vår master.

I vår nya master (mysql1):

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

Notera:Vi kan ersätta "%" med IP:n för Galera Cluster-noden som kommer att vara vår slav, i vårt exempel, galera1.

Säkerhetskopiering

Om vi ​​inte har det måste vi skapa en konsekvent säkerhetskopia av vår master (mysql1) och ladda den i vårt nya Galera Cluster. För detta kan vi använda XtraBackup-verktyget eller mysqldump. Låt oss se båda alternativen.

I vårt exempel använder vi sakila-databasen som är tillgänglig för testning.

XtraBackup-verktyg

Vi genererar säkerhetskopian i den nya mastern (mysql1). I vårt fall skickar vi den till den lokala katalogen /root/backup:

$ innobackupex /root/backup/

Vi måste få meddelandet:

180705 22:08:14 completed OK!

Vi komprimerar säkerhetskopian och skickar den till noden som kommer att vara vår slav (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, extrahera säkerhetskopian:

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

Vi stoppar klustret (om det startas). För detta stoppar vi mysql-tjänsterna för de tre noderna:

$ service mysql stop

I galera1 byter vi namn på datakatalogen för mysql och laddar säkerhetskopian:

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

Vi måste få meddelandet:

180705 23:00:01 completed OK!

Vi tilldelar korrekta behörigheter för datakatalogen:

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

Sedan måste vi initiera klustret.

När den första noden har initierats måste vi starta MySQL-tjänsten för de återstående noderna, eliminera alla tidigare kopior av filen grastate.dat och sedan verifiera att vår data är uppdaterad.

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

Obs:Kontrollera att användaren som används av XtraBackup skapas i vår initierade nod och är densamma i varje nod.

mysqldump

I allmänhet rekommenderar vi inte att du gör det med mysqldump, eftersom det kan vara ganska långsamt med en stor mängd data. Men det är ett alternativ att utföra uppgiften.

Vi genererar säkerhetskopian i den nya mastern (mysql1):

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

Vi komprimerar den och skickar den till vår slavnod (galera1):

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

Vi laddar soptippen i galera1.

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

När dumpen laddas i galera1 måste vi starta om MySQL-tjänsten på de återstående noderna, ta bort filen grastate.dat och verifiera att vi har vår data uppdaterad.

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

Starta replikeringsslav

Oavsett vilket alternativ vi väljer, XtraBackup eller mysqldump, om allt gick bra, kan vi i detta steg redan slå på replikering i noden som kommer att vara vår slav (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 verifierar att slaven fungerar:

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

Vid det här laget har vi något i stil med följande:

När NewGalera1 är uppdaterad kan vi peka om applikationen till vårt nya galera-kluster och konfigurera om den asynkrona replikeringen.

ClusterControl

Som vi nämnde tidigare, med ClusterControl kan vi göra flera av de uppgifter som nämns ovan med några enkla klick. Den har också automatiska återställningsalternativ, för både noderna och klustret. Låt oss se några uppgifter som den kan hjälpa till med.

För att utföra en distribution, välj helt enkelt alternativet "Deploy Database Cluster" och följ instruktionerna som visas.

Vi kan välja mellan olika typer av teknologier och leverantörer. Vi måste ange användare, nyckel eller lösenord och port för att ansluta med SSH till våra servrar. Vi behöver också namnet på vårt nya kluster och om vi vill att ClusterControl ska installera motsvarande programvara och konfigurationer åt oss.

Efter att ha ställt in SSH-åtkomstinformationen måste vi definiera noderna i vårt kluster. Vi kan också specificera vilket arkiv som ska användas. Vi måste lägga till våra servrar i klustret som vi ska skapa.

Vi kan övervaka statusen för skapandet av vårt nya kluster från ClusterControl-aktivitetsmonitorn.

Vi kan också göra en import av vårt nuvarande kluster eller databas enligt samma steg. I det här fallet kommer ClusterControl inte att installera databasprogramvaran, eftersom det redan finns en databas igång.

För att lägga till en replikeringsslav måste du klicka på Cluster Actions, välja Add Replication Slave och lägga till SSH-åtkomstinformationen för den nya servern. ClusterControl kommer att ansluta till servern för att göra nödvändiga konfigurationer för denna åtgärd.

För att förvandla en eller flera Galera-noder till masterservrar (som i betydelsen att producera binlogs), kan du gå till Nod Actions och välja Aktivera binär loggning.

Säkerhetskopior kan konfigureras med XtraBackup (fullständig eller inkrementell) och mysqldump, och du har andra alternativ som att ladda upp säkerhetskopian till molnet, kryptering, komprimering, schema och mer.

För att återställa säkerhetskopian, gå till fliken Säkerhetskopiering och välj alternativet Återställ, sedan väljer du på vilken server du vill återställa.

Om du har en slav och du vill ändra mastern, eller bygga om replikeringen, kan du gå till Nod Actions och välja alternativet.

Slutsats

Som vi kunde se har vi flera sätt att uppnå vårt mål, några mer komplexa, andra mer användarvänliga, men med vilket som helst av dem kan du återskapa ett kluster från en asynkron slav. Xtrabackup skulle återställa snabbare för större datavolymer. För att skydda dig mot operatörsfel (t.ex. en felaktig DROP TABLE) kan du också använda en fördröjd slav så att du förhoppningsvis har tid att stoppa påståendet från att spridas.

Vi hoppas att denna information är användbar och att du aldrig behöver använda den i produktionen;)