Amazon RDS DB インスタンスが再起動、回復、またはフェイルオーバーしたのはなぜですか?
Amazon Relational Database Service (Amazon RDS) DBインスタンスの再起動、回復、フェイルオーバーの根本原因を知りたいです。
簡単な説明
Amazon RDS データベースインスタンスは、次の条件下で自動的に再起動を実行します。
- プライマリアベイラビリティゾーンで可用性が失われるか、パフォーマンスのボトルネックとリソースの競合が原因で過剰なワークロードが発生しています。
- プライマリインスタンスへのネットワーク接続の喪失、プライマリのコンピューティングユニットの問題、プライマリのストレージの問題など、プライマリインスタンスに基盤となるインフラストラクチャの問題があります。
- DB インスタンスクラスタイプは、DB インスタンスの垂直スケーリングアクティビティの一環として変更されます。
- RDS DB インスタンスの基盤となるホストは、特定のメンテナンス時間中にソフトウェアパッチが適用されています。詳細については、「DB インスタンスのメンテナンス」および「DB インスタンスのエンジンバージョンのアップグレード」を参照してください。
- [Reboot] または [Reboot with failover] オプションを使用して、DB インスタンスの手動再起動を開始しました。
DB インスタンスに潜在的な問題が示され、RDS ヘルスチェックに応答しない場合、RDS はシングル AZ デプロイのシングル AZ 復旧とマルチ AZ 配置のマルチ AZ フェイルオーバーを自動的に開始します。その後、DB インスタンスが再起動され、管理者の介入なしにデータベース操作をできるだけ早く再開できます。
解決方法
停止の原因を特定するには、RDS DB インスタンスの次のログとメトリクスを確認します。
Amazon RDS イベント
インスタンスの予期しない停止の根本原因を特定するために、過去 24 時間のすべての Amazon RDS イベントを表示します。デフォルトでは、すべてのイベントが UTC/GMT 時間で登録されます。イベントを長期間保存するには、Amazon RDS イベントを Amazon CloudWatch Events に送信します。詳細については、「Amazon RDS イベントでトリガーするルールの作成」を参照してください。インスタンスが再起動すると、RDS イベント通知に次のメッセージのいずれかが表示されます。
-
The RDS instance was modified by customer (RDS インスタンスはお客様によって変更されました): この RDS イベントメッセージは、RDS インスタンスの変更によってフェイルオーバーが開始されたことを示しています。
-
**データベースインスタンスクラスへの変更の適用:**この RDS イベントメッセージは、DB インスタンスクラスタイプが変更されたことを示します。
- シングル AZ 配置は、このスケーリング操作中に数分間使用できなくなります。
- マルチ AZ 配置は、インスタンスのフェイルオーバーにかかる時間中は利用できません。この時間は通常約 60 秒です。これは、新しいサイズのデータベースでフェールオーバーが発生する前にスタンバイデータベースがアップグレードされるためです。続いて、データベースが再起動され、エンジンがリカバリを実行し、データベースが一貫した状態に保たれるようにします。
-
ユーザーが DB インスタンスのフェイルオーバーをリクエストしました: このメッセージは、[Reboot] または [Reboot with failover] オプションを使用して DB インスタンスの手動再起動を開始したことを示します。
-
The primary host of the RDS Multi-AZ instance is unhealthy (RDS マルチ AZ インスタンスのプライマリホストが異常です): この理由は、プライマリインスタンスへの通信が失われる原因となった、基盤となるハードウェアの一時的な問題を示しています。RDS モニタリングシステムが RDS インスタンスと通信してヘルスチェックを実行できなかったため、この問題によりインスタンスが異常な状態になった可能性があります。
-
The primary host of the RDS Multi-AZ instance is unreachable due to loss of network connectivity (RDS マルチ AZ インスタンスのプライマリホストで、ネットワーク接続が切断されたため、到達できません): この理由は、Multi-AZ フェイルオーバーとデータベースインスタンスの再起動が、マルチ AZ 配置のプライマリホストに影響を与えた一時的なネットワーク問題によって引き起こされたことを示しています。内部モニタリングシステムがこの問題を検出し、フェイルオーバーを開始しました。
-
The RDS Multi-AZ primary instance is busy and unresponsive (RDS マルチ AZ プライマリインスタンスはビジーで応答しません)、「the Multi-AZ instance activation started (マルチ AZ インスタンスのアクティベーションが開始されました)」、または the Multi-AZ instance activation completed (マルチ AZ インスタンスのアクティベーションが完了しました): イベントログにこれらのメッセージが表示されるのは、次のような場合です。
- プライマリ DB インスタンスが応答しません。
- データベースでメモリを過剰に消費した後のメモリ不足により、RDS モニタリングシステムが基盤となるホストに接続できませんでした。したがって、予防的な対策として、監視システムによってデータベースが再起動されます。
- DB インスタンスで、基盤となるホストとの間に断続的なネットワークの問題が発生しました。
- インスタンスでデータベースの負荷が発生しました。この場合、CloudWatch メトリクス CPUUtilization、DatabaseConnections、IOPS メトリクス、およびスループットの詳細が急増していることに気付く場合があります。また、Freeablemory の枯渇に気づくかもしれません。
-
Database instance patch: このメッセージは、インスタンスで [Auto minor version upgrade] 設定が有効になっているため、メンテナンス時間中に DB インスタンスがマイナーバージョンアップグレードを受けたことを示します。
CloudWatch メトリクス
Amazon RDS インスタンスの CloudWatch メトリクスを表示して、データベースの負荷の問題が停止の原因になっているかどうかをチェックします。詳細については、「Amazon CloudWatch を使用した Amazon RDS メトリクスのモニタリング」を参照してください。RDS インスタンスの可用性と正常性を示す次の主要メトリクスの急増を確認します。
- DatabaseConnections
- CPUUtilization
- FreeableMemory
- WriteIOPS
- ReadIOPS
- 読み取りスループット
- 書き込みスループット
- DiskQueueDepth
拡張モニタリング
Amazon RDS では、拡張モニタリングのメトリクスをお客様の Amazon CloudWatch Logs アカウントに提供します。これにより、DB インスタンスが実行されているオペレーティングシステムのメトリクスがリアルタイムで提供されます。DB インスタンスのすべてのシステムメトリクスとプロセス情報をコンソールで表示できます。
拡張モニタリング機能の詳細度は、1、5、10、15、30、または 60 に設定できます。
Amazon RDS インスタンスの拡張モニタリングをオンにするには、「拡張モニタリングの設定と有効化」を参照してください。
Performance Insights
Performance Insights ダッシュボードには、パフォーマンスの問題の分析やトラブルシューティングに役立つデータベースのパフォーマンスに関する情報が含まれています。また、DB インスタンスで過剰なリソースを消費するクエリと待機イベントを特定することもできます。Performance Insights がデータベースレベルでデータを収集し、そのデータは Performance Insights ダッシュボードに表示されます。詳細については、「Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング」を参照してください。アプリケーション側からリソース消費量が増加した場合は、Performance Insights ダッシュボードのサポート SQL ID を使用して、対応するクエリと照合します。この情報を使用してクエリのパフォーマンスを調整し、DBA のガイダンスを使用してワークロードを最適化することがベストプラクティスです。
- Amazon RDS コンソールを開きます。
- ナビゲーションペインで、[Performance Insights] を選択します。
- [Performance Insights] ページで、DB インスタンスを選択します。この DB インスタンスの Performance Insights ダッシュボードを表示できます。
- 問題が発生した時間枠を選択します。
- [Top SQL] (上位の SQL) タブを選択します。
- 設定アイコンを選択し、Support ID をオンにします。
- [Save] (保存) を選択します。
RDS データベースログ
Amazon RDS DB インスタンスの停止の原因をトラブルシューティングするには、Amazon RDS コンソールまたは Amazon RDS API オペレーションを使用して、データベースログファイルを表示、ダウンロード、または監視できます。データベーステーブルにロードされているいくつかのデータベースログファイルをクエリすることもできます。詳細については、「Monitoring Amazon RDS log files」(Amazon RDS ログファイルのモニタリング) を参照してください。
RDS インスタンスの停止に対処する際には、次のベストプラクティスに留意してください。
- インスタンスでマルチ AZ 配置を有効にして、停止中のダウンタイムを短縮します。マルチ AZ 配置では、RDS は、異なるアベイラビリティーゾーンまたは 2 つの読み取り可能なスタンバイに同期スタンバイレプリカを自動的にプロビジョニングして維持します。詳細については、「Amazon RDS Multi-AZ」を参照してください。
- お好みに応じて DB インスタンスのメンテナンス時間を調整します。この間、DB インスタンスは、DB インスタンスクラスの変更などシステムの変更が適用され停止が必要な場合に限り、必要な変更を行うための最低限の時間、使用できません。詳細については、「DB インスタンスのメンテナンス」を参照してください。インスタンスに自動マイナーバージョンアップグレードを行わないようにするには、このオプションをオフにします。詳細については、「マイナーエンジンバージョンの自動アップグレード」を参照してください。
- クエリを実行するのに十分なリソースがデータベースに割り当てられていることを確認してください。Amazon RDS では、割り当てられるリソースの量はインスタンスタイプによって異なります。また、ストアドプロシージャなどの特定のクエリは、メモリを無制限に消費することがあります。したがって、リソース不足のためにインスタンスが頻繁に再起動する場合は、データベースインスタンスクラスをスケールアップして、アプリケーションの需要の高まりに対応することを検討してください。
- インスタンスのスロットリングを回避するには、RDS インスタンスの可用性と正常性を示す RDS キーメトリクスに Amazon CloudWatch アラームを設定します。たとえば、FreeableMemory メトリクスに CloudWatch アラームを設定して、利用可能なメモリが 95% に到達したときに通知を受け取ることができます。インスタンスメモリを 5% 以上空けておくのがベストプラクティスです。詳細については、「拡張モニタリングの CloudWatch Logs をフィルタリングして、Amazon RDS のために自動化されたカスタムメトリクスを生成するにはどうすればよいですか?」を参照してください。
- RDS インスタンスでフェイルオーバーが発生したときに通知を受けるには、Amazon RDS イベント通知をサブスクライブします。詳細については、「Amazon RDS イベントの購読を作成するにはどうすれば良いですか?」を参照してください。
- データベースのパフォーマンスを最適化するには、クエリが適切に調整されていることを確認してください。適切に調整されていない場合、パフォーマンスの問題が発生し、待機時間が長くなる可能性があります。
- CPU、メモリ、またはその他のリソース不足に関するあらゆる種類の負荷のトラブルシューティングを行うには、「Amazon RDS または Amazon Aurora PostgreSQL の CPU 使用率が高い場合のトラブルシューティング方法を教えてください」を参照してください。
関連情報
Amazon RDS のダウンタイムやデータベースのパフォーマンスにはどのような要因が影響しますか?
Amazon RDS DB インスタンスがフェイルオーバーしたのはなぜですか?
関連するコンテンツ
- 質問済み 1年前lg...
- 質問済み 21時間前lg...
- 質問済み 12日前lg...
- AWS公式更新しました 1ヶ月前
- AWS公式更新しました 2年前
- AWS公式更新しました 1年前
- AWS公式更新しました 2年前