AWS Builder Center: Learn, Build and Connect with builders in the AWS community

AWS Builder Center is the official home for builders on AWS. Share and read what others are working on, follow people who inspire you, explore training and workshops, and find tools to support what you're building.

Amazon RDS DB インスタンスが再起動、回復、またはフェイルオーバーした理由を教えてください。

所要時間2分

Amazon Relational Database Service (Amazon RDS) データベースインスタンスの再起動、回復、またはフェイルオーバーの根本原因を知りたいです。

簡単な説明

Amazon RDS DB インスタンスは、以下の条件で自動的に再起動を実行します。

プライマリのアベイラビリティーゾーンに可用性の問題が発生した場合か、パフォーマンスのボトルネックとリソースの競合により過剰なワークロードが発生した場合。
プライマリインスタンスの基盤となるインフラストラクチャに問題がある場合。これには、プライマリインスタンスへのネットワーク接続の喪失、またはプライマリインスタンスのコンピュートユニットやストレージの問題が考えられます。
DB インスタンスクラスのタイプが、DB インスタンスの垂直スケーリングアクティビティの一環として変更された場合。
DB インスタンスの基盤となるホストが、特定のメンテナンス時間中に OS パッチを受けている場合。詳細については、「DB インスタンスのメンテナンス」および「DB インスタンスのエンジンバージョンのアップグレード」を参照してください。
[再起動] または [フェイルオーバーによる再起動] オプションを使用して、手動で DB インスタンスの再起動を開始した場合。

DB インスタンスに潜在的な問題が示されており、Amazon RDS ヘルスチェックに応答しない場合、Amazon RDS は次のいずれかのアクションを自動的に実行します。

シングル AZ 配置の場合、Amazon RDS はシングル AZ リカバリを開始します。
マルチ AZ 配置の場合、Amazon RDS はマルチ AZ 配置のマルチ AZ フェイルオーバーを開始します。

その後、Amazon RDS は、管理者の介入なしにデータベース操作をできるだけ早く再開できるように、DB インスタンスを再起動します。

解決策

停止の原因を特定するには、DB インスタンスの次のログとメトリクスを確認してください。また、ベストプラクティスにも必ず従ってください。

Amazon RDS イベントメッセージ

インスタンスの予期しない停止の根本原因を特定するには、過去 24 時間のすべての Amazon RDS イベントを表示します。デフォルトでは、Amazon RDS はすべてのイベントを UTC/GMT 時間で登録します。イベントをより長期間保存するには、Amazon RDS イベントを Amazon CloudWatch Events に送信してください。インスタンスが再起動すると、Amazon RDS イベント通知に次のいずれかのメッセージが表示されます。

The RDS instance was modified by customer

この RDS イベントメッセージは、RDS インスタンスの変更によりフェイルオーバーが開始されたことを示しています。

Applying modification to database instance class

この RDS イベントメッセージは、DB インスタンスクラスのタイプが配置タイプに基づいて変更されたことを示しています。

シングル AZ 配置は、スケーリング操作中に数分間使用できなくなります。
マルチ AZ 配置は、インスタンスがフェイルオーバーする間は使用できません。この所要時間は通常約 60 秒です。この遅延が発生するのは、新しくサイズを変更されたデータベースでフェイルオーバーが発生する前に、スタンバイデータベースがアップグレードされるためです。その後、データベースが再起動し、エンジンがリカバリを実行して、データベースが整合性のある状態に保たれるようにします。

The user requested a failover of the DB instance

このメッセージは、ユーザーが [再起動] または [フェイルオーバーによる再起動] オプションを使用して手動で DB インスタンスの再起動を開始したことを示しています。

The primary host of the RDS Multi-AZ instance is unhealthy
この理由は、基盤となるハードウェアの一時的な問題により、プライマリインスタンスとの通信が失われたことを示しています。この問題により、RDS モニタリングシステムが RDS インスタンスと通信してヘルスチェックを実行できなかったため、インスタンスが異常とみなされた可能性があります。

The primary host of the RDS Multi-AZ instance is unreachable due to loss of network connectivity

この理由は、マルチ AZ 配置のプライマリホストに影響した一時的なネットワークの問題により、マルチ AZ のフェイルオーバーとデータベースインスタンスの再起動が発生したことを示しています。内部監視システムがこの問題を検出し、フェイルオーバーを開始しました。

The RDS Multi-AZ primary instance is busy and unresponsive, the Multi-AZ instance activation started, or the Multi-AZ instance activation completed

このイベントログには、次の状況でこれらのメッセージが表示されます。

プライマリ DB インスタンスが応答しない場合。
データベースでメモリを過剰に消費した後のメモリ不足により、Amazon RDS モニタリングシステムが基盤となるホストに通信できなくなった場合。予防措置として、監視システムがデータベースを再起動します。
DB インスタンスで、基盤となるホストとのネットワークの問題が断続的に発生した場合。
インスタンスでデータベース負荷が発生した場合。この場合、CloudWatch メトリクス CPUUtilization、DatabaseConnections、IOPS メトリクス、およびスループットの詳細が急増している可能性があります。また、FreeableMemory が枯渇していることに気付く場合もあります。

Database instance patched

このメッセージは、DB インスタンスがメンテナンス時間中にマイナーバージョンアップグレードが実施されたことを示しています。このメッセージは、インスタンスのマイナーバージョン自動アップグレード設定がオンになっているために表示されます。

CloudWatch メトリクス

データベース負荷の問題が停止の原因となったかどうかを確認するには、Amazon RDS インスタンスの CloudWatch メトリクスを確認します。以下の主要メトリクスが急増している場合は、RDS インスタンスの可用性とヘルスステータスに問題がある可能性があります。

DatabaseConnections
CPUUtilization
FreeableMemory
WriteIOPS
ReadIOPS
ReadThroughput
WriteThroughput
DiskQueueDepth

拡張モニタリング

Amazon RDS は、拡張モニタリングからのメトリクスをお客様の Amazon CloudWatch Logs アカウントに配信します。この機能は、DB インスタンスが実行されているオペレーティングシステムのメトリクスをリアルタイムで提供します。DB インスタンスのすべてのシステムメトリクスとプロセス情報をコンソールで表示できます。

Database Insights

CloudWatch Database Insights ダッシュボードには、パフォーマンス問題の分析とトラブルシューティングに使用できるデータベースパフォーマンスに関する情報が含まれています。Database Insights ダッシュボードを使用して、クエリの統計情報を分析します。このダッシュボードの情報を使用してクエリのパフォーマンスを調整し、ワークロードを最適化するのがベストプラクティスです。詳細については、「CloudWatch Database Insights のデータベースインスタンスダッシュボードの表示」を参照してください。

注: 問題を軽減するには、データベース管理者と協力してこれらの変更を行うことがベストプラクティスです。

RDS データベースログ

DB インスタンスの停止原因をトラブルシューティングするには、Amazon Aurora と RDS コンソールまたは Amazon RDS API オペレーションを使用してデータベースログファイルを表示、ダウンロード、または監視します。データベーステーブルにロードされたデータベースログファイルを照会することもできます。詳細については、「Amazon RDS ログファイルのモニタリング」を参照してください。

RDS インスタンスの停止に対処する際は、次のベストプラクティスを念頭に置いてください。

停止中のダウンタイムを減らすには、インスタンスのマルチ AZ 配置を有効にします。
DB インスタンスのメンテナンス期間を調整します。RDS がシステム変更を適用する必要がある場合、DB インスタンスは、必要な変更を行うのに要する最小限の時間だけ使用できなくなります。インスタンスにマイナーバージョン自動アップグレードを行わせたくない場合は、このオプションを無効にします。
クエリを実行するのに十分なリソースをデータベースに割り当てます。Amazon RDS では、割り当てられるリソースの数はインスタンスタイプによって異なります。また、ストアドプロシージャなどの特定のクエリは、想定外に大量のメモリを消費する可能性があります。リソース不足のためにインスタンスが頻繁に再起動する場合は、アプリケーションの需要に合わせてデータベースインスタンスクラスをスケールアップしてください。
インスタンスのスロットリングを回避するには、RDS インスタンスの可用性とヘルスステータスを示す主要な Amazon RDS メトリクスに対して、Amazon CloudWatch アラームを設定します。例えば、使用可能なメモリが 95% に達したときに通知を受け取れるように、FreeableMemory メトリクスに CloudWatch アラームを設定できます。詳しくは、「拡張モニタリングの CloudWatch Logs をフィルタリングして、Amazon RDS のために自動化されたカスタムメトリクスを生成するにはどうすればよいですか?」を参照してください。
RDS インスタンスでフェイルオーバーが発生したときに Amazon RDS から通知を受けるには、Amazon RDS イベント通知をサブスクライブします。
データベースのパフォーマンスを最適化するには、クエリが PostgreSQL と MySQL 用に適切に調整されていることを確認してください。適切に調整されていない場合、パフォーマンスの問題が発生し、待ち時間が長くなる可能性があります。
CPU、メモリ、またはその他のリソース不足に関する負荷をトラブルシューティングするには、「Amazon RDS for PostgreSQL または Amazon Aurora PostgreSQL 互換インスタンスの CPU 使用率が高い場合のトラブルシューティング方法を教えてください」を参照してください。また、「Amazon RDS for MySQL または Amazon Aurora MySQL 互換 DB インスタンスの CPU 使用率が増加している場合のトラブルシューティングと解決方法を教えてください」も参照してください。