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

最終更新日: 2021 年 10 月 14 日

MySQL の Amazon Relational Database Service (Amazon RDS) でポイントインタイムリカバリ (PITR) を開始しましたが、予想以上に時間がかかっています。この原因は何でしょうか?

簡単な説明

ポイントインタイムリカバリ (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 サイトのバイナリロギング形式を参照してください。

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

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


この記事はお役に立ちましたか?


請求に関するサポートまたは技術サポートが必要ですか?