DB インスタンスに接続できないセキュリティの問題 DB インスタンス所有者のロールパスワードのリセット DB インスタンスの停止または再起動パラメーターの変更が有効にならない Aurora MySQL メモリ不足の問題 Aurora MySQL レプリケーションの問題デバイスに空き容量がない

Aurora のトラブルシューティング

以下のシナリオを使用して、Amazon RDS や Aurora の DB インスタンスで発生する問題をトラブルシューティングします。

トピック

Amazon RDS の DB インスタンスに接続できない
Amazon RDS のセキュリティに関する問題
DB インスタンス所有者のロールパスワードのリセット
Amazon RDS DB インスタンスの停止または再起動
Amazon RDS DB パラメータの変更が有効にならない
Amazon Aurora MySQL メモリ不足の問題
Amazon Aurora MySQL レプリケーションの問題
デバイスに空き容量がない

Amazon RDS API を使用した問題のデバッグについては、「Aurora のアプリケーションのトラブルシューティング」を参照してください。

Amazon RDS の DB インスタンスに接続できない

DB インスタンスに接続できない場合、一般的な原因として次のようなものがあります。

インバウンドルール – ローカルのファイアウォールによって適用されているアクセスルールと DB インスタンスへのアクセスが許可された IP アドレスが一致していない可能性があります。問題の原因として最も多いのは、セキュリティグループのインバウンドルールです。

デフォルトでは、DB インスタンスへのアクセスは許可されていません。アクセスは、DB インスタンスとの間のトラフィックを許可する VPC に関連付けられたセキュリティグループによって許可されます。必要に応じて、特定の状況のインバウンドルールとアウトバウンドルールをセキュリティグループに追加します。IP アドレス、IP アドレスの範囲、または別の VPC セキュリティグループを指定できます。

注記

新しいインバウンドルールを追加するときに [ソース] に [マイ IP] を選択すると、ブラウザで検出された IP アドレスから DB インスタンスへのアクセスを許可できます。

セキュリティグループの設定の詳細については、「セキュリティグループを作成して、VPC 内の DB クラスターへのアクセスを提供します。」を参照してください。

注記

169.254.0.0/16 の範囲内の IP アドレスからのクライアント接続は許可されていません。これは、ローカルリンクのアドレス指定に使用される Automatic Private IP Addressing Range (APIPA) です。
パブリックアクセス – クライアントアプリケーションを使用するなど、VPC の外部から DB インスタンスに接続するには、インスタンスにパブリック IP アドレスが割り当てられている必要があります。

インスタンへのパブリックアクセスを許可するには、インスタンスを変更し、[Public accessibility (パブリックアクセス)] で [Yes (はい)] を選択します。詳細については、「VPC の DB インスタンスをインターネットから隠す」を参照してください。
ポート – DB インスタンスの作成時に指定したポートが、ローカルのファイアウォールの制限によって通信の送受信に使用できない場合があります。指定したポートをインバウンドおよびアウトバウンドの通信に使用することがネットワークで許可されているかどうかを判断するには、ネットワーク管理者に確認します。
可用性 – 新しく作成された DB インスタンスでは、DB インスタンスが使用できるようになるまで、DB インスタンスのステータスは creating になります。ステータスが available になると、DB インスタンスに接続できます。DB インスタンスのサイズによっては、インスタンスが利用可能になるまでに最大 20 分かかることがあります。
内部ゲートウェイ – DB インスタンスをパブリックにアクセス可能にするには、その DB サブネットグループのサブネットにインターネットゲートウェイが必要です。
サブネットのインターネットゲートウェイを設定するには
1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。
2. ナビゲーションペインで、[データベース] を選択し、DB インスタンスの名前を選択します。
3. [接続とセキュリティ] タブで、[VPC] の下の VPC ID と [サブネット] の下のサブネット ID の値を書き留めます。
4. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。
5. ナビゲーションペインで、[Internet Gateways] を選択します。ご使用の VPC にアタッチされているインターネットゲートウェイがあることを確認します。それ外の場合は、[Create Internet Gateway] を選択してインターネットゲートウェイを作成します。インターネットゲートウェイを選択し、[VPC にアタッチ] を選択して指示どおりにインターネットゲートウェイを VPC にアタッチします。
6. ナビゲーションペインで [Subnets] を選択し、サブネットを選択します。
7. [Route Table] タブで、送信先として 0.0.0.0/0、ターゲットとして VPC のインターネットゲートウェイが指定されたルートがあることを確認します。IPv6 アドレスを使用してインスタンスに接続する場合は、インターネットゲートウェイを指しているすべての IPv6 トラフィック (::/0) 用のルートがあることを確認します。それ以外の場合は、以下の作業を行います。
  1. ルートテーブルの ID (rtb-xxxxxxxx) を選択して、ルートテーブルに移動します。
  2. [Routes] タブで、[Edit routes] を選択します。[Add route] を選択して、0.0.0.0/0 を宛先として追加し、インターネットゲートウェイをターゲットとして使用します。IPv6 の場合は、[Add route] を選択して、::/0 を宛先として追加し、インターネットゲートウェイをターゲットとして使用します。
  3. [Save routes] を選択します。
詳細については、「VPC の DB インスタンスの使用」を参照してください。

DB インスタンスへの接続のテスト

一般的な Linux または Microsoft Windows のツールを使用して DB インスタンスへの接続をテストできます。

Linux または UNIX のターミナルからは、次のように入力することで接続をテストできます (DB-instance-endpoint と port を DB インスタンスのエンドポイントとポートに置き換えてください)。


nc -zv DB-instance-endpoint port

コマンドと戻り値の例を以下に示します。


nc -zv postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299

  Connection to postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded!

Windows ユーザーは、Telnet を使用して DB インスタンスへの接続をテストできます。Telnet での操作は、接続のテスト以外はサポートされていないことに注意してください。接続に成功した場合、このアクションはメッセージを返しません。接続に失敗した場合は、次のようなエラーメッセージが返されます。


C:\>telnet sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com 819

  Connecting To sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com...Could not open
  connection to the host, on port 819: Connect failed

Telnet アクションが成功を示している場合、セキュリティグループは適切に設定されています。

注記

Amazon RDS は ping などの ICMP (Internet Control Message Protocol) トラフィックを受け付けません。

接続認証のトラブルシューティング

DB インスタンスに接続できるが、認証のエラーが発生する場合は、DB インスタンスのマスターユーザーパスワードのリセットが必要になることがあります。これを行うには、RDS インスタンスを変更します。

Amazon RDS のセキュリティに関する問題

セキュリティ問題を回避するために、マスター AWS ユーザー名とパスワードをユーザーアカウントに使用しないでください。ベストプラクティスは、マスターの AWS アカウントを使用して AWS Identity and Access Management (IAM) ユーザーを作成し、DB ユーザーアカウントに割り当てることです。また、必要に応じて、マスターアカウントを使用して他のユーザーアカウントを作成することもできます。

IAM ユーザーの作成の詳細については、「IAM ユーザーを作成する」を参照してください。

エラーメッセージ「Failed to retrieve account attributes, certain console functions may be impaired.」

このエラーが発生する原因はいくつかあります。アカウントにアクセス許可がないか、アカウントが正しく設定されていない可能性があります。新規のアカウントの場合は、アカウントの準備がまだ整っていない可能性があります。既存のアカウントの場合は、DB インスタンスの作成などの特定の操作を実行するためのアクセスポリシーでアクセス許可が設定されてない可能性があります。問題を修正するには、IAM 管理者がアカウントに必要なロールを指定する必要があります。詳細については、IAM ドキュメントを参照してください。

DB インスタンス所有者のロールパスワードのリセット

マスターパスワードをリセットすることで、その DB インスタンスに割り当てられた権限をリセットできます。

たとえば、SQL サーバーデータベースの db_owner ロールのメンバーでない場合は、DB インスタンスのマスターパスワードを変更することで、db_owner ロールのパスワードをリセットできます。DB インスタンスのパスワードを変更すると、DB インスタンスへのアクセス権を再取得することができます。また、DB インスタンスのパスワードを変更すると、変更した db_owner のパスワードを使用してデータベースにアクセスし、誤って取り消された db_owner ロールの権限を元に戻すこともできます。DB インスタンスのパスワードは、Amazon RDS コンソール、AWS CLI コマンドの modify-db-instance、または ModifyDBInstance API オペレーションを使用して変更できます。

Amazon RDS DB インスタンスの停止または再起動

DB インスタンスの停止は、DB インスタンスが再起動されたときに発生する可能性があります。また、DB インスタンスがアクセスできない状態になったときやデータベースが再開されたときに発生する可能性があります。再起動は、手動で DB インスタンスを再起動したとき、または設定を有効にするために再起動が必要な DB インスタンスの設定を変更したときに発生します。

DB インスタンスの再起動は、再起動が必要な設定を変更したとき、または手動で再起動を実行したときにのみ行われます。設定を変更し、変更を直ちに有効にすることをリクエストした場合、直ちに再起動を実行できます。または、DB インスタンスのメンテナンス時間中に再起動を実行することもできます。

以下のいずれかが発生したとき、DB インスタンスの再起動は直ちに実行されます。

DB インスタンスのバックアップ保持期間を 0 から 0 以外の値または 0 以外の値から 0 に変更し、[すぐに適用] を [true] に設定する。
DB インスタンスクラスを変更し、[すぐに適用] を [true] に設定する。

以下のいずれかが発生したとき、DB インスタンスの再起動はメンテナンス時間中に実行されます。

DB インスタンスのバックアップ保持期間を 0 から 0 以外の値または 0 以外の値から 0 に変更し、[すぐに適用] を [false] に設定する。
DB インスタンスクラスを変更し、[すぐに適用] を [false] に設定する。

DB パラメータグループの静的パラメータを変更する場合、その変更はパラメータグループに関連付けられている DB インスタンスを再起動するまで有効になりません。この変更には、手動での再起動が必要です。DB インスタンスは、メンテナンスウィンドウ中に自動では再起動されません。

Amazon RDS DB パラメータの変更が有効にならない

場合によっては、DB パラメータグループのパラメータを変更しても、その変更が有効にならないことがあります。その場合は、DB パラメータグループに関連付けられている DB インスタンスの再起動が必要な可能性があります。動的パラメータを変更する場合は、その変更はすぐに有効になります。静的パラメータを変更する場合は、その変更はパラメータグループに関連付けられている DB インスタンスを再起動するまで有効になりません。

RDS コンソールを使用するか、明示的に RebootDBInstance API オペレーションを呼び出すことによって、DB インスタンスを再起動できます (DB インスタンスが Multi-AZ deployment の場合、フェイルオーバーなしで実行してください)。静的パラメータの変更後に関連付けられている DB インスタンスの再起動を求める要件は、パラメータの誤った設定が API コールに影響を及ぼすリスクを低減するために役立ちます。これには、ModifyDBInstance を呼び出して DB インスタンスクラスを変更する場合などがあります。詳細については、「DB パラメータグループのパラメータの変更」を参照してください。

Amazon Aurora MySQL メモリ不足の問題

Aurora MySQL aurora_oom_response インスタンスレベルパラメータは、DB インスタンスによって、システムメモリをモニタリングしてさまざまなステートメントおよび接続で消費されるメモリを推測できるようにします。システムでメモリが不足すると、システムはメモリ不足 (OOM) およびデータベースの再起動を避ける目的でそのメモリを解放するアクションのリストを実行できます。このインスタンスレベルのパラメータには、メモリが少ないときに DB インスタンスによって実行されるべきアクションの、カンマ区切りの文字列を指定します。有効なアクションには、print、tune、decline、kill_query、またはこれらの任意の組み合わせが含まれます。空の文字列はアクションが実行されないことを意味し、実質的にこの機能は無効になります。

以下は、aurora_oom_response パラメータの使用例です。

print – 大量のメモリを使用するクエリのみを出力します。
tune – 内部テーブルキャッシュを調整して、メモリをシステムに戻します。
decline – インスタンスがメモリ不足になったら、新しいクエリを拒否します。
kill_query – インスタンスメモリが低いしきい値を超えるまで、メモリ消費の降順でクエリを強制終了します。データ定義言語 (DDL) ステートメントは強制終了されません。
print, tune – print と tune の両方について記述されたアクションを実行します。
tune, decline, kill_query – tune、decline、および kill_query について記述されたアクションを実行します。

db.t2.small DB インスタンスクラスでは、aurora_oom_response パラメータはデフォルトで print, tune に設定されます。他のすべての DB インスタンスクラスでは、パラメータ値はデフォルトで空になります (無効)。

Amazon Aurora MySQL レプリケーションの問題

MySQL のレプリケーションの問題のいくつかは、Aurora MySQL にも該当します。これらの問題を診断して修正できます。

トピック

リードレプリカ間の遅延の診断と解決
MySQL のリードレプリケーションのエラーの診断と解決
スレーブのダウンまたは無効エラー

リードレプリカ間の遅延の診断と解決

MySQL のリードレプリカを作成してそのリードレプリカが使用可能になると、Amazon RDS はリードレプリカの作成オペレーションが開始された時点以降にソースの DB インスタンスに対して行われた変更を最初にレプリケートします。このフェーズでは、リードレプリカのレプリケーション遅延時間が 0 より大きくなります。これは、Amazon CloudWatch で Amazon RDS の AuroraBinlogReplicaLag メトリクスを参照することによってモニタリングできます。

AuroraBinlogReplicaLag メトリクスでは、MySQL の SHOW SLAVE STATUS コマンドの Seconds_Behind_Master フィールドの値がレポートされます。詳細については、「SHOW SLAVE STATUS」を参照してください。 AuroraBinlogReplicaLag メトリックが 0 に達すると、レプリカがソース DB インスタンスに追いついています。 AuroraBinlogReplicaLag メトリクスが -1 を返す場合、レプリケーションがアクティブではない可能性があります。レプリケーションのエラーをトラブルシューティングする場合は、「MySQL のリードレプリケーションのエラーの診断と解決」を参照してください。 AuroraBinlogReplicaLag の値が -1 である場合は、Seconds_Behind_Master の値が特定できないか NULL であることも示しています。

AuroraBinlogReplicaLag メトリクスは、ネットワークが停止しているとき、またはメンテナンス時間にパッチを適用しているときには、-1 を返します。この場合、ネットワーク接続が復元されるか、メンテナンス時間が終了するまで待ってから、 AuroraBinlogReplicaLag メトリクスを再度確認します。

MySQL のリードレプリケーションテクノロジーは非同期です。そのため、ソースの DB インスタンスの BinLogDiskUsage メトリクスやリードレプリカの AuroraBinlogReplicaLag メトリクスが増加する場合があります。たとえば、ソースの DB インスタンスへの大量の書き込みオペレーションが並列で実行される場合を例にします。このとき、リードレプリカへの書き込みオペレーションは単一の I/O スレッドでシリアルで行われます。このような場合、ソースのインスタンスとリードレプリカの間に遅延が発生する可能性があります。

リードレプリカと MySQL の詳細については、MySQL のドキュメントの Replication Implementation Details を参照してください。

ソースの DB インスタンスに対する更新とそれに続くリードレプリカに対する更新の間の遅延を低減するには、次のような方法があります。

リードレプリカの DB インスタンスクラスがソースの DB インスタンスと同程度のストレージサイズを持つように設定します。
ソースの DB インスタンスとリードレプリカによって使用される DB パラメータグループのパラメータ設定の互換性を保ちます。詳細と例については、次のセクションにある max_allowed_packet パラメータの説明を参照してください。
クエリのキャッシュを無効にします。頻繁に変更されるテーブルでは、クエリのキャッシュを使用すると、キャッシュが頻繁にロックされ、更新されるため、レプリカの遅延が増加する可能性があります。このような場合、クエリのキャッシュを無効にすると、レプリカの遅延が小さくなることがあります。DB インスタンスの DB パラメータグループで query_cache_type parameter を 0 に設定することによって、クエリのキャッシュを無効にできます。クエリのキャッシュの詳細については、「クエリのキャッシュの設定」を参照してください。
InnoDB for MySQLでは、リードレプリカのバッファプールをウォームアップします。たとえば、頻繁に更新される一連の小さなテーブルがあり、InnoDB または XtraDB のテーブルスキーマを使用しているとします。その場合、それらのテーブルをリードレプリカにダンプします。そうすることで、データベースエンジンはそれらのテーブルの行をディスクからスキャンしてバッファープールにキャッシュします。これにより、レプリカの遅延を低減することができます。例を以下に示します。

Linux、macOS、Unix の場合:
```
PROMPT> mysqldump \
    -h <endpoint> \
    --port=<port> \
    -u=<username> \
    -p <password> \
    database_name table1 table2 > /dev/null 
```
Windows の場合:
```
PROMPT> mysqldump ^
    -h <endpoint> ^
    --port=<port> ^
    -u=<username> ^
    -p <password> ^
    database_name table1 table2 > /dev/null 
```

MySQL のリードレプリケーションのエラーの診断と解決

Amazon RDS は、リードレプリカのレプリケーション状態を監視し、何らかの理由でレプリケーションが停止した場合は、リードレプリカインスタンスの [レプリケーションの状態] フィールドを [Error] に更新します。MySQL または MariaDB エンジンによりスローされた関連するエラーの詳細は、[] フィールドを参照することで確認できます。リードレプリカのステータスを示すイベントが生成されます（RDS-EVENT-0045、RDS-EVENT-0046、RDS-EVENT-0047 など）。イベントについてとイベントへのサブスクライブの詳細については、「Amazon RDS イベント通知の使用」を参照してください。MySQL のエラーメッセージが返された場合は、MySQL のエラーメッセージのドキュメントでエラーを確認してください。

レプリケーションエラーを引き起こす可能性がある一般的な状況は次のとおりです。

リードレプリカの max_allowed_packet パラメータの値がソースの DB インスタンスの max_allowed_packet パラメータの値より小さい。

max_allowed_packet パラメータは、DB パラメータグループで設定できるカスタムパラメータです。max_allowed_packet パラメータは、データベースで実行できるデータ操作言語 (DML) の最大サイズを指定するために使用されます。ソースの DB インスタンスの max_allowed_packet の値がリードレプリカの max_allowed_packet の値より小さい場合、レプリケーションプロセスはエラーをスローしてレプリケーションを停止することがあります。最も一般的なエラーは「packet bigger than 'max_allowed_packet' bytes」です。ソースとリードレプリカで同じ max_allowed_packet パラメータ値を持つ DB パラメータグループが使用されるように設定することにより、エラーを修正できます。
リードレプリカのテーブルに書き込んでいる。リードレプリカでインデックスを作成する場合、read_only パラメータを 0 に設定してインデックスを作成する必要があります。リードレプリカのテーブルに書き込んだ場合、レプリケーションが中断する可能性があります。
MyISAM などの非トランザクションストレージエンジンを使用している。リードレプリカにはトランザクションストレージエンジンが必要です。レプリケーションがサポートされるストレージエンジンは、InnoDB for MySQL、InnoDB for MariaDB 10.2 以上、または XtraDB for MariaDB 10.1 以下のみです。

次のコマンドで MyISAM テーブルを InnoDB に変換できます。

alter table <schema>.<table_name> engine=innodb;
SYSDATE() など、安全でない非決定的クエリを使用している。詳細については、MySQL のドキュメントの Determination of Safe and Unsafe Statements in Binary Logging を参照してください。

以下の手順は、レプリケーションエラーを解決するのに役立ちます。

論理エラーが発生し、安全にエラーをスキップできる場合は、「現在のレプリケーションエラーのスキップ」の手順に従ってください。Aurora MySQL DB インスタンスは、mysql_rds_skip_repl_error プロシージャを含むバージョンを実行している必要があります。詳細については、「mysql_rds_skip_repl_error」を参照してください。
バイナリログ (binlog) の位置の問題が発生した場合は、mysql_rds_next_master_log コマンドを使用してレプリカの再生位置を変更できます。レプリカの再生位置を変更するには、Aurora MySQL DB インスタンスが mysql_rds_next_master_log コマンドをサポートしているバージョンを実行している必要があります。バージョン情報については、「mysql_rds_next_master_log」を参照してください。
DML の高負荷によって一時的なパフォーマンスの問題が発生した場合は、リードレプリカの DB パラメータグループで innodb_flush_log_at_trx_commit パラメータを 2 に設定できます。これを行うことによって、一時的に ACID 特性 (不可分性、整合性、分離性、耐久性) が低下しますが、リードレプリカの遅延を解消するのに役立ちます。
リードレプリカを削除し、同じ DB インスタンス識別子を使用してインスタンスを作成することで、エンドポイントを前のリードレプリカと同じままにすることができます。

レプリケーションエラーが解決すると、[Replication State] は [replicating] に変化します。詳細については、「MySQL リードレプリカに関する問題のトラブルシューティング」を参照してください。

スレーブのダウンまたは無効エラー

mysql.rds_skip_repl_error コマンドを呼び出した際に、次のエラーメッセージが表示されることがあります: Slave is down or disabled.

このエラーメッセージは、レプリケーションが停止して再開できないために表示されます。

多数のエラーをスキップする必要がある場合は、レプリケーションの遅延により、バイナリログファイルがデフォルトの保持期間を超えて増大する場合があります。この場合、バイナリログファイルがレプリカで再生される前に破棄され、致命的なエラーが発生することがあります。この破棄によりレプリケーションが停止し、mysql.rds_skip_repl_error コマンドを呼び出してレプリケーションエラーをスキップすることができなくなります。

この問題は、レプリケーションマスターでバイナリログファイルの保持時間を増加させることで軽減できます。バイナリログ保持時間を長くすると、レプリケーションを再開し、必要に応じて mysql.rds_skip_repl_error コマンドを使用できるようになります。

バイナリログの保持期間を設定するには、mysql_rds_set_configuration プロシージャを使用します。設定パラメータの「binlog retention hours」と DB クラスターでバイナリログファイルを保持する時間数を最大 720 時間 (30 日) で指定します。以下の例では、バイナリログファイルの保持期間を 48 時間に設定しています。


CALL mysql.rds_set_configuration('binlog retention hours', 48);

デバイスに空き容量がない

次のいずれかのエラーメッセージが表示される場合があります。

Amazon Aurora MySQL:


ERROR 3 (HY000): Error writing file '/rdsdbdata/tmp/XXXXXXXX' (Errcode: 28 - No space left on device)

Amazon Aurora PostgreSQL:


ERROR: could not write block XXXXXXXX of temporary file: No space left on device.

Amazon Aurora の DB クラスターの各 DB インスタンスは、セッションの一時テーブルを保存するためにローカルのソリッドステートドライブ (SSD) ストレージを使用します。一時テーブル用のこのローカルストレージは、Aurora クラスターのボリュームのように自動的に拡張されることはなく、容量が制限されています。この制限は、お使いの DB クラスターにおける DB インスタンスの、DB インスタンスクラスによって異なります。

一時テーブルとログに使用できるストレージの容量を表示するには、CloudWatch の FreeLocalStorage メトリクスを使用します。このメトリクスは、インスタンスごとの一時ボリュームを示すものであり、クラスターのボリュームを示すものではありません。使用可能なメトリクスの詳細については、「Amazon Aurora DB クラスターメトリクスのモニタリング」を参照してください。

場合によっては、一時ストレージに必要な容量を減らすためにワークロードを変更できないことがあります。その場合は、より多くの SSD ストレージを持つ DB インスタンスクラスを使用するように DB インスタンスを変更します。詳細については、「DB インスタンスクラス」を参照してください。

トラブルシューティングの詳細については、「Aurora for MySQL のローカルストレージには何が格納されていますか? ローカルストレージの問題はどのようにトラブルシューティングすればよいですか?」または「Amazon Aurora for PostgreSQL ストレージに、何が保存されていますか? また、ストレージの問題をトラブルシューティングする方法を教えてください」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

クォータと制約

Amazon RDS API リファレンス