ドナーでは、クローンユーザーには、ドナーからデータにアクセスして転送し、クローニング操作中に DDL をブロックするための BACKUP_ADMIN 権限が必要です。

受信者では、クローンユーザーに、受信者データの置換、クローニング操作中の DDL のブロック、およびサーバーの自動再起動のための CLONE_ADMIN 権限が必要です。 CLONE_ADMIN 権限には、BACKUP_ADMIN および SHUTDOWN 権限が暗黙的に含まれます。

ドナーと受信者の MySQL サーバーバージョンは同じである必要があります。 クローンプラグインは MYSQL 8.0.17 以上でサポートされます。

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

ドナーおよび受信者の MySQL サーバーインスタンスは、同じオペレーティングシステムおよびプラットフォーム上で実行する必要があります。 たとえば、ドナーインスタンスが Linux 64-bit プラットフォームで実行されている場合、受信者インスタンスもそのプラットフォームで実行される必要があります。 オペレーティングシステムのプラットフォームを決定する方法の詳細は、オペレーティングシステムのドキュメントを参照してください。

受信者には、クローンデータ用の十分なディスク領域が必要です。 デフォルトでは、ドナーデータをクローニングする前に受信者データが削除されるため、ドナーデータに十分な領域のみが必要です。 DATA DIRECTORY 句を使用して名前付きディレクトリにクローニングする場合は、既存の受信者データおよびクローンデータ用の十分なディスク領域が必要です。 データのサイズを見積もるには、ファイルシステムのデータディレクトリサイズと、データディレクトリの外部にあるテーブルスペースのサイズを確認します。 ドナーでデータサイズを見積もる場合は、InnoDB データのみがクローニングされることに注意してください。 データをほかのストレージエンジンに格納する場合は、それに応じてデータサイズの見積りを調整します。

InnoDB では、データディレクトリ外に一部のテーブルスペースタイプを作成できます。 ドナー MySQL サーバーインスタンスにデータディレクトリの外部に存在するテーブルスペースがある場合、クローニング操作はそれらのテーブルスペースにアクセスできる必要があります。 INFORMATION_SCHEMA.FILES テーブルをクエリーして、データディレクトリの外部にあるテーブルスペースを識別できます。 データディレクトリの外部にあるファイルには、データディレクトリ以外のディレクトリへの完全修飾パスがあります。

mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES;

ドナー上でアクティブなプラグイン (キーリングプラグインを含む) も、受信者上でアクティブである必要があります。 アクティブなプラグインを識別するには、SHOW PLUGINS ステートメントを発行するか、INFORMATION_SCHEMA.PLUGINS テーブルをクエリーします。

ドナーと受信者は、同じ MySQL サーバー文字セットと照合順序を持つ必要があります。 MySQL サーバーの文字セットおよび照合順序の構成の詳細は、セクション10.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';

暗号化されたデータまたはページ圧縮されたデータをクローニングする場合、ドナーと受信者のファイルシステムのブロックサイズは同じである必要があります。 ページ圧縮データの場合、受信者でホールパンチが発生するには、受信者ファイルシステムがスパースファイルとホールパンチをサポートしている必要があります。 これらの機能と、それらを使用するテーブルおよびテーブルスペースの識別方法の詳細は、セクション5.6.7.4「暗号化データのクローニング」 および セクション5.6.7.5「圧縮データのクローニング」 を参照してください。 ファイルシステムのブロックサイズを確認するには、オペレーティングシステムのドキュメントを参照してください。

暗号化されたデータをクローニングする場合は、セキュアな接続が必要です。 クローニング用の暗号化された接続の構成を参照してください。

受信者の clone_valid_donor_list 設定には、ドナー MySQL サーバーインスタンスのホストアドレスを含める必要があります。 有効なドナーリストのホストからのみデータをクローニングできます。 この変数を構成するには、SYSTEM_VARIABLES_ADMIN 権限を持つ MySQL ユーザーが必要です。 clone_valid_donor_list 変数の設定手順は、このセクションの後のリモートクローニングの例で説明します。 SHOW VARIABLES 構文を使用して、clone_valid_donor_list 設定を確認できます。

mysql> SHOW VARIABLES LIKE 'clone_valid_donor_list';

他のクローニング操作は実行しないでください。 一度に許可されるのは単一のクローニング操作のみです。 クローン操作が実行されているかどうかを確認するには、clone_status テーブルをクエリーします。 パフォーマンススキーマクローンテーブルを使用したクローニング操作のモニタリングを参照してください。

クローンプラグインは、1M バイトのパケットとメタデータでデータを転送します。 したがって、ドナーおよび受信者の MySQL サーバーインスタンスで必要な max_allowed_packet の最小値は 2MB です。 2MB 未満の max_allowed_packet 値はエラーになります。 次のクエリーを使用して、max_allowed_packet 設定を確認します:

mysql> SHOW VARIABLES LIKE 'max_allowed_packet';

ドナーの undo テーブルスペースファイル名は一意である必要があります。 データが受信者にクローニングされると、undo テーブルスペースは、ドナー上の場所に関係なく、受信者の innodb_undo_directory の場所または DATA DIRECTORY [=] 'clone_dir'句で指定されたディレクトリ (使用されている場合) にクローニングされます。 このため、ドナーでの undo テーブルスペースファイル名の重複は許可されません。 MySQL 8.0.18 では、クローニング操作中に重複する undo テーブルスペースファイル名が検出されると、エラーがレポートされます。 MySQL 8.0.18 より前は、同じファイル名の undo テーブルスペースをクローニングすると、受信者で undo テーブルスペースファイルが上書きされる可能性がありました。

ドナーで undo テーブルスペースのファイル名を表示して一意であることを確認するには、INFORMATION_SCHEMA.FILES にクエリーします:

mysql> SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES
       WHERE FILE_TYPE LIKE 'UNDO LOG';

undo テーブルスペースファイルの削除および追加の詳細は、セクション15.6.3.4「undo テーブルスペース」 を参照してください。

デフォルトでは、受信者 MySQL サーバーインスタンスは、データのクローニング後に自動的に再起動 (停止および起動) されます。 自動再起動を実行するには、受信者で監視プロセスを使用してサーバーの停止を検出する必要があります。 それ以外の場合、クローニング操作は、データのクローニング後に次のエラーで停止し、受信者の MySQL サーバーインスタンスが停止します:

ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).

このエラーはクローニングの失敗を示しません。 つまり、受信者の MySQL サーバーインスタンスは、データのクローニング後に手動で再起動する必要があります。 サーバーを手動で起動した後、受信者の MySQL サーバーインスタンスに接続し、パフォーマンススキーマクローンテーブルをチェックして、クローニング操作が正常に完了したことを確認できます (パフォーマンススキーマクローンテーブルを使用したクローニング操作のモニタリング を参照)。) RESTART ステートメントのモニタリングプロセス要件は同じです。 詳細は、セクション13.7.8.8「RESTART ステートメント」を参照してください。 この場合、自動再起動は実行されないため、DATA DIRECTORY 句を使用して名前付きディレクトリにクローニングする場合、この要件は適用されません。

リモートクローニング操作の様々な側面を制御する変数がいくつかあります。 リモートクローニング操作を実行する前に、変数を確認し、使用しているコンピューティング環境に合せて必要に応じて設定を調整します。 クローン変数は、クローニング操作が実行される受信者 MySQL サーバーインスタンスに設定されます。 セクション5.6.7.12「クローンシステム変数」を参照してください。