20.5.6 Using MySQL Enterprise Backup with Group Replication — MySQL 9.2

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