Fuld gendannelse af en MySQL eller MariaDB Galera Cluster fra backup

Udførelse af regelmæssige sikkerhedskopier af din databaseklynge er bydende nødvendigt for høj tilgængelighed og gendannelse af katastrofer. Hvis du af en eller anden grund mistede hele din klynge og skulle udføre en fuldstændig gendannelse fra backup, ville du have brug for en pålidelig og opdateret backup at starte fra.

Bedste praksis for sikkerhedskopiering

Nogle anbefalinger at overveje for et godt planlagt backup-regime:

• Du bør være i stand til at genoprette fuldstændigt efter en katastrofal fejl fra mindst to tidligere fulde sikkerhedskopier. Bare i tilfælde af at den seneste fulde sikkerhedskopi er beskadiget, tabt eller korrupt,
• Din sikkerhedskopi skal indeholde mindst én fuld sikkerhedskopi inden for en valgt cyklus, normalt ugentligt,
• Gem sikkerhedskopier væk fra den aktuelle dataplacering, helst off site,
• Brug en blanding af mysqldump og Xtrabackup for ekstra sikkerhed, og stol ikke på én metode,
• Testgendan dine sikkerhedskopier regelmæssigt, f.eks. hver anden måned.

En ugentlig fuld backup kombineret med daglig inkrementel backup er normalt nok. Det er altid en god plan at beholde et antal sikkerhedskopier i en periode, måske behold hver ugentlig backup i en måned. Dette giver dig mulighed for at gendanne en ældre database i tilfælde af nødsituationer, eller hvis du af en eller anden grund har en lokal backup-fil korruption.

mysqldump eller Xtrabackup

mysqldump er højst sandsynligt den mest populære måde at sikkerhedskopiere MySQL på. Den laver en logisk backup af dataene, læser fra hver tabel ved hjælp af SQL-sætninger og eksporterer derefter dataene til tekstfiler. Gendannelse af en mysqldump er lige så let som at oprette dumpfilen. De største ulemper er, at den er meget langsom for store databaser, den er ikke 'hot', og den udsletter InnoDB-bufferpuljen.

Xtrabackup udfører hot backups, låser ikke databasen under backup og er generelt hurtigere. Hot backups er vigtige for høj tilgængelighed, da de kører uden at blokere applikationen. Dette er også en vigtig faktor, når det bruges sammen med Galera, da Galera er afhængig af synkron replikering. Det kan dog være lidt vanskeligt at gendanne en xtrabackup ved at bruge manuelle måder.

ClusterControl understøtter planlægningen af ​​både mysqldump og Xtrabackup (fuld og trinvis) samt backupgendannelse direkte fra brugergrænsefladen.

Fuld gendannelse fra sikkerhedskopi

I dette indlæg vil vi vise dig, hvordan du gendanner Xtrabackup (fuld + inkrementel) på en tom klynge, der kører på MariaDB Galera Cluster. Disse trin bør også fungere på Percona XtraDB Cluster eller Galera Cluster til MySQL fra Codership.

I vores oprindelige klynge havde vi en fuld xtrabackup planlagt dagligt, med trinvise sikkerhedskopier oprettet hver time. Sikkerhedskopierne gemmes på ClusterControl som vist på følgende skærmbillede:

Lad os nu antage, at vi har mistet vores originale klynge og er nødt til at udføre en fuld gendannelse til en ny klynge. Trinene omfatter:

0. Konfigurer en ny ClusterControl-server.
1. Opret en ny MariaDB-klynge.
2. Eksporter backup-registreringerne og -filerne til den nye ClusterControl-server.
3. Start gendannelsesprocessen.
4. Start de resterende noder.

Følgende diagram illustrerer vores arkitektur for denne øvelse:

Trin 1 - Konfigurer ny MariaDB-klynge

Installer ClusterControl og implementer en ny MariaDB Cluster. Gå til ClusterControl -> Deploy -> Deploy Database Cluster -> MySQL Galera, og angiv de nødvendige oplysninger i implementeringsdialogen:

Klik på knappen Implementer og start implementeringen. Da vi kun har en klynge på den gamle server, så burde klynge-id'et være identisk (klynge-id:1) i denne nye instans.

På den gamle ClusterControl-server, eksporter tabellen backup_records til dumpfiler:

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

Udfør derefter fjernkopiering af backupfilerne fra den gamle server til den nye ClusterControl-server:

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

Det næste er at ændre dumpfilerne, så de afspejler den nye ClusterControl-server-IP-adresse. Glem ikke at undslippe prikken i IP-adressen:

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

På den nye ClusterControl-server skal du importere dumpfilerne:

$ mysql -uroot -p cmon < backup_records.sql

Bekræft, at backuplisten er korrekt i den nye ClusterControl-server:

Som du kan se, er alle forekomster af den tidligere IP-adresse (192.168.55.170) blevet erstattet af den nye IP-adresse (192.168.55.150). Nu er vi klar til at udføre gendannelsen på den nye server.

Trin 3 - Udfør gendannelsen

At udføre gendannelse gennem ClusterControl UI er et simpelt peg-og-klik-trin. Vælg hvilken sikkerhedskopi du vil gendanne, og klik på knappen "Gendan". Vi vil gendanne den seneste trinvise sikkerhedskopi, der er tilgængelig (Backup:9). Klik på "Gendan"-knappen lige under sikkerhedskopinavnet, og du vil blive præsenteret for følgende dialogboks før gendannelse:

Det ser ud til, at backup-størrelsen er ret lille (165,6 kB). Det betyder ikke rigtig noget, fordi ClusterControl vil forberede alle inkrementelle sikkerhedskopier grupperet under Backup Set 6, som indeholder den fulde Xtrabackup. Du har også flere muligheder for eftergendannelse:

• Gendan sikkerhedskopiering til - Vælg den node, som sikkerhedskopien skal gendannes på.
• Tmp Dir - Directory vil blive brugt på den lokale ClusterControl-server som midlertidig lagring under forberedelse af backup. Den skal være lige så stor som den estimerede MySQL-datamappe.
• Bootstrap-klynge fra den gendannede node - Da dette er en ny klynge, vil vi slå dette TIL, så ClusterControl vil bootstrap klyngen automatisk, efter at gendannelsen lykkes.
• Lav en kopi af datakataloget, før du gendanner sikkerhedskopien - Hvis de gendannede data er beskadiget eller ikke, som du forventede, vil du have en sikkerhedskopi af den tidligere MySQL-datamappe. Da dette er en ny klynge, vil vi ignorere denne.

Percona Xtrabackup-gendannelse vil få klyngen til at blive stoppet. ClusterControl vil:

1. Stop alle noder i klyngen.
2. Gendan sikkerhedskopien på den valgte node.
3. Bootstrap den valgte node.

For at se gendannelsesforløbet skal du gå til Aktivitet -> Jobs -> Gendan sikkerhedskopi og klikke på knappen "Fuld jobdetaljer". Du burde se noget som dette:

En vigtig ting, du skal gøre, er at overvåge outputtet af MySQL-fejlloggen på målknuden (192.168.55.151) under gendannelsesprocessen. Efter gendannelsen er fuldført og under bootstrapping-processen, bør du se følgende linjer begynde at dukke op:

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)

Gå ikke i panik. Dette er en forventet adfærd, fordi dette sikkerhedskopieringssæt ikke gemmer cmon-loginoplysningerne for den nye ClusterControl cmon-adgangskode. Den har i stedet gendannet/erstattet den gamle cmon-bruger. Det du skal gøre er at gengive cmon-bruger tilbage til serveren ved at køre følgende sætning på denne DB-node:

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

ClusterControl ville derefter være i stand til at oprette forbindelse til den bootstrappede node og bestemme noden og backuptilstanden. Hvis alt er OK, bør du se noget som dette:

På dette tidspunkt er målknuden bootstrapped og kører. Vi kan starte de resterende noder under Noder -> vælg node -> Start Node og marker afkrydsningsfeltet "Udfør en første start":

Gendannelsen er nu fuldført, og du kan forvente, at Performance -> DB Growth rapporterer den opdaterede størrelse af vores nyligt gendannede datasæt:

God fornøjelse med gendannelsen!