Úplné obnovení clusteru MySQL nebo MariaDB Galera ze zálohy

Provádění pravidelných záloh databázového clusteru je nezbytné pro vysokou dostupnost a obnovu po havárii. Pokud z nějakého důvodu přijdete o celý cluster a budete muset provést úplnou obnovu ze zálohy, budete potřebovat spolehlivou a aktuální zálohu, ze které byste mohli začít.

Doporučené postupy pro zálohování

Některá doporučení, která je třeba zvážit pro dobrý režim plánovaného zálohování:

• Měli byste být schopni se úplně zotavit z katastrofického selhání z alespoň dvou předchozích úplných záloh. Pro případ, že by byla nejnovější plná záloha poškozena, ztracena nebo poškozena,
• Vaše záloha by měla obsahovat alespoň jednu plnou zálohu ve zvoleném cyklu, obvykle týdně,
• Zálohy ukládejte mimo aktuální umístění dat, nejlépe mimo pracoviště,
• Pro větší bezpečnost použijte kombinaci mysqldump a Xtrabackup a nespoléhejte se na jednu metodu,
• Pravidelně testujte obnovení záloh, např. každé dva měsíce.

Obvykle stačí týdenní plná záloha kombinovaná s denním přírůstkovým zálohováním. Uchovávání určitého počtu záloh po určitou dobu je vždy dobrý plán, možná si ponechejte každou týdenní zálohu po dobu jednoho měsíce. To vám umožní obnovit starší databázi v případě nouze nebo pokud z nějakého důvodu došlo k poškození místního záložního souboru.

mysqldump nebo Xtrabackup

mysqldump je velmi pravděpodobně nejoblíbenějším způsobem zálohování MySQL. Provádí logické zálohování dat, čtení z každé tabulky pomocí příkazů SQL a poté export dat do textových souborů. Obnovení mysqldump je stejně snadné jako vytvoření souboru výpisu. Hlavní nevýhodou je, že je velmi pomalý u velkých databází, není „horký“ a vymaže zásobník vyrovnávací paměti InnoDB.

Xtrabackup provádí horké zálohy, nezamyká databázi během zálohování a je obecně rychlejší. Horké zálohy jsou důležité pro vysokou dostupnost, protože běží bez blokování aplikace. To je také důležitý faktor při použití s ​​Galera, protože Galera spoléhá na synchronní replikaci. Obnovení xtrabackup však může být trochu složité pomocí ručních způsobů.

ClusterControl podporuje plánování mysqldump a Xtrabackup (úplné a přírůstkové), stejně jako obnovu záloh přímo z uživatelského rozhraní.

Úplné obnovení ze zálohy

V tomto příspěvku vám ukážeme, jak obnovit Xtrabackup (úplný + přírůstkový) na prázdný cluster běžící na MariaDB Galera Cluster. Tyto kroky by měly fungovat také na Percona XtraDB Cluster nebo Galera Cluster pro MySQL od Codership.

V našem původním clusteru jsme měli denně naplánovanou úplnou zálohu xtrabackup s přírůstkovými zálohami vytvářenými každou hodinu. Zálohy jsou uloženy v ClusterControl, jak je znázorněno na následujícím snímku obrazovky:

Nyní předpokládejme, že jsme ztratili svůj původní cluster a musíme provést úplné obnovení nového clusteru. Tyto kroky zahrnují:

0. Nastavte nový server ClusterControl.
1. Nastavte nový klastr MariaDB.
2. Exportujte záložní záznamy a soubory na nový server ClusterControl.
3. Spusťte proces obnovení.
4. Spusťte zbývající uzly.

Následující diagram ilustruje naši architekturu pro toto cvičení:

Krok 1 – Nastavení nového clusteru MariaDB

Nainstalujte ClusterControl a nasaďte nový MariaDB Cluster. Přejděte na ClusterControl -> Deploy -> Deploy Database Cluster -> MySQL Galera a zadejte požadované informace v dialogovém okně nasazení:

Klikněte na tlačítko Deploy a spusťte instalaci. Protože máme cluster pouze na starém serveru, mělo by být ID clusteru v této nové instanci identické (ID clusteru:1).

Na starém serveru ClusterControl exportujte tabulku backup_records do souborů výpisu:

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

Poté proveďte vzdálené zkopírování záložních souborů ze starého serveru na nový server ClusterControl:

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

Dále je třeba upravit soubory výpisu, aby odrážely novou IP adresu serveru ClusterControl. Nezapomeňte v IP adrese uvolnit tečku:

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

Na novém serveru ClusterControl importujte soubory výpisu:

$ mysql -uroot -p cmon < backup_records.sql

Ověřte správnost seznamu záloh na novém serveru ClusterControl:

Jak můžete vidět, všechny výskyty předchozí IP adresy (192.168.55.170) byly nahrazeny novou IP adresou (192.168.55.150). Nyní jsme připraveni provést obnovu na novém serveru.

Krok 3 – Proveďte obnovu

Provedení obnovy prostřednictvím uživatelského rozhraní ClusterControl je jednoduchým krokem ukaž a klikni. Vyberte zálohu, kterou chcete obnovit, a klikněte na tlačítko „Obnovit“. Chystáme se obnovit nejnovější dostupnou přírůstkovou zálohu (Záloha:9). Klikněte na tlačítko „Obnovit“ přímo pod názvem zálohy a zobrazí se následující dialogové okno předběžné obnovy:

Vypadá to, že velikost zálohy je docela malá (165,6 kB). Na tom vlastně nezáleží, protože ClusterControl připraví všechny přírůstkové zálohy seskupené pod Backup Set 6, který obsahuje plnou Xtrabackup. Máte také několik možností po obnovení:

• Obnovit zálohu na – Vyberte uzel, ze kterého chcete zálohu obnovit.
• Tmp Dir – Adresář bude použit na místním serveru ClusterControl jako dočasné úložiště během přípravy zálohy. Musí být stejně velký jako odhadovaný datový adresář MySQL.
• Zavedení clusteru z obnoveného uzlu – Protože se jedná o nový cluster, přepneme jej na hodnotu ZAPNUTO, aby ClusterControl po úspěšném obnovení automaticky zavedl cluster.
• Před obnovením zálohy si vytvořte kopii datového adresáře – Pokud jsou obnovená data poškozena nebo nejsou podle očekávání, budete mít zálohu předchozího datového adresáře MySQL. Protože se jedná o nový cluster, budeme tento cluster ignorovat.

Obnova Percona Xtrabackup způsobí zastavení clusteru. ClusterControl:

1. Zastavte všechny uzly v clusteru.
2. Obnovte zálohu na vybraném uzlu.
3. Zaveďte vybraný uzel.

Chcete-li zobrazit průběh obnovy, přejděte na Aktivita -> Úlohy -> Obnovit zálohu a klikněte na tlačítko „Úplné podrobnosti úlohy“. Měli byste vidět něco takového:

Jedna důležitá věc, kterou musíte udělat, je sledovat výstup protokolu chyb MySQL na cílovém uzlu (192.168.55.151) během procesu obnovy. Po dokončení obnovy a během procesu bootstrappingu byste měli vidět následující řádky:

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)

Nepanikařte. Toto je očekávané chování, protože tato zálohovací sada neukládá přihlašovací údaje Cmon nového hesla ClusterControl Cmon. Místo toho obnovil/nahradil starého uživatele cmon. Co musíte udělat, je znovu udělit uživatele cmon zpět na server spuštěním následujícího příkazu na tomto uzlu DB:

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

ClusterControl by se pak mohl připojit k uzlu bootstrapped a určit stav uzlu a zálohy. Pokud je vše v pořádku, měli byste vidět něco takového:

V tomto okamžiku je cílový uzel bootstrapped a spuštěn. Zbývající uzly můžeme spustit pod Nodes -> zvolte uzel -> Start Node a zaškrtněte políčko „Perform an Initial Start“:

Obnova je nyní dokončena a můžete očekávat, že Výkon -> Růst DB nahlásí aktualizovanou velikost naší nově obnovené datové sady:

Šťastné obnovení!