Пълно възстановяване на MySQL или MariaDB Galera клъстер от архивиране

Извършването на редовни архиви на вашия клъстер от база данни е наложително за висока наличност и възстановяване след бедствие. Ако по някаква причина сте загубили целия си клъстер и трябва да извършите пълно възстановяване от архивно копие, ще ви е необходим надежден и актуален архив, от който да започнете.

Най-добри практики за архивиране

Някои препоръки, които да имате предвид за добър планиран режим на архивиране:

Трябва да можете да се възстановите напълно от катастрофална повреда от поне две предишни пълни резервни копия. Само в случай, че последното пълно архивиране е повредено, загубено или повредено,
Вашето архивно копие трябва да съдържа поне едно пълно архивиране в рамките на избран цикъл, обикновено седмично,
Съхранявайте резервни копия далеч от текущото местоположение на данни, за предпочитане извън сайта,
Използвайте смес от mysqldump и Xtrabackup за допълнителна безопасност и не разчитайте на един метод,
Редовно тествайте възстановяването на вашите резервни копия, напр. на всеки два месеца.

Ежеседмично пълно архивиране, комбинирано с ежедневно допълнително архивиране, обикновено е достатъчно. Поддържането на определен брой резервни копия за определен период от време винаги е добър план, може би пазете всеки седмичен архив за един месец. Това ви позволява да възстановите по-стара база данни в случай на спешни случаи или ако по някаква причина имате повреден локален архивен файл.

mysqldump или Xtrabackup

mysqldump е много вероятно най-популярният начин за архивиране на MySQL. Той прави логическо архивиране на данните, като чете от всяка таблица, използвайки SQL изрази, след което експортира данните в текстови файлове. Възстановяване на mysqldump е също толкова лесно, колкото създаването на дъмп файл. Основните недостатъци са, че е много бавен за големи бази данни, не е „горещ“ и изтрива буферния пул на InnoDB.

Xtrabackup извършва горещо архивиране, не заключва базата данни по време на архивирането и като цяло е по-бърз. Горещите архиви са важни за високата наличност, тъй като работят без да блокират приложението. Това също е важен фактор, когато се използва с Galera, тъй като Galera разчита на синхронна репликация. Въпреки това, възстановяването на xtrabackup може да бъде малко трудно, като използвате ръчни начини.

ClusterControl поддържа планирането както на mysqldump, така и на Xtrabackup (пълно и инкрементално), както и възстановяването на резервно копие направо от потребителския интерфейс.

Пълно възстановяване от архивиране

В тази публикация ще ви покажем как да възстановите Xtrabackup (пълен + инкрементален) върху празен клъстер, работещ на MariaDB Galera Cluster. Тези стъпки трябва да работят и върху Percona XtraDB Cluster или Galera Cluster за MySQL от Codership.

В нашия оригинален клъстер имахме пълно xtrabackup, планирано ежедневно, с инкрементални архиви, създавани на всеки час. Архивите се съхраняват в ClusterControl, както е показано на следната екранна снимка:

Сега да приемем, че сме загубили оригиналния си клъстер и трябва да извършим пълно възстановяване на нов клъстер. Стъпките включват:

Настройте нов сървър на ClusterControl.
Настройте нов MariaDB клъстер.
Експортирайте архивните записи и файлове към новия сървър на ClusterControl.
Започнете процеса на възстановяване.
Стартирайте останалите възли.

Следната диаграма илюстрира нашата архитектура за това упражнение:

Стъпка 1 - Настройте нов MariaDB клъстер

Инсталирайте ClusterControl и разгърнете нов MariaDB Cluster. Отидете на ClusterControl -> Deploy -> Deploy Database Cluster -> MySQL Galera и посочете необходимата информация в диалоговия прозорец за внедряване:

Щракнете върху бутона Deploy и започнете внедряването. Тъй като имаме само клъстер на стария сървър, така че идентификационният номер на клъстера трябва да е идентичен (идентификатор на клъстер:1) в този нов екземпляр.

Стъпка 2 – Експортиране и импортиране на архивните файлове След като клъстерът бъде разгърнат, ще трябва да импортираме резервните копия от стария сървър на ClusterControl в новия. Първо, експортирайте съдържанието на cmon.backup_records в дъмп файлове. Тъй като старият идентификатор на клъстера и новият са идентични, ние просто трябва да модифицираме дъмп файла с новия IP адрес и да го импортираме в новия възел на ClusterControl. Ако идентификаторът на клъстера е различен, тогава трябва да промените съответно стойността на „cid“ в дъмп файловете, преди да импортирате в CMON DB на новия възел. Освен това е по-лесно да запазите мястото за съхранение на архиви, както в стария сървър, така че новият ClusterControl да може да намери архивните файлове в новия сървър.

На стария сървър ClusterControl експортирайте таблицата backup_records в дъмп файлове:

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

След това извършете дистанционно копиране на архивните файлове от стария сървър в новия сървър на ClusterControl:

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

След това трябва да промените дъмп файловете, за да отразяват новия IP адрес на сървъра на ClusterControl. Не забравяйте да избягвате точката в IP адреса:

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

На новия сървър ClusterControl импортирайте дъмп файловете:

$ mysql -uroot -p cmon < backup_records.sql

Проверете дали списъкът с архиви е правилен в новия сървър на ClusterControl:

Както можете да видите, всички поява на предишния IP адрес (192.168.55.170) са заменени с новия IP адрес (192.168.55.150). Сега сме готови да извършим възстановяването в новия сървър.

Стъпка 3 - Извършете възстановяването

Извършването на възстановяване чрез потребителския интерфейс на ClusterControl е проста стъпка с насочване и щракване. Изберете кое архивиране да възстановите и кликнете върху бутона „Възстановяване“. Ще възстановим най-новото налично поетапно архивиране (Архив:9). Щракнете върху бутона „Възстановяване“ точно под името на архива и ще ви бъде представен следния диалогов прозорец за предварително възстановяване:

Изглежда, че размерът на резервното копие е доста малък (165,6 kB). Всъщност няма значение, защото ClusterControl ще подготви всички инкрементални архиви, групирани в Backup Set 6, който съдържа пълния Xtrabackup. Имате и няколко опции след възстановяване:

Възстановяване на резервното копие при включено – Изберете възела, на който да възстановите архива.
Tmp Dir – директорията ще се използва на локалния сървър на ClusterControl като временно съхранение по време на подготовката за архивиране. Тя трябва да е толкова голяма, колкото прогнозната директория с данни на MySQL.
Клъстер за стартиране от възстановения възел – Тъй като това е нов клъстер, ще го включим, така че ClusterControl да стартира автоматично клъстера след успешно възстановяване.
Направете копие на datadir, преди да възстановите архива – Ако възстановените данни са повредени или не, както се очаква да бъдат, ще имате резервно копие на предишната директория с данни на MySQL. Тъй като това е нов клъстер, ние ще игнорираме този.

Възстановяването на Percona Xtrabackup ще доведе до спиране на клъстера. ClusterControl ще:

Спрете всички възли в клъстера.
Възстановете резервното копие на избрания възел.
Стартирайте избрания възел.

За да видите напредъка на възстановяването, отидете на Активност -> Задачи -> Възстановяване на архивиране и щракнете върху бутона "Пълни подробности за работата". Трябва да видите нещо подобно:

Едно важно нещо, което трябва да направите, е да наблюдавате изхода на MySQL регистъра за грешки на целевия възел (192.168.55.151) по време на процеса на възстановяване. След като възстановяването завърши и по време на процеса на зареждане, трябва да видите следните редове, които започват да се появяват:

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)

Не изпадайте в паника. Това е очаквано поведение, тъй като този набор за архивиране не съхранява идентификационните данни за влизане в cmon на новата парола ClusterControl cmon. Вместо това е възстановил/заменил стария потребител на cmon. Това, което трябва да направите, е да върнете отново потребителя на cmon на сървъра, като изпълните следното изявление на този DB възел:

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

Тогава ClusterControl ще може да се свърже с стартирания възел и да определи възела и състоянието на архивиране. Ако всичко е наред, трябва да видите нещо подобно:

В този момент целевият възел е стартиран и работи. Можем да стартираме останалите възли под Nodes -> изберете node -> Start Node и поставете отметка в квадратчето „Извършване на първоначално стартиране“:

Възстановяването вече е завършено и можете да очаквате Performance -> DB Growth да докладва актуализирания размер на нашия нововъзстановен набор от данни:

Приятно възстановяване!