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

最終更新日: 2020 年 10 月 21 日

Amazon Aurora クラスターでクラスタークローン、スナップショット復元、またはポイントインタイム操作を実行しています。この復元に時間がかかっているのはなぜですか? また、この問題を解決するにはどうすればよいですか?

簡単な説明

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

解決方法

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

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

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

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

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

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

注: AWS CLI または API を使用して復元操作を実行する場合、CreateDBInstance 呼び出しは自動ではないため、必ず呼び出してください。

ソースデータベースでの長時間実行の書き込み操作の確認

長時間のクラッシュリカバリを防ぐ最善の方法は、スナップショット、ポイントインタイム、またはクローンの時点で、ソースデータベース上で長時間実行される書き込み操作が実行されていないことを確認することです。長時間実行される DCL、DDL、または DML (オープン書き込みトランザクション) によって、復元されたデータベースが使用可能になるまでにかかる時間が長くなる場合があります。

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

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

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