このページは機械翻訳したものです。
クローンプラグインでは、リモートデータをクローニングするための次の構文がサポートされています。つまり、リモート MySQL サーバーインスタンス (ドナー) からクローニング操作が開始された MySQL インスタンス (受信者) にデータをクローニングして転送します。
CLONE INSTANCE FROM 'user'@'host':port
IDENTIFIED BY 'password'
[DATA DIRECTORY [=] 'clone_dir']
[REQUIRE [NO] SSL];
ここでは:
は、ドナー MySQL サーバーインスタンス上のクローンユーザーです。user
はpassword
のパスワードです。user
は、ドナー MySQL サーバーインスタンスのhost
hostname
アドレスです。 インターネットプロトコルバージョン 6 (IPv6) アドレス形式はサポートされていません。 かわりに、IPv6 アドレスのエイリアスを使用できます。 IPv4 アドレスはそのまま使用できます。
は、ドナー MySQL サーバーインスタンスのport
port
番号です。 (mysqlx_port
で指定された X プロトコル ポートはサポートされていません。 MySQL Router を介したドナー MySQL サーバーインスタンスへの接続もサポートされていません。)-
DATA DIRECTORY [=] '
は、クローニングするデータの受信者上のディレクトリを指定するために使用するオプションの句です。 このオプションは、受信者データディレクトリ内の既存のデータを削除しない場合に使用します。 絶対パスが必要であり、ディレクトリが存在していない必要があります。 MySQL サーバーには、ディレクトリの作成に必要な書込みアクセス権が必要です。clone_dir
'オプションの
DATA DIRECTORY [=] '
句を使用しない場合、クローニング操作では、受信者データディレクトリ内の既存のデータが削除され、クローニングされたデータに置き換えられ、その後サーバーが自動的に再起動されます。clone_dir
' [REQUIRE [NO] SSL]
は、クローニングされたデータをネットワーク経由で転送するときに、暗号化された接続を使用するかどうかを明示的に指定します。 明示的な指定が満たされない場合は、エラーが返されます。 SSL 句が指定されていない場合、クローンはデフォルトで暗号化された接続を確立しようとし、セキュアな接続試行が失敗した場合はセキュアでない接続にフォールバックします。 暗号化データをクローニングする場合は、この句が指定されているかどうかに関係なく、セキュアな接続が必要です。 詳細は、クローニング用の暗号化された接続の構成を参照してください。
デフォルトでは、ドナー MySQL サーバーインスタンスのデータディレクトリに存在するユーザー作成の InnoDB
テーブルおよびテーブルスペースは、受信者 MySQL サーバーインスタンスのデータディレクトリにクローニングされます。 DATA DIRECTORY [=] '
句を指定すると、指定したディレクトリにクローニングされます。
clone_dir
'
ドナー MySQL サーバーインスタンスのデータディレクトリ外にあるユーザー作成の InnoDB
テーブルおよびテーブルスペースは、受信者 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 サーバーインスタンスでクローンプラグインがアクティブである必要があります。 インストールの手順については、セクション5.6.7.1「クローンプラグインのインストール」を参照してください。
クローニング操作 (「「クローンユーザー」」) を実行するには、ドナーおよび受信者の MySQL ユーザーが必要です。
ドナーでは、クローンユーザーには、ドナーからデータにアクセスして転送し、クローニング操作中に DDL をブロックするための
BACKUP_ADMIN
権限が必要です。受信者では、クローンユーザーに、受信者データの置換、クローニング操作中の DDL のブロック、およびサーバーの自動再起動のための
CLONE_ADMIN
権限が必要です。CLONE_ADMIN
権限には、BACKUP_ADMIN
およびSHUTDOWN
権限が暗黙的に含まれます。
クローンユーザーを作成し、必要な権限を付与する手順は、この前提条件情報に続くリモートクローニングの例に含まれています。
CLONE INSTANCE
ステートメントの実行時には、次の前提条件がチェックされます:
-
ドナーと受信者の 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 [=] '
句で指定されたディレクトリ (使用されている場合) にクローニングされます。 このため、ドナーでの undo テーブルスペースファイル名の重複は許可されません。 MySQL 8.0.18 では、クローニング操作中に重複する undo テーブルスペースファイル名が検出されると、エラーがレポートされます。 MySQL 8.0.18 より前は、同じファイル名の undo テーブルスペースをクローニングすると、受信者で undo テーブルスペースファイルが上書きされる可能性がありました。clone_dir
'ドナーで 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「クローンシステム変数」を参照してください。
次の例は、リモートデータのクローニングを示しています。 デフォルトでは、リモートクローニング操作により、受信者データディレクトリ内のデータが削除され、クローニングされたデータに置き換えられ、後で MySQL サーバーが再起動されます。
この例では、リモートクローニングの前提条件を満たしていることを前提としています。 リモートクローニングの前提条件を参照してください。
-
管理ユーザーアカウントでドナー MySQL サーバーインスタンスにログインします。
-
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';
-
クローンプラグインをインストールします:
mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';
-
-
管理ユーザーアカウントで受信者 MySQL サーバーインスタンスにログインします。
-
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';
-
クローンプラグインをインストールします:
mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';
-
ドナー MySQL サーバーインスタンスのホストアドレスを
clone_valid_donor_list
変数設定に追加します。mysql> SET GLOBAL clone_valid_donor_list = 'example.donor.host.com:3306';
-
-
以前に作成したクローンユーザー (
recipient_clone_user'@'example.recipient.host.com
) として受信者 MySQL サーバーインスタンスにログオンし、CLONE INSTANCE
ステートメントを実行します。mysql> CLONE INSTANCE FROM 'donor_clone_user'@'example.donor.host.com':3306 IDENTIFIED BY 'password';
データがクローニングされると、受信者の MySQL サーバーインスタンスが自動的に再起動されます。
クローニング操作のステータスおよび進行状況の監視の詳細は、セクション5.6.7.9「クローニング操作の監視」 を参照してください。
デフォルトでは、リモートクローニング操作によって受信者データディレクトリ内のデータが削除され、クローニングされたデータに置き換えられます。 名前付きディレクトリにクローニングすることで、受信者データディレクトリから既存のデータを削除しないようにできます。
名前付きディレクトリにクローニングする手順は、リモートデータのクローニング で説明されている手順と同じですが、例外があります: 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 サーバーを再起動する場合は、手動で再起動する必要があります:
shell> mysqld_safe --datadir=/path/to/clone_dir
ここで、/path/to/clone_dir
は受信者の指定されたディレクトリへのパスです。
リモートクローニング操作の暗号化された接続を構成して、ネットワーク経由でクローニングされるデータを保護できます。 暗号化されたデータをクローニングする場合は、デフォルトで暗号化された接続が必要です (セクション5.6.7.4「暗号化データのクローニング」 を参照)。)
次の手順では、暗号化された接続を使用するように受信者 MySQL サーバーインスタンスを構成する方法について説明します。 ドナー MySQL サーバーインスタンスは、暗号化された接続を使用するようにすでに構成されていることを前提としています。 そうでない場合は、サーバー側の構成手順について セクション6.3.1「暗号化接続を使用するための MySQL の構成」 を参照してください。
暗号化された接続を使用するように受信者 MySQL サーバーインスタンスを構成するには:
-
ドナー MySQL サーバーインスタンスのクライアント証明書およびキーファイルを受信者ホストで使用できるようにします。 セキュアなチャネルを使用して受信者ホストにファイルを配布するか、受信者ホストにアクセス可能なマウントされたパーティションにファイルを配置します。 使用可能にするクライアント証明書およびキーファイルには、次のものがあります:
-
ca.pem
自己署名認証局 (CA) ファイル。
-
client-cert.pem
クライアント公開キー証明書ファイル。
-
client-key.pem
クライアント秘密キーファイル。
-
-
受信者 MySQL サーバーインスタンスで次の SSL オプションを構成します。
-
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
-
-
暗号化された接続を使用する必要がある場合は、受信者に対して
CLONE
ステートメントを発行するときにREQUIRE SSL
句を含めます。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
を使用するとエラーが発生します。