Amazon RDS for MySQL DB インスタンスのスナップショットの復元に時間がかかるのはなぜですか?

簡単な説明

スナップショットの復元時間が長くなるのは、通常、データベースリカバリに時間がかかることが原因です。リカバリ時間は、スナップショット作成時のインスタンスのワークロードに左右されます。ソース DB インスタンスでバイナリログが有効になっている場合、リカバリに時間がかかることがあります。その結果、スナップショットの復元時間も影響を受ける可能性があります。

解決方法

スナップショットを復元すると、Amazon RDS はリカバリプロセスを実行し、新しい DB インスタンスで MySQL DB エンジンが起動します。インスタンスの起動中のリカバリセッションの長さによっては、新しい DB インスタンスの開始に数分かかる場合があります。詳細については、MySQL ウェブサイトの「InnoDB クラッシュリカバリ」を参照してください。

注: ボリュームが Amazon Simple Storage Service (Amazon S3) から完全にハイドレートされるまで、レイテンシー (または読み込みの遅延) が発生します。読み込みの遅延の詳細については、「スナップショットからの復元」を参照してください。

Amazon RDS でのスナップショットの復元の完了時間を短縮するには、次のアプローチを検討してください。

• オフピーク時に DB インスタンスのバックアップウィンドウをスケジュールするか、DB インスタンスの手動スナップショットを作成します。スナップショットの作成中にソース DB インスタンスで実行されるアクティビティは、データベースのリカバリ時間とスナップショットの復元時間に影響します。
• ソースインスタンスがスナップショット中に磁気ストレージタイプを使用している場合、新しく復元されたインスタンスは変更中の状態になります。例えば、DB スナップショットを汎用 SSD (GP2) またはプロビジョンド IOPS (PIOPS) ストレージタイプとして復元すると、基礎となるボリュームが変更されます。その結果、新しいインスタンスは「変更中」の状態を示します。この間、Amazon RDS インスタンスに接続することはできますが、パフォーマンスが低下する可能性があります。
• インスタンスを一時的に上位の DB インスタンスクラス (メモリまたは RAM が多いインスタンスクラスなど) に復元します。DB インスタンスクラスをアップグレードすることで、クラッシュのリカバリ時間を短縮できます。一時的にリソースが増加し、全体的なクラッシュリカバリ時間を短縮できます。スナップショットの復元が完了したら、インスタンスクラスをスケールダウンできます。

Amazon RDS でバイナリログ記録が有効になっているスナップショットのスナップショット復元完了時間を短縮するには、次の点を考慮してください。

• バイナリログが有効になっている場合 (ソースインスタンスで自動バックアップが有効になっている場合など)、バイナリログはスナップショットの復元時間に直接影響します。クラッシュリカバリ中に、スナップショット復元プロセスによってバイナリログリカバリも実行されます。
• バイナリログのリカバリ時間を短縮するには、大規模なトランザクションや大きなバイナリログファイルを避けてください。バイナリログに記録されるデータが多いほど、バイナリログのリカバリ中に復元プロセスで処理する必要があるデータが増えます。その結果、リカバリ時間が長くなり、スナップショットの復元時間も長くなります。
• 可能な限り、適切なトランザクションサイズを使用してください。大規模なトランザクションは、一度にバイナリログファイルに書き込まれ、異なるファイル間で分割されることはありません。その結果、バイナリログファイルが大きくなり、クラッシュのリカバリ時間が長くなります。
• 使用するバイナリログ形式のタイプは、リカバリの規模と効率にも影響します。一部の形式 (行ベースのログ記録など) は、バイナリログの他の形式よりも多くの情報を記録します。テーブル内の多数の行を変更するステートメントにより、DB エンジンは、変更されたすべての行のバイナリログエントリを生成します。その結果、取得するバイナリログファイルが大きくなります。行ベースのログ記録形式の詳細については、MySQL ウェブサイトの「行ベースのログ記録とレプリケーションの使用」を参照してください。さまざまなタイプのバイナリログ記録形式の詳細については、MySQL ウェブサイトの「ステートメントベースおよび行ベースのレプリケーションの長所と短所」を参照してください。