Amazon Aurora のトラブルシューティング - Amazon Aurora
DB インスタンスに接続できないセキュリティの問題DB インスタンス所有者のパスワードのリセットDB インスタンスの停止または再起動パラメータの変更が有効にならないAurora の解放可能なメモリの問題Aurora MySQL のレプリケーションの問題

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

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

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 Management Console にサインインし、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. [ルートの保存] を選択します。

      また、IPv6 エンドポイントに接続する場合は、クライアントの IPv6 アドレス範囲が DB インスタンスへの接続を認可されていることを確認してください。

    詳細については、「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 アカウント を使用してユーザーを作成し、DB ユーザーアカウントに割り当てることです。また、必要に応じて、マスターアカウントを使用して他のユーザーアカウントを作成することもできます。

ユーザーの作成の詳細については、「AWS アカウント での IAM ユーザーの作成」を参照してください。AWS IAM Identity Center でのユーザー作成の詳細については、「Manage identities in IAM Identity Center」(IAM Identity Center での ID の管理) を参照してください。

エラーメッセージ「アカウント属性の取得に失敗しました。コンソールの特定の機能が損なわれる可能性があります。」

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

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

DB クラスターからロックアウトされた場合は、マスターユーザーとしてログインできます。その後、他の管理ユーザーまたはロールの認証情報をリセットできます。マスターユーザーとしてログインできない場合は、AWS アカウントの所有者がマスターユーザーのパスワードをリセットできます。リセットする必要がある管理アカウントまたはロールの詳細については、「マスターユーザーアカウント権限」を参照してください。

DB インスタンスのパスワードは、Amazon RDS コンソール、AWS CLI コマンドの modify-db-instance、または ModifyDBInstance API オペレーションを使用して変更できます。DB クラスターの DB インスタンスの変更の詳細については、「DB クラスター内の DB インスタンスの変更」を参照してください。

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

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

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

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

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

  • DB インスタンスクラスを変更し、[すぐに適用] を [true] に設定する。

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

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

  • DB インスタンスクラスを変更し、[すぐに適用] を [false] に設定する。

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

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

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

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

Amazon Aurora の解放可能なメモリの問題

解放可能なメモリは、データベースエンジンで使用できる DB インスタンスの合計ランダムアクセスメモリ (RAM) です。これは、空きオペレーティングシステム (OS) メモリと使用可能なバッファとページキャッシュメモリの合計です。データベースエンジンは、ホスト上のほとんどのメモリを使用しますが、OS プロセスも一部の RAM を使用します。データベースエンジンに現在割り当てられているメモリや OS プロセスによって使用されているメモリは、空きメモリには含まれません。データベースエンジンのメモリが不足している場合、DB インスタンスは、バッファリングとキャッシュに通常使用される一時スペースを使用できます。前述のように、この一時スペースは空きメモリに含まれます。

Amazon CloudWatch の FreeableMemory メトリクスを使用して、空きメモリを監視します。詳細については、「Amazon Aurora ​のメトリクスのモニタリングの概要」を参照してください。

DB インスタンスの解放可能なメモリが常に不足またはスワップ領域を使用する場合、DB インスタンスクラスへのスケールアップを検討する必要があります。詳細については、「Aurora DB インスタンスクラス」を参照してください。

メモリ設定を変更することもできます。例えば、Aurora MySQL と指定すると、innodb_buffer_pool_sizeパラメータのサイズを調整することもできます。このパラメータはデフォルトで物理メモリの 75% に設定されています。MySQL のトラブルシューティングのヒントについては、「Amazon RDS for MySQL データベースの空きメモリ不足のトラブルシューティング方法を教えてください」を参照してください。

Aurora Serverless v2 の場合、FreeableMemory 値は、DB インスタンスを最大容量にスケーリングしたときに利用できる未使用のメモリ量を表します。インスタンスが比較的低い容量にスケールダウンしたかもしれませんが、インスタンスがスケールアップできるため、FreeableMemory に高い値が報告されます。そのメモリは現在利用できませんが、必要な場合は入手できます。

現在の容量が最大容量を下回る 各 Aurora 容量ユニット (ACU) では、FreeableMemory は約 2 GiB 増加します。したがって、DB インスタンスが限りなく大きくスケールアップされるまで、このメトリクスはゼロに近づきません。

このメトリクスが 0 値に近づいた場合、DB インスタンスは限界までスケールアップしたことになります。これにより、使用可能なメモリの限界に近づいています。クラスターの最大 ACU 設定を引き上げることを検討してください。このメトリクスがリーダー DB インスタンスで 0 値に近づいた場合、クラスターにリーダー DB インスタンスを追加することを検討してください。これにより、ワークロードの読み取り専用部分のワークロードをより多くの DB インスタンスに分散することで、各リーダー DB インスタンスのメモリ使用量を軽減できます。詳細については、「Aurora Serverless v2 の重要な Amazon CloudWatch メトリクス」を参照してください。

Aurora Serverless v1 の場合、容量範囲を変更して ACU を使用できます。詳細については、「Aurora Serverless v1 DB クラスターの変更」を参照してください。

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

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

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

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

AuroraBinlogReplicaLag メトリクスには、MySQL Seconds_Behind_Master コマンドの SHOW REPLICA STATUS フィールドの値が報告されます。詳細については、MySQL ドキュメントの「SHOW REPLICA STATUS ステートメント」を参照してください。

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

注記

Aurora MySQL の旧バージョンは SHOW REPLICA STATUS の代わりに SHOW SLAVE STATUS を使用していました。Aurora MySQL バージョン 1 または 2 を使用している場合は、SHOW SLAVE STATUS を使用してください。Aurora MySQL バージョン 3 以降は、SHOW REPLICA STATUS を使います。

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

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

リードレプリカと MySQL の詳細については、MySQL ドキュメントの「レプリケーション実装の詳細」を参照してください。

出典の 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 では、リードレプリカのレプリケーションステータスをモニタリングします。RDS では、何らかの理由でレプリケーションが停止した場合、リードレプリカのインスタンスの [Replication State] (レプリケーションステータス) フィールドを Error に更新します。MySQL または MariaDB エンジンによりスローされた関連するエラーの詳細は、[] フィールドを参照することで確認できます。リードレプリカのステータスを示すイベントが生成されます (RDS-EVENT-0045、RDS-EVENT-0046、RDS-EVENT-0057 など)。イベントについてとイベントへのサブスクライブの詳細については、「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 または MariaDB のストレージエンジンでのみサポートされています。

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

    alter table <schema>.<table_name> engine=innodb;

  • SYSDATE() など、安全でない非決定的クエリを使用している。詳細については、MySQL ドキュメントの「バイナリロギングでの安全および安全でないステートメントの判断」を参照してください。

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

  • 論理的なエラーが発生し、安全にエラーをスキップできる場合は、「現在のレプリケーションエラーのスキップ」のステップに従ってください。Aurora MySQL DB インスタンスは、mysql_rds_skip_repl_error プロシージャを含むバージョンを実行している必要があります。詳細については、「mysql_rds_skip_repl_error」を参照してください。

  • バイナリログ (binlog) の位置の問題が発生した場合は、レプリカの再生位置を変更できます。これを行うには、Aurora MySQL バージョン 1 および 2 の mysql.rds_next_master_log コマンドを使用します。これを行うには、Aurora MySQL バージョン 3 以降の mysql.rds_next_source_log コマンドを使用します。レプリカの再生位置を変更するには、Aurora MySQL DB インスタンスがこのコマンドをサポートしているバージョンで実行されている必要があります。バージョン情報については、「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 コマンドを呼び出すと、レプリケーションがダウンまたは無効であることを示すエラーメッセージが表示されることがあります。

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

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

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

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

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