Amazon RDS for MySQL インスタンスのポイントインタイムリカバリの実行に時間がかかるのはなぜですか?

簡単な説明

ポイントインタイムリカバリ (PITR) は、データベースを指定された日付と時刻の状態に復元するプロセスです。PITR を開始すると、最新のバックアップ (自動または手動) が復元されます。トランザクションログは、Amazon RDS データベースを PITR 時間までロールフォワードするために適用されます。

解決方法

長いポイントインタイムリカバリを回避するためのベストプラクティス

長いポイントインタイムリカバリを回避するには、次のベストプラクティスに従ってください:

• 災害対策戦略を作成します。
• 小規模なトランザクションを使用し、COMMIT コマンドをより頻繁に実行します。
• 大規模なトランザクションを実行するには、大規模なトランザクションの前後にスナップショットを作成します。ただし、max_allowed_packet パラメータより大きいトランザクションは PITR が失敗するしてしまいます。
• そのため、スナップショットの復元時間を最小限にしてください。スナップショットの復元は、ポイントインタイムリカバリプロセスの一部として開始されます。スナップショットの復元が長くなると、ポイントインタイムリカバリセッションが長くなる可能性があります。詳細については、「Amazon RDS for MySQL DB インスタンスのスナップショットの復元に時間がかかるのはなぜですか?」を参照してください。
• 適用するログの数によっては、ログ適用プロセスに時間がかかることがあります。適用するログの数を減らすには、自動バックアップの間に手動のスナップショットを作成することを検討してください。ポイントインタイムリカバリでは、PITR 時間近くで作成された自動スナップショットまたは手動スナップショットが自動的に選択されるため、中間の手動スナップショットを使用すると、適用するログの数を減らすことができます。大量の変更を処理する場合は、3～4 時間ごとに手動スナップショットを作成します。
• 大規模なトランザクションをリプレイする場合、 wait_timeout 値を小さくすると、Amazon RDS for MySQL のポイントインタイム復元プロセスが中断する可能性があります。たとえば、大規模な行ベースの一括更新、挿入、または削除を実行しており、再生に wait_timeout よりも長い時間がかかる場合、中断が発生します。PITR プロセスの中断を防ぐには、 wait_timeout 値を「600」(10 分) 以上に設定します。詳細については、Amazon RDS for MySQL の構成パラメータのベストプラクティスにある wait_timeout セクションを参照してください。
• 行ベースのバイナリロギングを使用する場合は、 binlog_row_image パラメーター値を「FULL」ではなく「MINIMAL」に設定することを検討してください。この更新された値は、バイナリログのサイズを縮小し、バイナリログのリカバリ時間を最小限に抑えます。
• 特定の binlog 形式が必要でない限り、MIXED ログ形式の使用を検討してください。混合ロギングでは、デフォルトでステートメントベースのロギングが使用されますが、ロギングモードは必要に応じて自動的に行ベースに切り替わります。この切り替えは、バイナリログのサイズを減らすのに役立ちます。MIXED ロギングの詳細については、MySQL Web サイトのバイナリロギング形式を参照してください。

ポイントインタイムリカバリの失敗

次のシナリオでは、ポイントインタイムリカバリが失敗します。

• 「ストレージがいっぱい」状態の DB インスタンス。
• MySQL で MyISAM テーブルを使用する。MyISAM ストレージエンジンは、信頼性の高いクラッシュリカバリプロセスをサポートしていません。MyISAM テーブルは、ポイントインタイムリカバリプロセスが適切に機能しないようにします。
• 一時テーブル、分散トランザクション、およびインメモリテーブルの使用。