17.5.5 Using MySQL Enterprise Backup with Group Replication — MySQL 5.7

17.5.5 Использование MySQL Enterprise Backup с групповой репликацией

является коммерчески лицензированной утилитой резервного копирования для MySQL Server, доступной с MySQL Enterprise Edition. В этом разделе объясняется, как выполнить резервное копирование и последующее восстановление узла групповой репликации с помощью MySQL Enterprise Backup. Та же техника может быть использована для быстрого добавления нового узла в группу.

Выполнение резервного копирования узла групповой репликации с помощью MySQL Enterprise Backup

Выполнение резервного копирования узла групповой репликации аналогично резервному копированию автономного экземпляра MySQL. Следующие инструкции предполагают, что вы уже знакомы с использованием MySQL Enterprise Backup для выполнения резервного копирования; если это не так, пожалуйста, просмотрите , особенно . Также обратите внимание на требования, описанные в и .

Рассмотрим следующую группу из трех узлов, s1, s2 и s3, работающих на хостах с одинаковыми именами:

mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s1          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s3          |        3306 | ONLINE       |
+-------------+-------------+--------------+

Используя MySQL Enterprise Backup, создайте резервную копию s2, выполнив на его хосте, например, следующую команду:

s2> mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/backups/my.mbi_`date +%d%m_%H%M` \
		      --backup-dir=/backups/backup_`date +%d%m_%H%M` --user=root -p \
		      --host=127.0.0.1 backup-to-image

Примечание

При резервном копировании вторичного узла, поскольку MySQL Enterprise Backup не может записать состояние резервного копирования и метаданные в экземпляр сервера только для чтения, во время операции резервного копирования могут появиться предупреждения, подобные следующему:
```
181113 21:31:08 MAIN WARNING: This backup operation cannot write to backup
progress. The MySQL server is running with the --super-read-only option.
```
Вы можете избежать предупреждения, используя опцию --no-history-logging в вашей команде резервного копирования.

Восстановление вышедшего из строя узла

Предположим, что один из узлов (s3 в приведенном ниже примере) необратимо поврежден. Самая последняя резервная копия узла группы s2 может быть использована для восстановления s3. Вот шаги для выполнения восстановления:

Скопируйте резервную копию s2 на хост для s3. Точный способ копирования резервной копии зависит от операционной системы и доступных инструментов. В этом примере мы предполагаем, что хосты — оба сервера Linux, и используем SCP для копирования файлов между ними:
```
s2/backups> scp my.mbi_2206_1429 s3:/backups
```
Восстановите резервную копию. Подключитесь к целевому хосту (в данном случае хосту для s3) и восстановите резервную копию с помощью MySQL Enterprise Backup. Вот шаги:
1. Остановите поврежденный сервер, если он все еще работает. Например, в дистрибутивах Linux, использующих systemd:
```
s3> systemctl stop mysqld
```
2. Сохраните файл конфигурации auto.cnf, расположенный в каталоге данных поврежденного сервера, скопировав его в безопасное место вне каталога данных. Это необходимо для сохранения уникального идентификатора сервера, который потребуется позже.
3. Удалите все содержимое каталога данных s3. Например:
```
s3> rm -rf /var/lib/mysql/*
```
  Если системные переменные innodb_data_home_dir, innodb_log_group_home_dir и innodb_undo_directory указывают на каталоги, отличные от каталога данных, они также должны быть очищены; в противном случае операция восстановления завершится неудачей.
4. Восстановите резервную копию s2 на хост для s3:
```
s3> mysqlbackup --defaults-file=/etc/my.cnf \
  --datadir=/var/lib/mysql \
  --backup-image=/backups/my.mbi_2206_1429  \
  --backup-dir=/tmp/restore_`date +%d%m_%H%M` copy-back-and-apply-log
```
  Примечание
  
  Приведенная выше команда предполагает, что бинарные журналы и журналы ретрансляции на s2 и s3 имеют одинаковое имя базового файла и находятся в одном и том же месте на двух серверах. Если эти условия не соблюдены, для MySQL Enterprise Backup 4.1.2 и более поздних версий следует использовать опции и для восстановления бинарного журнала и журнала ретрансляции в их исходные пути файлов на s3. Например, если вы знаете, что на s3 имя базового файла бинарного журнала — s3-bin, а имя базового файла журнала ретрансляции — s3-relay-bin, ваша команда восстановления должна выглядеть следующим образом:
  mysqlbackup --defaults-file=/etc/my.cnf \ --datadir=/var/lib/mysql \ --backup-image=/backups/my.mbi_2206_1429 \ --log-bin=s3-bin --relay-log=s3-relay-bin \ --backup-dir=/tmp/restore_`date +%d%m_%H%M` copy-back-and-apply-log
  Возможность восстановления бинарного журнала и журнала ретрансляции в правильные пути файлов упрощает процесс восстановления; если это по какой-либо причине невозможно, см. Перестроение вышедшего из строя узла для повторного присоединения в качестве нового узла.
Восстановите файл auto.cnf для s3. Для повторного присоединения к группе репликации восстановленный узел должен иметь тот же server_uuid, что и раньше при присоединении к группе. Укажите старый уникальный идентификатор сервера, скопировав файл auto.cnf, сохраненный на шаге 2 выше, в каталог данных восстановленного узла.

Примечание

Если вы не можете предоставить восстановленному узлу оригинальный server_uuid вышедшего из строя узла, восстановив старый файл auto.cnf, необходимо позволить восстановленному узлу присоединиться к группе как новому узлу; см. инструкции в Перестроение вышедшего из строя узла для повторного присоединения в качестве нового узла ниже о том, как это сделать.
Запустите восстановленный сервер. Например, в дистрибутивах Linux, использующих systemd:
```
systemctl start mysqld
```
Примечание

Если восстанавливаемый сервер является первичным узлом, выполните шаги, описанные в Восстановление первичного узла перед запуском восстановленного сервера.
Перезапустите групповую репликацию. Подключитесь к перезапущенному s3, используя, например, клиент mysql, и выполните следующую команду:
```
mysql> START GROUP_REPLICATION;
```
Прежде чем восстановленный экземпляр сможет стать онлайн-узлом группы, ему необходимо применить любые транзакции, которые произошли в группе после создания резервной копии; это достигается с помощью механизма распределенного восстановления групповой репликации, и процесс запускается после выполнения оператора START GROUP_REPLICATION. Чтобы проверить статус узла восстановленного экземпляра, выполните:
```
mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s1          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s3          |        3306 | RECOVERING   |
+-------------+-------------+--------------+
```
Это показывает, что s3 применяет транзакции, чтобы догнать группу. Как только он догонит остальную часть группы, его member_state изменится на ONLINE:
```
mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s1          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s3          |        3306 | ONLINE       |
+-------------+-------------+--------------+
```
Примечание

Если восстанавливаемый сервер является первичным узлом, после того, как он достигнет синхронизации с группой и станет ONLINE, выполните шаги в конце Восстановления первичного узла, чтобы отменить внесенные изменения в конфигурацию сервера до его запуска.

Узел теперь полностью восстановлен из резервной копии и функционирует как обычный узел группы.

Перестроение вышедшего из строя узла для повторного присоединения в качестве нового узла

Иногда шаги, описанные выше в Восстановлении вышедшего из строя узла, не могут быть выполнены, например, потому что бинарный журнал или журнал ретрансляции повреждены или просто отсутствуют в резервной копии. В такой ситуации используйте резервную копию для перестроения узла и затем добавьте его в группу в качестве нового узла. В приведенных ниже шагах предполагается, что перестроенный узел называется s3, как и вышедший из строя узел, и он работает на том же хосте, что и s3:

Скопируйте резервную копию s2 на хост для s3. Точный способ копирования резервной копии зависит от операционной системы и доступных инструментов. В этом примере предполагается, что оба хоста — серверы Linux, и используется SCP для копирования файлов между ними:
```
s2/backups> scp my.mbi_2206_1429 s3:/backups
```
Восстановите резервную копию. Подключитесь к целевому хосту (хосту для s3 в данном случае) и восстановите резервную копию с помощью MySQL Enterprise Backup. Вот шаги:
1. Остановите поврежденный сервер, если он все еще работает. Например, на дистрибутивах Linux, использующих systemd:
```
s3> systemctl stop mysqld
```
2. Удалите все содержимое каталога данных s3. Например:
```
s3> rm -rf /var/lib/mysql/*
```
  Если переменные системы innodb_data_home_dir, innodb_log_group_home_dir и innodb_undo_directory указывают на каталоги, отличные от каталога данных, они также должны быть очищены; в противном случае операция восстановления завершится ошибкой.
3. Восстановите резервную копию s2 на хост s3. С этим подходом мы строим s3 как нового участника, для которого нам не нужны или не требуется использовать старые двоичные и релейные журналы из резервной копии; поэтому, если эти журналы включены в вашу резервную копию, исключите их с помощью параметров и :
```
s3> mysqlbackup --defaults-file=/etc/my.cnf \
  --datadir=/var/lib/mysql \
  --backup-image=/backups/my.mbi_2206_1429  \
  --backup-dir=/tmp/restore_`date +%d%m_%H%M` \
  --skip-binlog --skip-relaylog \
  copy-back-and-apply-log
```
  Примечания
  Если у вас есть здоровые двоичные и релейные журналы в резервной копии, которые можно без проблем перенести на целевой хост, рекомендуется следовать более простому методу, описанному в Восстановление отказавшего узла выше.
  
  НЕ восстанавливайте вручную файл auto.cnf поврежденного сервера в каталог данных нового узла — при присоединении перестроенного s3 к группе в качестве нового узла ему будет присвоен новый UUID сервера.
Запустите восстановленный сервер. Например, на дистрибутивах Linux, использующих systemd:
```
systemctl start mysqld
```
Примечание

Если сервер, который вы восстанавливаете, является первичным узлом, выполните шаги, описанные в Восстановление первичного узла перед запуском восстановленного сервера.
Перенастройте восстановленный узел для присоединения к Group Replication. Подключитесь к восстановленному серверу с помощью клиента mysql и сбросьте информацию о источнике и реплике с помощью следующих команд:
```
mysql> RESET MASTER;
```
```
mysql> RESET SLAVE ALL;
```
Для того, чтобы восстановленный сервер мог автоматически восстановиться, используя встроенный механизм Group Replication для распределённого восстановления, настройте переменную сервера gtid_executed. Для этого используйте файл backup_gtid_executed.sql, включенный в резервную копию s2, который обычно восстанавливается в каталоге данных восстановленного узла. Отключите двоичное протоколирование, используйте файл backup_gtid_executed.sql для настройки gtid_executed, а затем снова включите двоичное протоколирование, выполнив следующие операторы с помощью вашего клиента mysql:
```
mysql> SET SQL_LOG_BIN=OFF;
mysql> SOURCE datadir/backup_gtid_executed.sql
mysql> SET SQL_LOG_BIN=ON;
```
Затем настройте учетные данные пользователя Group Replication на узле:
```
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' /
		FOR CHANNEL 'group_replication_recovery';
```
Перезапустите Group Replication. Выполните следующую команду на восстановленном сервере с помощью вашего клиента mysql:
```
mysql> START GROUP_REPLICATION;
```
Перед тем, как восстановленный экземпляр сможет стать активным узлом группы, ему необходимо применить любые транзакции, произошедшие в группе после создания резервной копии; это достигается с помощью механизма распределённого восстановления Group Replication, и процесс начинается после выполнения оператора START GROUP_REPLICATION. Для проверки состояния узла восстановленного экземпляра выполните:
```
mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s3          |        3306 | RECOVERING   |
| s2          |        3306 | ONLINE       |
| s1          |        3306 | ONLINE       |
+-------------+-------------+--------------+
```
Это показывает, что s3 применяет транзакции, чтобы догнать группу. После того, как он догонит остальные узлы группы, его состояние member_state изменится на ONLINE:
```
mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s3          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s1          |        3306 | ONLINE       |
+-------------+-------------+--------------+
```
Примечание

Если восстанавливаемый сервер является первичным узлом, после того, как он синхронизировался с группой и стал ONLINE, выполните шаги в конце Восстановление первичного узла для отмены внесенных вами изменений в конфигурации сервера перед запуском.

Узел теперь восстановлен в группе как новый узел.

Восстановление первичного узла. Если восстановленный узел является первичным в группе, необходимо принять меры, чтобы предотвратить запись в восстановленную базу данных во время фазы восстановления Group Replication: в зависимости от того, как к группе обращаются клиенты, есть вероятность, что операторы DML будут выполняться на восстановленном узле после того, как он станет доступным в сети, до того, как узел завершит обработку пропущенных операций в группе. Чтобы этого избежать, перед запуском восстановленного сервера настройте следующие переменные системы в файле параметров сервера:

group_replication_start_on_boot=OFF
super_read_only=ON
event_scheduler=OFF

Эти настройки гарантируют, что узел станет только для чтения при запуске и что планировщик событий будет отключен, пока узел догоняет группу во время фазы восстановления. Также необходимо настроить надлежащую обработку ошибок на клиентах, так как им временно будет запрещено выполнять операции DML в этот период на восстановленном узле. После завершения процесса восстановления и синхронизации восстановленного узла с остальными узлами группы, верните эти изменения; перезапустите планировщик событий:

mysql> SET global event_scheduler=ON;

Измените следующие переменные системы в файле параметров узла, чтобы они были правильно настроены для следующего запуска:

group_replication_start_on_boot=ON
super_read_only=OFF
event_scheduler=ON