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

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

トピック

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

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

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

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

ローカルファイアウォールによって実施されるアクセスルールと、インスタンスのセキュリティグループで DB インスタンスへのアクセスを許可した Ingress IP アドレスが同期していません。問題の原因はほとんどの場合、セキュリティグループの Ingress ルールです。

デフォルトでは、DB インスタンスはアクセスを許可していません。アクセスはセキュリティグループを介して許可されます。アクセスを許可するには、状況に合わせて特定の Ingress ルールと Egress ルールを設定した独自のセキュリティグループを作成する必要があります。必要に応じて、DB インスタンスに対するソース関連の送受信トラフィックを許可するルールを、VPC に関連付けられたセキュリティグループに追加します。IP アドレス、IP アドレスの範囲、または別の VPC セキュリティグループを指定できます。

セキュリティグループのセットアップの詳細については、「セキュリティグループを作成して、VPC 内の DB クラスターへのアクセスを提供します。」を参照してください。
DB インスタンスの作成時に指定したポートが、ローカルファイアウォールの制限によって、通信の送受信に使用できません。この場合、指定したポートをインバウンドおよびアウトバウンド通信に使用することがネットワークで許可されているかどうかを判断するには、ネットワーク管理者に確認します。
DB インスタンスは、まだ作成中であり、利用できません。DB インスタンスのサイズによっては、インスタンスが利用可能になるまでに最大 20 分かかることがあります。

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

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

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


nc -zv <DB-instance-endpoint> <port>

たとえば、サンプルのコマンドと戻り値は次のようになります。


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

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

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


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

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

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

注記

Amazon RDS では ping も含めて Internet Control Message Protocol (ICMP) トラフィックを受け入れません。

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

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

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

セキュリティ問題を回避するために、マスター AWS ユーザー名とパスワードをユーザーアカウントに使用しないでください。ベストプラクティスは、マスター AWS アカウントを使用して 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_owner のパスワードを使用してデータベースにアクセスしたり、誤って失効になった可能性のある db_owner ロールに対する権限を復元したりできます。Amazon RDS コンソール、AWS CLI コマンド modify-db-instance、または ModifyDBInstance オペレーションを使用して、DB インスタンスのパスワードを変更できます。

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

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

DB インスタンスの設定を変更したときは、[Apply Immediately] 設定を使用して、いつ変更が適用されたかを確認できます。

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

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

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

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

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

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

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

DB パラメータグループのパラメータを変更したが、変更が有効にならない場合、通常、DB パラメータグループに関連付けられている DB インスタンスを再起動する必要があります。動的なパラメータを変更した場合、変更は直ちに有効になります。静的パラメータを変更した場合、パラメータグループに関連付けられている DB インスタンスを再起動するまで、変更は有効になりません。

RDS コンソールを使用するか、明示的に RebootDbInstance API オペレーションを呼び出すことによって、DB インスタンスを再起動できます (DB インスタンスがMulti-AZ deployment の場合、フェイルオーバーなしで実行してください)。静的パラメータを変更した後、関連付けられた DB インスタンスの再起動を求める要件は、パラメータの誤った設定が API コールに影響するリスク (DB インスタンスクラスを変更する ModifyDBInstance の呼び出しなど) の軽減に役立ちます。詳細については、「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 DB インスタンスクラスでは、aurora_oom_response パラメータはデフォルトで print, tune に設定されます。他のすべての DB インスタンスクラスでは、パラメータ値はデフォルトで空になります (無効)。

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

MySQL および MariaDB のレプリケーションの問題には、Aurora MySQL にも当てはまるものがあります。これらの問題を診断して修正できます。

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

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

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

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

MySQL および MariaDB リードレプリケーションテクノロジーは非同期であるため、ソース DB インスタンスの BinLogDiskUsage メトリクスとリードレプリカの AuroraBinlogReplicaLag メトリクスが時折増加することが予期されます。たとえば、ソース DB インスタンスには大量の書き込みオペレーションが並行して行われますが、リードレプリカへの書き込みオペレーションは単一の I/O スレッドを使用してシリアル化されます。このため、ソースインスタンスとリードレプリカの間に遅延が生じる可能性があります。リードレプリカと MySQL の詳細については、MySQL ドキュメントの『レプリケーション実装ガイド』を参照してください。読み取り専用のレプリカの詳細については、MariaDB ドキュメントの「レプリケーションの概要」を参照してください。

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

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

Linux、OS X、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 または MariaDB のリードレプリケーションのエラーの診断と解決

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

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

リードレプリカの max_allowed_packet パラメータの値が、ソース DB インスタンス max_allowed_packet のパラメータ未満である。

max_allowed_packet パラメータは、データベースで実行できるデータ操作言語 (DML) の最大サイズを指定するために使用される、DB パラメータグループで設定可能なカスタムパラメータです。ソース 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 または MariaDB DB インスタンスは、mysql_rds_skip_repl_error プロシージャを含むバージョンを実行している必要があります。詳細については、「mysql_rds_skip_repl_error」を参照してください。
binlog の位置の問題が発生した場合は、mysql_rds_next_master_log コマンドを使用してスレーブの再生位置を変更できます。スレーブの再生位置を変更するには、MySQL または MariaDB 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 または MariaDB リードレプリカに関する問題のトラブルシューティング」を参照してください。

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

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

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

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

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

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


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

No Space Left on Device (デバイスに空き容量がない) エラー

Amazon Aurora から次のエラーメッセージが返される場合があります。


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

Amazon Aurora DB クラスターの各 DB インスタンスは、セッションの一時テーブルを保存するのにローカル SSD ストレージを使用します。一時テーブル用のこのローカルストレージは、Aurora クラスターボリュームのように自動的に拡張されることはなく、容量が制限されています。この制限は、お使いの DB クラスターにおける DB インスタンスの、DB インスタンスクラスによって異なります。メモリ最適化インスタンスタイプのローカル SSD ストレージの量を調べるには、「Amazon EC2 のインスタンスタイプ」を参照してください。

ワークロードを変更することで、必要な一時ストレージの容量を減らすことができない場合には、DB インスタンスを拡張して、より多くのローカル SSD ストレージを保有する DB インスタンスクラスを使用することができます。

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

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

ドキュメントの表記規則

« 前次 »