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

На приемнике пользователю clone требуется привилегия CLONE_ADMIN для замены данных приемника, блокировки операций DDL на приемнике во время операции клонирования и автоматической перезагрузки сервера. Привилегия CLONE_ADMIN неявно включает привилегии BACKUP_ADMIN и SHUTDOWN.

Донор и приемник должны быть серверами MySQL одной серии, например 8.4.0 и 8.4.11. Чтобы определить версию MySQL сервера, выполните следующий запрос:

mysql> SHOW VARIABLES LIKE 'version';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| version       | 9.2.0 |
+---------------+-------+

Донорский и приемник 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.

Плагин clone передает данные пакетами по 1 МБ плюс метаданные. Таким образом, минимальное необходимое значение max_allowed_packet составляет 2 МБ на донорском и приемнике MySQL серверах. Значение 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, «Переменные системы клонирования».