Как да възстановите MySQL Galera клъстер от асинхронен подчинен

Въведение

При стартиране на Galera Cluster е обичайна практика да се добавят един или повече асинхронни подчинени устройства в същия или в различен център за данни. Това ни осигурява план за извънредни ситуации с нисък RTO и ниски оперативни разходи. В случай на невъзстановим проблем в нашия клъстер, можем бързо да преминем към него, за да могат приложенията да продължат да имат достъп до данни.

Когато използваме този тип настройка, не можем просто да възстановим нашия клъстер от предишен архив. Тъй като async slave сега е новият източник на истина, трябва да изградим отново клъстера от него.

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

Топология

По-горе можем да видим примерна топология с Galera Cluster и асинхронна реплика/подчинен.

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

Ако погледнем предишното изображение, можем да видим, че нашите 3 възела на Galera са надолу. Нашият подчинен не може да се свърже с главната програма на Galera, но е в състояние „Нагоре и работи“.

Повишаване на подчинен

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

В нашия подчинен (mysql1):

mysql> SET GLOBAL read_only=0;
Query OK, 0 rows affected (0.00 sec)
mysql> STOP SLAVE;
Query OK, 0 rows affected (0.00 sec)
mysql> RESET SLAVE;
Query OK, 0 rows affected (0.18 sec)

Създаване на нов клъстер

След това, за да започнем възстановяването на нашия неуспешен клъстер, ще създадем нов клъстер Galera. Това може лесно да се направи чрез ClusterControl ClusterControl, моля, превъртете по-надолу в този блог, за да видите как.

След като разположим нашия нов клъстер Galera, ще имаме нещо като следното:

Репликация

Трябва да гарантираме, че параметрите за репликация са конфигурирани.

За възли на Galera (galera1, galera2, galera3):

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin = /var/lib/mysql-binlog/binlog
log_slave_updates = ON
gtid_mode = ON
enforce_gtid_consistency = true
relay_log = relay-bin
expire_logs_days = 7

За главен възел (mysql1):

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON
sync_binlog=1
report_host=<HOSTNAME or IP>    # Local server

За да може нашият нов подчинен (galera1) да се свърже с новия ни главен (mysql1), трябва да създадем потребител с разрешения за репликация в нашия главен.

В нашия нов master (mysql1):

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';

Забележка:Можем да заменим „%“ с IP на възела Galera Cluster, който ще бъде наш подчинен, в нашия пример galera1.

Резервно копие

Ако го нямаме, трябва да създадем последователно архивиране на нашия главен (mysql1) и да го заредим в нашия нов клъстер Galera. За това можем да използваме инструмента XtraBackup или mysqldump. Нека видим и двете опции.

В нашия пример използваме базата данни sakila, налична за тестване.

Инструмент XtraBackup

Генерираме архива в новия главен файл (mysql1). В нашия случай го изпращаме в локалната директория /root/backup:

$ innobackupex /root/backup/

Трябва да получим съобщението:

180705 22:08:14 completed OK!

Ние компресираме архива и го изпращаме до възела, който ще бъде наш подчинен (galera1):

$ cd /root/backup
$ tar zcvf 2018-07-05_22-08-07.tar.gz 2018-07-05_22-08-07
$ scp /root/backup/2018-07-05_22-08-07.tar.gz galera1:/root/backup/

В galera1 извлечете архива:

$ tar zxvf /root/backup/2018-07-05_22-08-07.tar.gz

Спираме клъстера (ако е стартиран). За това спираме mysql услугите на 3-те възела:

$ service mysql stop

В galera1 преименуваме директорията с данни на mysql и зареждаме архива:

$ mv /var/lib/mysql /var/lib/mysql.bak
$ innobackupex --copy-back /root/backup/2018-07-05_22-08-07

Трябва да получим съобщението:

180705 23:00:01 completed OK!

Ние задаваме правилните разрешения на директорията с данни:

$ chown -R mysql.mysql /var/lib/mysql

След това трябва да инициализираме клъстера.

След като първият възел е инициализиран, трябва да стартираме услугата MySQL за останалите възли, като елиминираме всяко предишно копие на файла grastate.dat и след това да проверим дали данните ни са актуализирани.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Забележка:Уверете се, че потребителят, използван от XtraBackup, е създаден в нашия инициализиран възел и е един и същ във всеки възел.

mysqldump

По принцип не препоръчваме да го правите с mysqldump, защото може да бъде доста бавен с голям обем данни. Но това е алтернатива за изпълнение на задачата.

Генерираме архива в новия главен файл (mysql1):

$ mysqldump -uroot -p --single-transaction --skip-add-locks --triggers --routines --events --databases sakila > /root/backup/sakila_dump.sql

Компресираме го и го изпращаме до нашия подчинен възел (galera1):

$ gzip /root/backup/sakila_dump.sql
$ scp /root/backup/sakila_dump.sql.gz galera1:/root/backup/

Зареждаме дъмпа в galera1.

$ gunzip /root/backup/sakila_dump.sql.gz
$ mysql -p < /root/backup/sakila_dump.sql

Когато дъмпът се зареди в galera1, трябва да рестартираме услугата MySQL на останалите възли, като премахнем файла grastate.dat и проверим дали данните ни са актуализирани.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Стартиране на подчинено устройство за репликация

Независимо коя опция ще изберем, XtraBackup или mysqldump, ако всичко е минало добре, в тази стъпка вече можем да включим репликацията във възела, който ще бъде наш подчинен (galera1).

$ mysql> CHANGE MASTER TO MASTER_HOST = 'mysql1', MASTER_PORT = 3306, MASTER_USER = 'slave_user', MASTER_PASSWORD = 'slave_password', MASTER_AUTO_POSITION = 1;
$ mysql> START SLAVE;

Проверяваме дали подчинението работи:

mysql> SHOW SLAVE STATUS\G
       Slave_IO_Running: Yes
       Slave_SQL_Running: Yes

В този момент имаме нещо като следното:

След като NewGalera1 е актуален, можем да пренасочим приложението към нашия нов клъстер galera и да конфигурираме повторно асинхронната репликация.

ClusterControl

Както споменахме по-рано, с ClusterControl можем да изпълним няколко от посочените по-горе задачи с няколко прости щраквания. Той също така има опции за автоматично възстановяване, както за възлите, така и за клъстера. Нека видим някои задачи, с които може да помогне.

За да извършите внедряване, просто изберете опцията „Разгръщане на клъстер от база данни“ и следвайте инструкциите, които се появяват.

Можем да избираме между различни видове технологии и доставчици. Трябва да посочим потребител, ключ или парола и порт за свързване чрез SSH към нашите сървъри. Нуждаем се и от името на нашия нов клъстер и ако искаме ClusterControl да инсталира съответния софтуер и конфигурации вместо нас.

След като настроим информацията за SSH достъп, трябва да дефинираме възлите в нашия клъстер. Можем също да посочим кое хранилище да използваме. Трябва да добавим нашите сървъри към клъстера, който ще създадем.

Можем да наблюдаваме състоянието на създаването на нашия нов клъстер от монитора на активността на ClusterControl.

Също така можем да направим импорт на нашия текущ клъстер или база данни, като следваме същите стъпки. В този случай ClusterControl няма да инсталира софтуера на базата данни, защото вече има работеща база данни.

За да добавите подчинен за репликация, трябва да щракнете върху Действия на клъстер, да изберете Добавяне на подчинен за репликация и да добавите информацията за SSH достъп на новия сървър. ClusterControl ще се свърже със сървъра, за да направи необходимите конфигурации за това действие.

За да превърнете един или повече възли на Galera в главни сървъри (като в смисъл на създаване на binlogs), можете да отидете на Node Actions и да изберете Enable Binary Logging.

Архивите могат да се конфигурират с XtraBackup (пълен или инкрементален) и mysqldump и имате други опции като качване на архива в облака, криптиране, компресиране, график и др.

За да възстановите архива, отидете в раздела Архивиране и изберете опцията Възстановяване, след което изберете на кой сървър искате да възстановите.

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

Заключение

Както видяхме, имаме няколко начина да постигнем целта си, някои по-сложни, други по-удобни за потребителя, но с всеки от тях можете да пресъздадете клъстер от асинхронен подчинен. Xtrabackup би възстановил по-бързо за по-големи обеми данни. За да се предпазите от грешка на оператора (напр. погрешна DROP TABLE), можете също да използвате отложен подчинен, така че да се надяваме да имате време да спрете разпространението на оператора.

Надяваме се, че тази информация е полезна и че никога не трябва да я използвате в производството;)