このページは機械翻訳したものです。

5.6.7.8 リモートクローニング操作の失敗処理

このセクションでは、クローニング操作の様々な段階での障害処理について説明します。

1. 前提条件がチェックされます (リモートクローニングの前提条件 を参照)。

   • 前提条件チェック中に障害が発生した場合、CLONE INSTANCE 操作によってエラーが報告されます。

2. DDL 操作をブロックするためにバックアップロックが取得されます。

   • クローニング操作で、clone_ddl_timeout 変数で指定された時間制限内に DDL ロックを取得できない場合は、エラーが報告されます。

3. 受信者のユーザー作成データ (スキーマ、テーブル、テーブルスペース) およびバイナリログは、データが受信者データディレクトリにクローニングされる前に削除されます。

   • リモートクローニング操作中にユーザーが作成したデータが受信者から削除されると、受信者データディレクトリ内の既存のデータは保存されず、障害が発生した場合に失われる可能性があります。 受信者で置き換えるデータが重要な場合は、リモートクローニング操作を開始する前にバックアップを作成する必要があります。

     情報提供のために、データの削除がいつ開始および終了するかを指定する警告がサーバーエラーログに出力されます:

     [Warning] [MY-013453] [InnoDB] Clone removing all user data for provisioning:
     Started...
     
     [Warning] [MY-013453] [InnoDB] Clone removing all user data for provisioning:
     Finished

     データの削除中に障害が発生した場合は、クローニング操作の前に存在していたスキーマ、テーブルおよびテーブルスペースの一部が受信者に残される可能性があります。 クローニング操作の実行中または障害の発生後は、サーバーは常に一貫性のある状態になります。

4. データはドナーからクローニングされます。 ユーザー作成データ、ディクショナリメタデータおよびその他のシステムデータがクローニングされます。

   • データのクローニング中に障害が発生した場合、クローニング操作はロールバックされ、クローニングされたすべてのデータが削除されます。 この段階では、受信者の既存のデータも削除され、受信者にはユーザーデータが残されません。

     このシナリオが発生した場合は、失敗の原因を修正してクローニング操作を再実行するか、クローニング操作を忘れてクローニング操作の前に作成したバックアップから受信者データをリストアできます。

5. サーバーは自動的に再起動されます (名前付きディレクトリにクローニングしないリモートクローニング操作に適用されます)。 起動時には、一般的なサーバー起動タスクが実行されます。

   • サーバーの自動再起動が失敗した場合は、サーバーを手動で再起動してクローニング操作を完了できます。

クローニング操作中にネットワークエラーが発生した場合、エラーが 5 分以内に解決されると操作は再開されます。 それ以外の場合、操作は中止され、エラーが返されます。