7.6.7.3 Cloning Remote Data — MySQL 8.4

7.6.7.3 Клонирование удаленных данных

Плагин клонирования поддерживает следующий синтаксис для клонирования удаленных данных; то есть, клонирования данных с удалённого сервера MySQL (донор) и их переноса на сервер MySQL, на котором была инициирована операция клонирования (получатель).

CLONE INSTANCE FROM 'user'@'host':port
IDENTIFIED BY 'password'
[DATA DIRECTORY [=] 'clone_dir']
[REQUIRE [NO] SSL];

где:

user — пользователь для клонирования на донорском сервере MySQL.
password — пароль user.
host — адрес hostname донорского сервера MySQL. Формат адресов Internet Protocol версии 6 (IPv6) не поддерживается. Вместо этого можно использовать псевдоним для адреса IPv6. Адрес IPv4 можно использовать непосредственно.
port — номер port донорского сервера MySQL. (Порт X Protocol, указанный в mysqlx_port, не поддерживается. Подключение к донорскому серверу MySQL через MySQL Router также не поддерживается.)
DATA DIRECTORY [=] 'clone_dir' — необязательная часть, используемая для указания каталога на получателе для клонируемых данных. Используйте этот параметр, если вы не хотите удалять существующие данные, созданные пользователем (схемы, таблицы, табличные пространства) и двоичные журналы с каталога данных получателя. Требуется абсолютный путь, а каталог не должен существовать. Сервер MySQL должен иметь необходимые права записи для создания каталога.

Если необязательная часть DATA DIRECTORY [=] 'clone_dir' не используется, операция клонирования удаляет данные, созданные пользователем (схемы, таблицы, табличные пространства) и двоичные журналы из каталога данных получателя, клонирует новые данные в каталог данных получателя и автоматически перезапускает сервер после этого.
[REQUIRE [NO] SSL] явно указывает, использовать ли зашифрованное соединение при передаче клонированных данных по сети. Если явное указание невозможно выполнить, возвращается ошибка. Если условие SSL не указано, клонирование пытается установить зашифрованное соединение по умолчанию, переходя к незащищённому соединению, если попытка установить защищённое соединение терпит неудачу. Защищённое соединение требуется при клонировании зашифрованных данных независимо от того, указано ли это условие. Для получения дополнительной информации см. Настройка зашифрованного соединения для клонирования.

Примечание

По умолчанию, таблицы и табличные пространства, созданные пользователем InnoDB, которые находятся в каталоге данных на донорском сервере MySQL, клонируются в каталог данных на сервере MySQL получателе. Если указано условие DATA DIRECTORY [=] 'clone_dir', они клонируются в указанный каталог.

Таблицы и табличные пространства, созданные пользователем InnoDB, которые находятся вне каталога данных на донорском сервере MySQL, клонируются в тот же путь на сервере MySQL получателе. Если таблица или табличное пространство уже существуют, выводится ошибка.

По умолчанию, системные табличные пространства InnoDB, журналы redo и табличные пространства undo клонируются в те же места, что и на доноре (как определено в innodb_data_home_dir и innodb_data_file_path, innodb_log_group_home_dir и innodb_undo_directory соответственно). Если указано условие DATA DIRECTORY [=] 'clone_dir', эти табличные пространства и журналы клонируются в указанный каталог.

Предварительные условия удаленного клонирования

Для выполнения операции клонирования плагин клонирования должен быть активен как на донорском, так и на реципиентном сервере MySQL. Инструкции по установке см. в разделе 7.6.7.1, «Установка плагина клонирования».

Для выполнения операции клонирования требуется пользователь MySQL на донорском и реципиентном серверах (пользователь “пользователь клонирования”).

На донорском сервере пользователю клонирования требуется привилегия BACKUP_ADMIN для доступа и передачи данных с донорского сервера и блокирования одновременных DDL-операций во время операции клонирования. Одновременные DDL-операции по умолчанию разрешены на донорском сервере. См. раздел 7.6.7.4, «Клонирование и одновременные DDL».
На реципиентном сервере пользователю клонирования требуется привилегия CLONE_ADMIN для замены данных на реципиентном сервере, блокирования DDL-операций на реципиентном сервере во время операции клонирования и автоматического перезапуска сервера. Привилегия CLONE_ADMIN неявно включает привилегии BACKUP_ADMIN и SHUTDOWN.

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

Следующие предварительные условия проверяются при выполнении инструкции CLONE INSTANCE:

Донорский и реципиентный серверы должны быть одного семейства, например, 8.4.0 и 8.4.11. Чтобы определить версию сервера MySQL, выполните следующий запрос:
```
mysql> SHOW VARIABLES LIKE 'version';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| version       | 8.4.4 |
+---------------+-------+
```
Донорский и реципиентный серверы MySQL должны работать на одной операционной системе и платформе. Например, если донорский сервер работает на 64-битной платформе Linux, реципиентный сервер также должен работать на этой платформе. Справочная информация по вашей операционной системе содержит сведения о том, как определить вашу операционную систему и платформу.
На реципиентном сервере должно быть достаточно дискового пространства для данных, подлежащих клонированию. По умолчанию данные, созданные пользователем (схемы, таблицы, табличные пространства) и двоичные журналы удаляются на реципиентном сервере перед клонированием данных с донорского сервера, поэтому вам требуется только достаточно места для данных донорского сервера. Если вы клонируете в указанный каталог с использованием ключевого слова DATA DIRECTORY, вам должно быть достаточно дискового пространства для существующих данных реципиентного сервера и данных, подлежащих клонированию. Размер данных можно оценить, проверив размер каталога данных в вашей файловой системе и размер всех табличных пространств, расположенных вне каталога данных. При оценке размера данных на донорском сервере помните, что клонируются только данные InnoDB. Если данные хранятся в других хранилищах, скорректируйте оценку размера данных в соответствии с этим.
InnoDB позволяет создавать некоторые типы табличных пространств вне каталога данных. Если на донорском сервере MySQL есть табличные пространства, расположенные вне каталога данных, операция клонирования должна иметь возможность доступа к этим табличным пространствам. Вы можете запросить таблицу Information Schema FILES, чтобы определить табличные пространства, расположенные вне каталога данных. Файлы, расположенные вне каталога данных, имеют полное путь к каталогу, отличном от каталога данных.
```
mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES;
```
Плагины, активные на донорском сервере, включая любой плагин ключей, должны быть активны и на реципиентном сервере. Активные плагины можно определить, выполнив инструкцию SHOW PLUGINS или запросив таблицу Information Schema PLUGINS.
Донорский и реципиентный серверы должны иметь один и тот же набор символов и правила сопоставления сервера MySQL. Сведения о конфигурации набора символов и правил сопоставления сервера MySQL см. в разделе 12.15, «Настройка наборов символов».
Требуются одинаковые значения innodb_page_size и innodb_data_file_path на донорском и реципиентном серверах. Значение innodb_data_file_path на донорском и реципиентном серверах должно указывать на то же количество файлов данных эквивалентного размера. Настройки переменных можно проверить, используя синтаксис SHOW VARIABLES.
```
mysql> SHOW VARIABLES LIKE 'innodb_page_size';
mysql> SHOW VARIABLES LIKE 'innodb_data_file_path';
```
При клонировании зашифрованных или сжатых по страницам данных донорский и реципиентный серверы должны иметь одинаковый размер блока файловой системы. Для данных, сжатых по страницам, файловая система реципиентного сервера должна поддерживать разреженные файлы и удаление дыр для удаления дыр на реципиентном сервере. Сведения об этих функциях и о том, как определить таблицы и табличные пространства, которые их используют, см. в разделе 7.6.7.5, «Клонирование зашифрованных данных» и разделе 7.6.7.6, «Клонирование сжатых данных». Информация о размере блока файловой системы содержится в документации вашей операционной системы.
Для клонирования зашифрованных данных требуется безопасное подключение. См. Настройка зашифрованного подключения для клонирования.
Настройка clone_valid_donor_list на реципиентном сервере должна содержать адрес хоста донорского сервера MySQL. Вы можете клонировать данные только с хоста, входящего в список допустимых доноров. Для настройки этой переменной требуется пользователь MySQL с привилегией SYSTEM_VARIABLES_ADMIN. Инструкции по настройке переменной clone_valid_donor_list приведены в примере удаленного клонирования, следующем за этим разделом. Значение clone_valid_donor_list можно проверить с помощью синтаксиса SHOW VARIABLES.
```
mysql> SHOW VARIABLES LIKE 'clone_valid_donor_list';
```
Не должно выполняться других операций клонирования. Одновременно разрешена только одна операция клонирования. Чтобы определить, выполняется ли операция клонирования, запросите таблицу clone_status. См. Мониторинг операций клонирования с использованием таблиц Performance Schema Clone.
Плагин клонирования передает данные пакетами по 1 МБ плюс метаданные. Таким образом, минимальное необходимое значение max_allowed_packet на донорском и реципиентном серверах MySQL составляет 2 МБ. Значение max_allowed_packet меньше 2 МБ приводит к ошибке. Используйте следующий запрос, чтобы проверить настройку max_allowed_packet:
```
mysql> SHOW VARIABLES LIKE 'max_allowed_packet';
```

Применимы также следующие предварительные условия:

Имена файлов таблиц отката на доноре должны быть уникальными. При клонировании данных на получателя таблицы отката, независимо от их расположения на доноре, клонируются в расположение innodb_undo_directory на получателе или в каталог, указанный в предложении DATA DIRECTORY [=] 'clone_dir', если оно используется. По этой причине дублирование имён файлов таблиц отката на доноре недопустимо. При обнаружении дублирующихся имён файлов таблиц отката во время операции клонирования будет сообщено об ошибке.

Для просмотра имён файлов таблиц отката на доноре, чтобы убедиться в их уникальности, запросите таблицу FILES:
```
mysql> SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES
       WHERE FILE_TYPE LIKE 'UNDO LOG';
```
Сведения о удалении и добавлении файлов таблиц отката см. в разделе 17.6.3.4, «Undo Tablespaces».
По умолчанию экземпляр сервера MySQL получателя автоматически перезапускается (останавливается и запускается) после клонирования данных. Для автоматического перезапуска должен быть доступен процесс мониторинга на получателе, который обнаруживает остановки сервера. В противном случае, после клонирования данных операция клонирования завершается с ошибкой:
```
ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).
```
Эта ошибка не указывает на сбой клонирования. Это означает, что экземпляр сервера MySQL получателя необходимо запустить вручную после клонирования данных. После ручного запуска сервера вы можете подключиться к экземпляру сервера MySQL получателя и проверить таблицы производительности Performance Schema, чтобы убедиться, что операция клонирования выполнена успешно (см. Мониторинг операций клонирования с помощью таблиц Performance Schema Clone Tables.) У предписания RESTART также есть требование к процессу мониторинга. Более подробную информацию см. в разделе 15.7.8.8, «RESTART Statement». Это требование не применимо, если клонирование выполняется в указанный каталог, используя предложение DATA DIRECTORY, так как автоматический перезапуск в этом случае не выполняется.
Несколько переменных контролируют различные аспекты операции удаленного клонирования. Перед выполнением операции удалённого клонирования необходимо ознакомиться с переменными и, при необходимости, настроить параметры, подходящие для вашей вычислительной среды. Переменные клонирования устанавливаются на экземпляре сервера MySQL получателя, где выполняется операция клонирования. См. раздел 7.6.7.13, «Переменные системы клонирования».

Клонирование удалённых данных

Следующий пример демонстрирует клонирование удалённых данных. По умолчанию операция удалённого клонирования удаляет созданные пользователем данные (схемы, таблицы, табличные пространства) и двоичные логи на получателе, клонирует новые данные в каталог данных получателя и перезапускает сервер MySQL после этого.

Пример предполагает, что требования к удалённому клонированию выполнены. См. Требования к удалённому клонированию.

Войдите на экземпляр сервера MySQL донора с учётной записью администратора.
1. Создайте пользователя клонирования с привилегией BACKUP_ADMIN.
```
mysql> CREATE USER 'donor_clone_user'@'example.donor.host.com' IDENTIFIED BY 'password';
mysql> GRANT BACKUP_ADMIN on *.* to 'donor_clone_user'@'example.donor.host.com';
```
2. Установите плагин клонирования:
```
mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';
```
Войдите на экземпляр сервера MySQL получателя с учётной записью администратора.
1. Создайте пользователя клонирования с привилегией CLONE_ADMIN.
```
mysql> CREATE USER 'recipient_clone_user'@'example.recipient.host.com' IDENTIFIED BY 'password';
mysql> GRANT CLONE_ADMIN on *.* to 'recipient_clone_user'@'example.recipient.host.com';
```
2. Установите плагин клонирования:
```
mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';
```
3. Добавьте адрес хоста экземпляра сервера MySQL донора в настройку переменной clone_valid_donor_list.
```
mysql> SET GLOBAL clone_valid_donor_list = 'example.donor.host.com:3306';
```
Войдите на экземпляр сервера MySQL получателя как созданный ранее пользователь клонирования (recipient_clone_user'@'example.recipient.host.com) и выполните предписание CLONE INSTANCE.
```
mysql> CLONE INSTANCE FROM 'donor_clone_user'@'example.donor.host.com':3306
       IDENTIFIED BY 'password';
```
После клонирования данных экземпляр сервера MySQL на получателе автоматически перезапускается.

Сведения о мониторинге состояния и ходе операции клонирования см. в разделе 7.6.7.10, «Мониторинг операций клонирования».

Клонирование в указанный каталог

По умолчанию операция удалённого клонирования удаляет созданные пользователем данные (схемы, таблицы, табличные пространства) и двоичные логи из каталога данных получателя перед клонированием данных с экземпляра сервера MySQL донора. Клонируя в указанный каталог, вы можете избежать удаления данных из текущего каталога данных получателя.

Процедура клонирования в указанный каталог аналогична процедуре, описанной в разделе о клонировании удалённых данных с одним исключением: в предписании CLONE INSTANCE должно быть указано предложении DATA DIRECTORY. Например:

mysql> CLONE INSTANCE FROM 'user'@'example.donor.host.com':3306
       IDENTIFIED BY 'password'
       DATA DIRECTORY = '/path/to/clone_dir';

Требуется абсолютный путь, и каталог не должен существовать. Сервер MySQL должен иметь необходимые права записи для создания каталога.

При клонировании в указанный каталог экземпляр сервера MySQL получателя не перезапускается автоматически после клонирования данных. Если вы хотите перезапустить сервер MySQL в указанном каталоге, сделайте это вручную:

$> mysqld_safe --datadir=/path/to/clone_dir

где /path/to/clone_dir — путь к указанному каталогу на получателе.

Настройка защищённого подключения для клонирования

Вы можете настроить защищённое соединение для операций удалённого клонирования, чтобы защитить данные во время клонирования по сети. Зашифрованное соединение требуется по умолчанию при клонировании зашифрованных данных. (см. раздел 7.6.7.5, «Клонирование зашифрованных данных».)

Ниже описано, как настроить экземпляр сервера MySQL получателя для использования защищённого соединения. Предполагается, что экземпляр сервера MySQL донора уже настроен на использование защищённых соединений. Если нет, см. раздел 8.3.1, «Настройка MySQL для использования защищённых соединений» для инструкций по конфигурации сервера.

Чтобы настроить экземпляр сервера MySQL получателя для использования защищённого соединения:

Сделайте файлы сертификата и ключа клиента экземпляра сервера MySQL донора доступными для хоста получателя. Либо передайте файлы на хост получателя по защищённому каналу, либо поместите их в смонтированный раздел, доступный для хоста получателя. К таким файлам относятся:
- ca.pem
  
  Файл сертификата центра сертификации (CA) с собственноручной подписью.
- client-cert.pem
  
  Файл сертификата открытого ключа клиента.
- client-key.pem
  
  Файл закрытого ключа клиента.
Настройте следующие параметры SSL на экземпляре сервера MySQL получателя.
- clone_ssl_ca
  
  Указывает путь к файлу сертификата центра сертификации (CA) с собственноручной подписью.
- clone_ssl_cert
  
  Указывает путь к файлу сертификата открытого ключа клиента.
- clone_ssl_key
  
  Указывает путь к файлу закрытого ключа клиента.
Например:
```
clone_ssl_ca=/path/to/ca.pem
clone_ssl_cert=/path/to/client-cert.pem
clone_ssl_key=/path/to/client-key.pem
```
Чтобы потребовать использование защищённого соединения, включите предложение REQUIRE SSL при вызове предписания CLONE на получателе.
```
mysql> CLONE INSTANCE FROM 'user'@'example.donor.host.com':3306
       IDENTIFIED BY 'password'
       DATA DIRECTORY = '/path/to/clone_dir'
       REQUIRE SSL;
```
Если предложение SSL не указано, плагин клонирования пытается установить защищённое соединение по умолчанию, возвращаясь к незащищённому соединению, если попытка защищённого соединения завершается неудачей.

Примечание

Если вы клонируете зашифрованные данные, защищённое соединение требуется по умолчанию, независимо от того, указано ли предложение REQUIRE SSL. Использование REQUIRE NO SSL вызывает ошибку при попытке клонирования зашифрованных данных.