7.6.7.7 Cloning for Replication — MySQL 9.2

7.6.7.7 Клонирование для репликации

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

Члены Групповой репликации также могут быть настроены на использование плагина клонирования в качестве варианта для распределенного восстановления, в этом случае присоединяющиеся члены автоматически выбирают наиболее эффективный способ получения данных группы от существующих членов группы. Для получения дополнительной информации см. Раздел 20.5.4.2, «Клонирование для распределенного восстановления».

Во время операции клонирования извлекается и передается как позиция бинарного журнала (имя файла, смещение), так и gtid_executed набор GTID с экземпляра сервера MySQL донора на получателя. Эти данные позволяют инициировать репликацию в согласованной позиции в потоке репликации. Бинарные журналы и журналы ретрансляции, которые хранятся в файлах, не копируются с донора на получателя. Для инициирования репликации бинарные журналы, необходимые для того, чтобы получатель догнал донора, не должны быть удалены между временем клонирования данных и временем запуска репликации. Если необходимые бинарные журналы недоступны, генерируется ошибка рукопожатия репликации. Следовательно, клонированный экземпляр должен быть добавлен в группу репликации без чрезмерной задержки, чтобы избежать удаления необходимых бинарных журналов или существенного отставания нового члена, что потребует большего времени восстановления.

Выполните эту команду на клонированном экземпляре сервера MySQL, чтобы проверить позицию бинарного журнала, которая была передана получателю:
```
mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;
```
Выполните эту команду на клонированном экземпляре сервера MySQL, чтобы проверить gtid_executed набор GTID, который был передан получателю:
```
mysql> SELECT @@GLOBAL.GTID_EXECUTED;
```

По умолчанию хранилища метаданных репликации хранятся в таблицах, которые копируются с донора на получателя во время операции клонирования. Хранилища метаданных репликации содержат настройки конфигурации, связанные с репликацией, которые могут быть использованы для правильного возобновления репликации после операции клонирования. Таблицы mysql.slave_master_info, mysql.slave_relay_log_info и mysql.slave_worker_info также копируются.

Список того, что включено в каждую таблицу, см. в Разделе 19.2.4.2, «Хранилища метаданных репликации».

Для клонирования для репликации выполните следующие шаги:

Для нового члена группы для Групповой репликации сначала настройте экземпляр сервера MySQL для Групповой репликации, следуя инструкциям в Разделе 20.2.1.6, «Добавление экземпляров в группу». Также настройте предварительные условия для клонирования, описанные в Разделе 20.5.4.2, «Клонирование для распределенного восстановления». При выполнении START GROUP_REPLICATION в присоединяющемся члене операция клонирования автоматически управляется Групповой репликацией, поэтому вам не нужно выполнять ее вручную и не нужно выполнять какие-либо дополнительные шаги настройки на присоединяющемся члене.
Для реплики в топологии репликации MySQL «источник/реплика» сначала вручную клонируйте данные с экземпляра сервера MySQL донора на получателя. Донор должен быть источником или репликой в топологии репликации. Инструкции по клонированию см. в Разделе 7.6.7.3, «Клонирование удаленных данных».
После успешного завершения операции клонирования, если вы хотите использовать те же каналы репликации на экземпляре сервера MySQL получателя, что и на доноре, проверьте, какие из них могут автоматически возобновить репликацию в топологии репликации MySQL «источник/реплика», а какие необходимо настроить вручную.
- Для репликации на основе GTID, если получатель настроен с gtid_mode=ON и клонирован с донора с gtid_mode=ON, ON_PERMISSIVE или OFF_PERMISSIVE, на получателе применяется gtid_executed набор GTID с донора. Если получатель клонирован с реплики, уже находящейся в топологии, каналы репликации на получателе, использующие автоматическое позиционирование GTID, могут автоматически возобновить репликацию после операции клонирования при запуске канала. Вам не нужно выполнять ручную настройку, если вы просто хотите использовать эти же каналы.
- Для репликации на основе позиции файла бинарного журнала позиция бинарного журнала с донора применяется на получателе. Каналы репликации на получателе, использующие репликацию на основе позиции файла бинарного журнала, автоматически пытаются выполнить процесс восстановления журнала ретрансляции, используя информацию клонированного журнала ретрансляции, перед перезапуском репликации. Для однопоточной реплики (replica_parallel_workers установлено в 0), восстановление журнала ретрансляции должно быть успешным при отсутствии других проблем, что позволяет каналу возобновить репликацию без дальнейшей настройки. Для многопоточной реплики (replica_parallel_workers больше 0), восстановление журнала ретрансляции, скорее всего, не удастся, поскольку обычно оно не может быть завершено автоматически. В этом случае выводится сообщение об ошибке, и вам необходимо настроить канал вручную.
Если вам нужно настроить каналы клонированной репликации вручную или вы хотите использовать разные каналы репликации на получателе, следующие инструкции предоставляют краткое изложение и сокращенные примеры добавления экземпляра сервера MySQL получателя в топологию репликации. Также обратитесь к подробным инструкциям, применимым к вашей настройке репликации.
- Для добавления экземпляра сервера MySQL получателя в топологию репликации MySQL, использующей транзакции на основе GTID в качестве источника данных репликации, настройте экземпляр в соответствии с требованиями, следуя инструкциям в Разделе 19.1.3.4, «Настройка репликации с использованием GTID». Добавьте каналы репликации для экземпляра, как показано в следующем сокращенном примере. Оператор CHANGE REPLICATION SOURCE TO должен определить адрес хоста и номер порта источника, и опция SOURCE_AUTO_POSITION должна быть включена, как показано:
```
CHANGE SOURCE TO SOURCE_HOST = 'source_host_name', SOURCE_PORT = source_port_num,
       ...
       SOURCE_AUTO_POSITION = 1,
       FOR CHANNEL 'setup_channel';
START REPLICA USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel';
```
- Для добавления экземпляра сервера MySQL получателя в топологию репликации MySQL, использующей репликацию на основе позиции файла бинарного журнала, настройте экземпляр в соответствии с требованиями, следуя инструкциям в Разделе 19.1.2, «Настройка репликации на основе позиции файла бинарного журнала». Добавьте каналы репликации для экземпляра, как показано в следующем сокращенном примере, используя позицию файла бинарного журнала, которая была передана получателю во время операции клонирования:
```
SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;
CHANGE SOURCE TO SOURCE_HOST = 'source_host_name', SOURCE_PORT = source_port_num,
       ...
       SOURCE_LOG_FILE = 'source_log_name',
       SOURCE_LOG_POS = source_log_pos,
       FOR CHANNEL 'setup_channel';
START REPLICA USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel';
```