Amazon RDS for MySQL インスタンスで、スナップショットの復元時間を短縮する方法を教えてください。

簡単な説明

スナップショットの復元時間が長くなる一般的な理由は、データベースのリカバリに時間がかかることです。データベースの復旧時間は、スナップショットが発生したときのインスタンスのワークロードに基づいています。ソース DB インスタンスでバイナリログ記録を有効にした場合、復旧とスナップショットの復元に時間がかかる場合があります。

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

注: ボリュームが Amazon シンプルストレージサービス (Amazon S3) から完全に復元されるまでは、ある程度の遅延や読み込みの低速化が発生します。詳細については、「DB スナップショットでの復元」を参照してください。

ポイントインタイムリカバリ (PITR) については、「Amazon RDS for MySQL インスタンスのポイントインタイムリカバリの実行に時間がかかる理由を教えてください」を参照してください。

解決策

スナップショットの復元時間を短縮するには、次のベストプラクティスに従ってください。

• バックアップ期間をスケジュールするか、ピーク時以外に DB インスタンスのスナップショットを手動で作成します。スナップショットを作成すると、ソース DB インスタンスで実行するアクティビティにより、データベースとスナップショットの復旧時間が影響を受けます。
• ソースインスタンスがスナップショット中にマグネティックストレージタイプを使用している場合、復元されたインスタンスは変更中ステータスになります。たとえば、DB スナップショットのストレージタイプを汎用 SSD gp2 や プロビジョンド IOPS として復元するとボリュームの変更が行われます。  この期間は Amazon RDS インスタンスに接続できますが、パフォーマンスが低下する可能性があります。
• インスタンスを一時的に上位の DB インスタンスクラスに復元します。DB インスタンスクラスをアップグレードすると、一時的にリソースが増え、クラッシュからの回復時間が短縮されます。  スナップショットの復元が完了したら、インスタンスクラスをスケールダウンしても問題ありません。

バイナリのログ記録がオンになっているスナップショットでスナップショット復元時間を短縮するには、次のベストプラクティスに従ってください。

• binlog のリカバリ時間を短縮するには、大量のトランザクションやサイズの大きい binlog ファイルは避けてください。大量のデータを含むバイナリログでは、binlog の回復時間が長くなります。さらに、スナップショットの復元時間も長くなります。
• 適切なトランザクションサイズを使用します。大規模なトランザクションは、バイナリログファイルに一度に書き込まれ、別々のファイルに分割されることはありません。その結果、バイナリログファイルが大きくなり、クラッシュからの回復時間が長くなります。
• 適切なバイナリログ記録形式を使用してください。バイナリログ記録形式は、クラッシュリカバリの規模と効率に影響する可能性があります。詳細については、MySQL のウェブサイトで「行ベースのログ記録とレプリケーションの使用」を参照してください。バイナリログ記録形式の詳細については、MySQL のウェブサイトで「](https://dev.mysql.com/doc/refman/5.7/en/replication-sbr-rbr.html)ステートメントベースおよび行ベースレプリケーションの利点と欠点[」を参照してください。

注: 低速な読み込みをより早く完了するには、Amazon RDS インスタンスタイプと、より高いスループットの Amazon Elastic Block Store (Amazon EBS) ボリュームを使用します。低速な読み込みが完了したら、インスタンスクラスタイプをダウングレードして IOPS とスループットの値を下げても問題ありません。