Fullständig återställning av ett MySQL- eller MariaDB Galera-kluster från säkerhetskopiering

Att utföra regelbundna säkerhetskopieringar av ditt databaskluster är absolut nödvändigt för hög tillgänglighet och katastrofåterställning. Om du av någon anledning tappade bort hela ditt kluster och var tvungen att göra en fullständig återställning från säkerhetskopia, skulle du behöva en pålitlig och uppdaterad säkerhetskopia att börja från.

Bästa metoder för säkerhetskopiering

Några rekommendationer att överväga för en bra schemalagd säkerhetskopiering:

• Du bör kunna återställa dig helt efter ett katastrofalt fel från minst två tidigare fullständiga säkerhetskopior. Bara om den senaste fullständiga säkerhetskopian är skadad, förlorad eller korrupt,
• Din säkerhetskopia bör innehålla minst en fullständig säkerhetskopia inom en vald cykel, normalt varje vecka,
• Lagra säkerhetskopior borta från den aktuella dataplatsen, helst utanför platsen,
• Använd en blandning av mysqldump och Xtrabackup för extra säkerhet, och lita inte på en metod,
• Testa återställa dina säkerhetskopior regelbundet, t.ex. varannan månad.

En veckovis fullständig backup kombinerad med daglig inkrementell backup räcker normalt. Att behålla ett antal säkerhetskopior under en period är alltid en bra plan, kanske behåll varje veckosäkerhetskopiering i en månad. Detta gör att du kan återställa en äldre databas i händelse av nödsituationer eller om du av någon anledning har skadad lokal säkerhetskopia.

mysqldump eller Xtrabackup

mysqldump är mycket troligt det mest populära sättet att säkerhetskopiera MySQL. Den gör en logisk säkerhetskopiering av data, läser från varje tabell med hjälp av SQL-satser och exporterar sedan data till textfiler. Återställning av en mysqldump är lika enkelt som att skapa dumpfilen. De största nackdelarna är att det är väldigt långsamt för stora databaser, det är inte "hett" och det raderar InnoDB-buffertpoolen.

Xtrabackup utför heta säkerhetskopieringar, låser inte databasen under säkerhetskopieringen och är generellt sett snabbare. Hot backups är viktiga för hög tillgänglighet, eftersom de körs utan att blockera applikationen. Detta är också en viktig faktor när den används med Galera, eftersom Galera förlitar sig på synkron replikering. Men att återställa en xtrabackup kan vara lite knepigt med manuella sätt.

ClusterControl stöder schemaläggning av både mysqldump och Xtrabackup (fullständig och inkrementell), samt säkerhetskopiering direkt från användargränssnittet.

Fullständig återställning från säkerhetskopia

I det här inlägget kommer vi att visa dig hur du återställer Xtrabackup (full + inkrementell) till ett tomt kluster som körs på MariaDB Galera Cluster. Dessa steg bör också fungera på Percona XtraDB Cluster eller Galera Cluster för MySQL från Codership.

I vårt ursprungliga kluster hade vi en fullständig xtrabackup schemalagd dagligen, med inkrementella säkerhetskopieringar som skapades varje timme. Säkerhetskopiorna lagras på ClusterControl som visas i följande skärmdump:

Låt oss nu anta att vi har förlorat vårt ursprungliga kluster och måste göra en fullständig återställning till ett nytt kluster. Stegen inkluderar:

0. Konfigurera en ny ClusterControl-server.
1. Sätt upp ett nytt MariaDB-kluster.
2. Exportera säkerhetskopiorna och filerna till den nya ClusterControl-servern.
3. Starta återställningsprocessen.
4. Starta de återstående noderna.

Följande diagram illustrerar vår arkitektur för denna övning:

Steg 1 – Konfigurera ett nytt MariaDB-kluster

Installera ClusterControl och distribuera ett nytt MariaDB Cluster. Gå till ClusterControl -> Deploy -> Deploy Database Cluster -> MySQL Galera och ange nödvändig information i distributionsdialogrutan:

Klicka på knappen Distribuera och starta distributionen. Eftersom vi bara har ett kluster på den gamla servern så bör kluster-ID:t vara identiskt (kluster-ID:1) i den här nya instansen.

Exportera tabellen backup_records till dumpfiler på den gamla ClusterControl-servern:

$ mysqldump -uroot -p --single-transaction --no-create-info cmon backup_records > backup_records.sql

Utför sedan fjärrkopiering av säkerhetskopieringsfilerna från den gamla servern till den nya ClusterControl-servern:

$ scp -r /root/backups 192.168.55.150:/root/
$ scp ~/backup_records.sql 192.168.55.150:~

Nästa är att ändra dumpfilerna för att återspegla den nya ClusterControl-serverns IP-adress. Glöm inte att undvika punkten i IP-adressen:

$ sed -i "s/192\.168\.55\.170/192\.168\.55\.150/g" backup_records.sql

Importera dumpfilerna på den nya ClusterControl-servern:

$ mysql -uroot -p cmon < backup_records.sql

Kontrollera att säkerhetskopieringslistan är korrekt i den nya ClusterControl-servern:

Som du kan se har alla förekomster av den tidigare IP-adressen (192.168.55.170) ersatts av den nya IP-adressen (192.168.55.150). Nu är vi redo att utföra återställningen i den nya servern.

Steg 3 - Utför återställningen

Att utföra återställning via ClusterControl UI är ett enkelt peka-och-klicka-steg. Välj vilken säkerhetskopia som ska återställas och klicka på knappen "Återställ". Vi kommer att återställa den senaste tillgängliga inkrementella säkerhetskopian (Säkerhetskopiering:9). Klicka på knappen "Återställ" precis under säkerhetskopieringsnamnet och du kommer att presenteras med följande dialogruta för föråterställning:

Det ser ut som om säkerhetskopian är ganska liten (165,6 kB). Det spelar egentligen ingen roll eftersom ClusterControl kommer att förbereda alla inkrementella säkerhetskopior grupperade under Backup Set 6, som innehåller den fullständiga Xtrabackupen. Du har också flera alternativ för efteråterställning:

• Återställ säkerhetskopia på - Välj den nod du vill återställa säkerhetskopian på.
• Tmp Dir - Directory kommer att användas på den lokala ClusterControl-servern som tillfällig lagring under förberedelse av säkerhetskopiering. Den måste vara lika stor som den uppskattade MySQL-datakatalogen.
• Bootstrap-kluster från den återställda noden - Eftersom detta är ett nytt kluster, kommer vi att sätta PÅ detta så att ClusterControl kommer att bootstrapa klustret automatiskt efter att återställningen har lyckats.
• Gör en kopia av datakatalogen innan du återställer säkerhetskopian - Om den återställda informationen är skadad eller inte som du förväntade dig att den skulle vara, kommer du att ha en säkerhetskopia av den tidigare MySQL-datakatalogen. Eftersom detta är ett nytt kluster kommer vi att ignorera detta.

Percona Xtrabackup-återställning gör att klustret stoppas. ClusterControl kommer:

1. Stoppa alla noder i klustret.
2. Återställ säkerhetskopian på den valda noden.
3. Bootstrap den valda noden.

För att se återställningsförloppet, gå till Aktivitet -> Jobb -> Återställ säkerhetskopia och klicka på knappen "Fullständiga jobbdetaljer". Du borde se något sånt här:

En viktig sak som du behöver göra är att övervaka utdata från MySQL-felloggen på målnoden (192.168.55.151) under återställningsprocessen. När återställningen är klar och under uppstartsprocessen bör du se följande rader:

Version: '10.1.22-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:52 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:53 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:54 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:55 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)

Få inte panik. Detta är ett förväntat beteende eftersom denna säkerhetskopia inte lagrar cmon-inloggningsuppgifterna för det nya ClusterControl cmon-lösenordet. Den har återställt/ersatt den gamla cmon-användaren istället. Vad du behöver göra är att återge cmon-användare tillbaka till servern genom att köra följande sats på denna DB-nod:

GRANT ALL PRIVILEGES ON *.* to [email protected]'192.168.55.150' IDENTIFIED BY 'mynewCMONpassw0rd' WITH GRANT OPTION;
FLUSH PRIVILEGES;

ClusterControl skulle då kunna ansluta till den bootstrappade noden och bestämma noden och backuptillståndet. Om allt är OK bör du se något i stil med detta:

Vid denna tidpunkt är målnoden bootstrapped och igång. Vi kan starta de återstående noderna under Noder -> välj nod -> Start Node och markera kryssrutan "Utför en första start":

Återställningen är nu klar och du kan förvänta dig att Performance -> DB Growth rapporterar den uppdaterade storleken på vår nyligen återställda datamängd:

Lycka till med återställningen!