20.5.6 Using MySQL Enterprise Backup with Group Replication — MySQL 8.4

20.5.6 Использование MySQL Enterprise Backup с Group Replication

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

Создание резервной копии члена Group Replication с помощью MySQL Enterprise Backup

Создание резервной копии члена Group Replication аналогично созданию резервной копии автономной 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

Восстановление неисправного члена

Предположим, что один из членов (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 и mysqld-auto.cnf (если он существует), скопировав их в безопасное место за пределами каталога данных. Это необходимо для сохранения UUID сервера UUID сервера и Раздела 7.1.9.3, «Переменные системы, сохраняемые в БД» (если они используются), которые необходимы на следующих шагах.
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 имеют одинаковое имя файла и находятся в одинаковых местоположениях на двух серверах. Если эти условия не выполнены, вы должны использовать опции для восстановления бинарного лога и релейного лога в их исходные пути файлов на 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, что и при присоединении к группе ранее. Укажите старый UUID сервера, скопировав файл auto.cnf, сохраненный на шаге 2, в каталог данных восстановленного члена.

Примечание

Если вы не можете предоставить восстановленному члену оригинальный server_uuid поврежденного члена, восстановив его старый файл auto.cnf, необходимо разрешить восстановленному члену присоединиться к группе в качестве нового члена; см. инструкции в Перестроение поврежденного члена для повторного присоединения в качестве нового члена, как это сделать.
Восстановить файл mysqld-auto.cnf для s3 (требуется только если s3 использовал переменные системы, сохраняемые в БД). Параметры Раздела 7.1.9.3, «Переменные системы, сохраняемые в БД», которые использовались для настройки поврежденного члена, должны быть предоставлены восстановленному члену. Эти параметры находятся в файле mysqld-auto.cnf поврежденного сервера, который вы должны были сохранить на шаге 2. Восстановите файл в каталог данных восстановленного сервера. См. Восстановление переменных системы, сохраняемых в БД, что делать, если у вас нет копии файла.
Запустить восстановленный сервер. Например, в дистрибутивах Linux, использующих systemd:
```
systemctl start mysqld
```
Примечание

Если восстанавливаемый сервер является первичным членом, выполните шаги, описанные в Восстановление первичного члена перед запуском восстановленного сервера.
Перезапустить Group Replication. Подключитесь к перезапущенному s3 с помощью, например, клиента 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 |
+-------------+-------------+--------------+
| 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. Сохраните файл конфигурации mysqld-auto.cnf, если он найден в каталоге данных поврежденного сервера, скопировав его в безопасное место вне каталога данных. Это необходимо для сохранения переменных сервера Раздел 7.1.9.3, «Постоянные системные переменные», которые понадобятся позже.
3. Удалите все содержимое каталога данных для s3. Например:
```
s3> rm -rf /var/lib/mysql/*
```
  Если системные переменные innodb_data_home_dir, innodb_log_group_home_dir и innodb_undo_directory указывают на каталоги, отличные от каталога данных, их также следует очистить; в противном случае операция восстановления завершится сбоем.
4. Восстановите резервную копию 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
```
  Примечание
  
  Если у вас есть исправные бинарные и релейные логи в резервной копии, которые можно без проблем перенести на целевой хост, рекомендуется следовать более простому методу, как описано в Восстановлении неисправного члена выше.
Восстановите файл mysqld-auto.cnf для s3 (требуется только если s3 использовал постоянные системные переменные). Параметры Раздела 7.1.9.3, «Постоянные системные переменные», которые использовались для настройки неисправного члена, должны быть предоставлены восстановленному серверу. Эти настройки можно найти в файле mysqld-auto.cnf неисправного сервера, который вы должны были сохранить на шаге 2 выше. Восстановите файл в каталог данных восстановленного сервера. См. Восстановление постоянных системных переменных, что делать, если у вас нет копии файла.

Примечание

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

Если восстанавливаемый сервер является первичным членом, выполните шаги, описанные в Восстановление первичного члена перед запуском восстановленного сервера.
Настройте восстановленный член для присоединения к группе Group Replication. Подключитесь к восстановленному серверу с помощью клиента mysql и сбросьте информацию о источнике и реплике с помощью следующих инструкций:
```
mysql> RESET BINARY LOGS AND GTIDS;

mysql> RESET REPLICA 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 на члене, используя SQL-запросы, показанные здесь:
```
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user',
    ->   SOURCE_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, выполните шаги, описанные в конце Восстановление первичного члена, чтобы отменить внесенные вами изменения в конфигурацию сервера до его запуска.

Член теперь восстановлен в группе в качестве нового члена.

Восстановление постоянных системных переменных. mysqlbackup не поддерживает создание резервных копий или сохранение Раздела 7.1.9.3, «Постоянные системные переменные» — файл mysqld-auto.cnf не включен в резервную копию. Чтобы запустить восстановленный член со своими настройками постоянных переменных, вам необходимо выполнить одно из следующих действий:

Сохраните копию файла mysqld-auto.cnf с поврежденного сервера и скопируйте ее в каталог данных восстановленного сервера.
Скопируйте файл mysqld-auto.cnf с другого члена группы в каталог данных восстановленного сервера, если этот член имеет такие же постоянные системные переменные, что и поврежденный член.
После запуска восстановленного сервера и перед перезапуском Group Replication вручную установите все системные переменные в их постоянные значения через клиент mysql.

Восстановление первичного члена. Если восстановленный член является первичным в группе, необходимо позаботиться о предотвращении записи в восстановленную базу данных во время процесса распределенного восстановления 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