Volledig herstel van een MySQL- of MariaDB Galera-cluster vanuit back-up

Het maken van regelmatige back-ups van uw databasecluster is absoluut noodzakelijk voor hoge beschikbaarheid en noodherstel. Als je om wat voor reden dan ook je hele cluster bent kwijtgeraakt en een volledige back-up moet herstellen, heb je een betrouwbare en up-to-date back-up nodig om mee te beginnen.

Beste praktijken voor back-ups

Enkele aanbevelingen om te overwegen voor een goed gepland back-upregime:

• U zou in staat moeten zijn om volledig te herstellen van een catastrofale fout van ten minste twee eerdere volledige back-ups. Voor het geval de meest recente volledige back-up beschadigd, verloren of corrupt is,
• Uw back-up moet ten minste één volledige back-up bevatten binnen een gekozen cyclus, normaal gesproken wekelijks,
• Bewaar back-ups weg van de huidige gegevenslocatie, bij voorkeur offsite,
• Gebruik een combinatie van mysqldump en Xtrabackup voor extra veiligheid, en vertrouw niet op één methode,
• Test regelmatig uw back-ups terug te zetten, b.v. elke twee maanden.

Een wekelijkse volledige back-up gecombineerd met dagelijkse incrementele back-up is normaal gesproken voldoende. Een aantal back-ups voor een bepaalde periode bewaren is altijd een goed plan, bewaar elke wekelijkse back-up misschien een maand. Hiermee kunt u een oudere database herstellen in geval van nood of als u om de een of andere reden last heeft van beschadiging van het lokale back-upbestand.

mysqldump of Xtrabackup

mysqldump is zeer waarschijnlijk de meest populaire manier om een ​​back-up van MySQL te maken. Het maakt een logische back-up van de gegevens, leest uit elke tabel met behulp van SQL-instructies en exporteert de gegevens vervolgens naar tekstbestanden. Herstel van een mysqldump is net zo eenvoudig als het maken van het dumpbestand. De belangrijkste nadelen zijn dat het erg traag is voor grote databases, niet 'hot' is en de InnoDB-bufferpool wegvaagt.

Xtrabackup maakt hot backups, vergrendelt de database niet tijdens de backup en is over het algemeen sneller. Hot-back-ups zijn belangrijk voor hoge beschikbaarheid, omdat ze worden uitgevoerd zonder de toepassing te blokkeren. Dit is ook een belangrijke factor bij gebruik met Galera, aangezien Galera vertrouwt op synchrone replicatie. Het kan echter een beetje lastig zijn om een ​​xtrabackup handmatig te herstellen.

ClusterControl ondersteunt de planning van zowel mysqldump als Xtrabackup (volledig en incrementeel), evenals het herstellen van back-ups rechtstreeks vanuit de gebruikersinterface.

Volledig herstel vanaf back-up

In dit bericht laten we u zien hoe u Xtrabackup (volledig + incrementeel) kunt herstellen op een leeg cluster dat draait op MariaDB Galera Cluster. Deze stappen zouden ook moeten werken op Percona XtraDB Cluster of Galera Cluster voor MySQL van Codership.

In ons oorspronkelijke cluster hadden we dagelijks een volledige xtraback-up gepland, waarbij elk uur incrementele back-ups werden gemaakt. De back-ups worden opgeslagen op ClusterControl zoals weergegeven in de volgende schermafbeelding:

Laten we nu aannemen dat we ons oorspronkelijke cluster zijn kwijtgeraakt en een volledig herstel naar een nieuw cluster moeten uitvoeren. De stappen omvatten:

0. Stel een nieuwe ClusterControl-server in.
1. Stel een nieuw MariaDB-cluster in.
2. Exporteer de back-uprecords en bestanden naar de nieuwe ClusterControl-server.
3. Start het herstelproces.
4. Start de resterende knooppunten.

Het volgende diagram illustreert onze architectuur voor deze oefening:

Stap 1 - Nieuwe MariaDB-cluster instellen

Installeer ClusterControl en implementeer een nieuw MariaDB-cluster. Ga naar ClusterControl -> Deploy -> Deploy Database Cluster -> MySQL Galera en geef de vereiste informatie op in het implementatiedialoogvenster:

Klik op de knop Deploy en start de implementatie. Aangezien we alleen een cluster op de oude server hebben, moet de cluster-ID in deze nieuwe instantie identiek zijn (cluster-ID:1).

Exporteer op de oude ClusterControl-server de tabel backup_records naar dumpbestanden:

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

Voer vervolgens een externe kopie uit van de back-upbestanden van de oude server naar de nieuwe ClusterControl-server:

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

Vervolgens moeten de dumpbestanden worden aangepast om het nieuwe IP-adres van de ClusterControl-server weer te geven. Vergeet niet om de punt in het IP-adres te escapen:

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

Importeer de dumpbestanden op de nieuwe ClusterControl-server:

$ mysql -uroot -p cmon < backup_records.sql

Controleer of de back-uplijst correct is in de nieuwe ClusterControl-server:

Zoals u kunt zien, zijn alle exemplaren van het vorige IP-adres (192.168.55.170) vervangen door het nieuwe IP-adres (192.168.55.150). Nu zijn we klaar om het herstel op de nieuwe server uit te voeren.

Stap 3 - Voer de restauratie uit

Het uitvoeren van herstel via de gebruikersinterface van ClusterControl is een eenvoudige aanwijs-en-klik-stap. Kies welke back-up u wilt herstellen en klik op de knop "Herstellen". We gaan de laatste beschikbare incrementele back-up herstellen (Back-up:9). Klik op de knop "Herstellen" net onder de naam van de back-up en u krijgt het volgende dialoogvenster voor het herstel te zien:

Het lijkt erop dat de back-upgrootte vrij klein is (165,6 kB). Het maakt niet echt uit, want ClusterControl zal alle incrementele back-ups voorbereiden die zijn gegroepeerd onder Back-upset 6, die de volledige Xtrabackup bevat. Je hebt ook verschillende opties voor na de restauratie:

• Back-up terugzetten op - Kies het knooppunt waarop de back-up moet worden teruggezet.
• Tmp Dir - Directory wordt gebruikt op de lokale ClusterControl-server als tijdelijke opslag tijdens back-upvoorbereiding. Het moet zo groot zijn als de geschatte MySQL-gegevensmap.
• Bootstrap-cluster van het herstelde knooppunt - aangezien dit een nieuw cluster is, gaan we dit AAN zetten, zodat ClusterControl het cluster automatisch opstart nadat het herstel is gelukt.
• Maak een kopie van de datadir voordat u de back-up terugzet - Als de herstelde gegevens beschadigd zijn of niet zijn zoals u verwacht, hebt u een back-up van de vorige MySQL-gegevensdirectory. Aangezien dit een nieuwe cluster is, gaan we deze negeren.

Percona Xtrabackup-herstel zorgt ervoor dat het cluster wordt gestopt. ClusterControl zal:

1. Stop alle knooppunten in het cluster.
2. Herstel de back-up op het geselecteerde knooppunt.
3. Bootstrap het geselecteerde knooppunt.

Om de voortgang van het herstel te zien, gaat u naar Activiteit -> Taken -> Back-up herstellen en klikt u op de knop "Volledige taakdetails". Je zou zoiets als dit moeten zien:

Een belangrijk ding dat u moet doen, is de uitvoer van het MySQL-foutenlogboek op het doelknooppunt (192.168.55.151) controleren tijdens het herstelproces. Nadat het herstel is voltooid en tijdens het bootstrapping-proces, zou u de volgende regels moeten zien verschijnen:

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)

Geen paniek. Dit is een verwacht gedrag omdat deze back-upset de cmon-inloggegevens van het nieuwe ClusterControl cmon-wachtwoord niet opslaat. Het heeft in plaats daarvan de oude cmon-gebruiker hersteld/vervangen. Wat u moet doen, is de cmon-gebruiker opnieuw toewijzen aan de server door de volgende instructie op dit DB-knooppunt uit te voeren:

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

ClusterControl zou dan verbinding kunnen maken met het bootstrap-knooppunt en het knooppunt en de back-upstatus bepalen. Als alles in orde is, zou je zoiets als dit moeten zien:

Op dit punt is het doelknooppunt opgestart en actief. We kunnen de resterende nodes starten onder Nodes -> kies node -> Start Node en vink het selectievakje "Voer een eerste start uit" aan:

Het herstel is nu voltooid en u kunt verwachten dat Performance -> DB Growth de bijgewerkte grootte van onze onlangs herstelde dataset zal rapporteren:

Veel plezier met herstellen!