Amazon Aurora DB クラスターのクローン、スナップショット復元、またはポイントインタイム復元に時間がかかるのはなぜですか?

簡単な説明

Amazon Aurora の継続的なバックアップと復元手法は、復元時間の変化を回避するために最適化されています。また、クラスターが使用可能になり次第、クラスターのストレージボリュームがフルパフォーマンスに達するのにも役立ちます。一般的に、復元時間が長くなる原因は、バックアップが作成される時点においてソースデータベースで長時間実行されているトランザクションが原因です。

解決方法

注: AWS コマンドラインインターフェイス (AWS CLI) のコマンド実行中にエラーが発生した場合は、AWS CLI の最新バージョンを使用していることを確認してください。

Amazon Aurora は、クラスターボリュームの変更を自動的かつ継続的にバックアップします。バックアップは、バックアップ保持期間中は保持されます。この継続的なバックアップにより、データを新しいクラスター (指定された保持期間内の特定の時点) に復元できます。これにより、時間がかかる binlog のロールフォワードプロセスの必要性がなくなります。新しいクラスターを作成するため、パフォーマンスに対する影響や元のデータベースの中断はありません。

クローン、スナップショット、またはポイントインタイム復元を開始すると、Amazon Relational Database Service (Amazon RDS) はお客様に代わって次の API を呼び出します。

• RestoreDBClusterFromSnapshot または RestoreDBClusterToPointInTime。これらの API により、新しいクラスターが作成され、Amazon Simple Storage Service (Amazon S3) からボリュームが復元されます。この処理が完了するまでに最長で数時間かかる場合があります。Aurora クラスターにデータを復元すると、すべてのデータが Amazon S3 から 3 つのアベイラビリティーゾーンの 6 つのコピーに並行して取り込まれます。
• クラスターストレージボリュームのクローン作成 は、RestoreDBClusterToPointInTime のバリエーションです。コピーオンライトプロトコルを使用し、通常は数分で完了します。

このステップが完了すると、クラスターは [Available] (使用可能) の状態に変わります。コンソールを更新するか、AWS CLI でチェックすることで、クラスターの状態を確認できます。

インスタンスの作成プロセスは、クラスターが [Available] (使用可能) の場合にのみ開始されます。これは、インスタンス設定のセットアップとデータベースのクラッシュリカバリの 2 つの段階で発生します。

API がインスタンスのセットアップを完了したかどうかを確認するには、MySQL エラーログファイルを探します。インスタンスのステータスが [Creating] (作成中) の場合でも、これを行うことができます。エラーログファイルがダウンロード可能な場合は、インスタンスがセットアップされ、エンジンがクラッシュリカバリを実行しています。エラーログファイルは、Amazon CloudWatch メトリクスとともに、データベースのクラッシュリカバリの進行状況を確認するのに最適なリソースでもあります。

注: AWS CLI または API を使用して復元オペレーションを実行する場合、CreateDBInstance 呼び出しは自動ではないため、呼び出す必要があります。

ソースデータベースで長時間実行されている書き込みオペレーションがないかを確認する

スナップショット、ポイントインタイム、またはクローンの時点で、ソースデータベースに対して長時間実行されている書き込みオペレーションがないことを確認するのがベストプラクティスです。長時間実行されている DCL、DDL、または DML (オープン書き込みトランザクション) によって、復元されたデータベースが使用可能になるまでに長時間を要する場合があります。

例えば、Aurora クラスターのバイナリログをアクティブ化すると、リカバリの実行にかかる時間が長くなります。これは、InnoDB が自動的にログをチェックし、現在のデータベースへのロールフォワードを実行するためです。その後、リカバリ時に存在するコミットされていないトランザクションをロールバックします。InnoDB クラッシュリカバリの詳細については、InnoDB リカバリを参照してください。

インスタンスが作成およびリカバリプロセスを完了すると、クラスターとインスタンスは着信接続を受け入れる準備が整います。

注: Aurora はバイナリログを必要としません。必要でない限り、非アクティブ化するのがベストプラクティスです。クロスリージョンレプリケーションの場合は、代わりに Aurora グローバルデータベースを評価できます。Aurora グローバルデータベースもバイナリログを必要としません。

---

関連情報

Amazon Aurora ストレージと信頼性

DB クラスターのスナップショットからの復元