Amazon RDS のトラブルシューティング - Amazon Relational Database Service

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

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

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

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-endpointport を 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 インスタンスを変更します。

DB インスタンスの変更の詳細については、「Amazon RDS DB インスタンスを変更する」を参照してください。

Amazon RDS のセキュリティの問題

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ストレージのタイプを [Magnetic (Standard) (マグネティック (標準))] から [General Purpose (SSD) (汎用 (SSD))] または [Provisioned IOPS (SSD) (プロビジョンド IOPS (SSD))] に変更する。あるいは、[Provisioned IOPS (SSD) (プロビジョンド IOPS (SSD))] または [General Purpose (SSD) (汎用 (SSD))] から [Magnetic (Standard) (マグネティック (標準))] に変更する。

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

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

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

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

DB インスタンスのアクションと [Apply Immediately] の値を設定することによる効果を示す表については、「Amazon RDS DB インスタンスを変更する」を参照してください。

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

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

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

Amazon RDS DB インスタンスのストレージ不足

DB インスタンスのストレージ領域が不足すると、DB インスタンスを利用できなくなる可能性があります。CloudWatch で提供される FreeStorageSpace メトリクスを常にモニタリングして、DB インスタンスのストレージに十分な空き容量があることを確認することを強くお勧めします。

データベースインスタンスのストレージが不足すると、ステータスが storage-full になります。たとえば、ストレージを使い果たした DB インスタンスに対して DescribeDBInstances API オペレーションを呼び出すと、次のように出力されます。

aws rds describe-db-instances --db-instance-identifier mydbinstance DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

この状態から回復するには、ModifyDBInstance API オペレーションまたは次の AWS CLI コマンドを使用してインスタンスにストレージ容量を追加します。

Linux、macOS、Unix の場合:

aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --allocated-storage 60 \ --apply-immediately

Windows の場合:

aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --allocated-storage 60 ^ --apply-immediately
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

ここで DB インスタンスの情報を取得すると、DB インスタンスが modifying ステータスであり、ストレージのスケーリングが行われていることが示されます。

aws rds describe-db-instances --db-instance-identifier mydbinstance
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa modifying mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

ストレージのスケーリングが完了すると、DB インスタンスのステータスは available になります。

aws rds describe-db-instances --db-instance-identifier mydbinstance
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 60 sa available mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

DescribeEvents オペレーションを使用すると、ストレージ容量を使い果たしたときに通知を受信できます。たとえば、上記のオペレーションの後に DescribeEvents の呼び出しを実行すると、次のような出力が表示されます。

aws rds describe-events --source-type db-instance --source-identifier mydbinstance
2009-12-22T23:44:14.374Z mydbinstance Allocated storage has been exhausted db-instance 2009-12-23T00:14:02.737Z mydbinstance Applying modification to allocated storage db-instance 2009-12-23T00:31:54.764Z mydbinstance Finished applying modification to allocated storage

Amazon RDS DB インスタンス容量の不足

InsufficientDBInstanceCapacity エラーは、DB インスタンスを作成または変更するときや DB スナップショットから DB インスタンスを復元するときに返されます。このエラーが返る場合、一般的な原因は次のとおりです。

  • リクエストされたアベイラビリティーゾーンで特定の DB インスタンスクラスを利用できない場合。次のいずれかの方法で、問題を解決できます。

    • 別の DB インスタンスクラスでリクエストを再試行してください。

    • 別のアベイラビリティーゾーンでリクエストを再試行します。

    • 明示的なアベイラビリティーゾーンを指定せずにリクエストを再試行してください。

    Amazon EC2 インスタンスの容量問題のトラブルシューティングについては、Amazon Elastic Compute Cloud ユーザーガイドの「インスタンス容量の不足」を参照してください。

  • DB インスタンスが EC2-Classic プラットフォームにあって、VPC にはない場合。一部の DB インスタンスクラスでは VPC が必要です。たとえば、EC2-Classic プラットフォームを使用していて、VPC が必要な DB インスタンスクラスに切り替えて容量を増やそうとすると、このエラーが発生します。VPC でのみ使用可能な Amazon EC2 インスタンスタイプについては、Amazon Elastic Compute Cloud ユーザーガイドの「EC2-Classic で利用可能なインスタンスタイプ」を参照してください。問題を解決するために、VPC 内に DB インスタンスを移動できます。詳細については、「VPC 外の DB インスタンスを VPC 内に移行する」を参照してください。

DB インスタンスの変更については、「Amazon RDS DB インスタンスを変更する」を参照してください。

Amazon RDS MySQL および MariaDB の問題

MySQL および MariaDB DB インスタンスに関する問題を診断して修正できます。

MySQL および MariaDB の最大接続数

RDS の MySQL または MariaDB DB インスタンスへの許可されている接続の最大数は、その DB インスタンスクラスで使用できるメモリ量に基づきます。使用できるメモリ量が多い DB インスタンスは、使用できる接続数が多くなります。DB インスタンスクラスの詳細については、「DB インスタンスクラス」を参照してください。

DB インスタンスへの接続の制限は、デフォルトで DB インスタンスクラスの最大値に設定されます。同時接続数は、許可されている最大接続数を上限とする任意の値に制限できます。この制限には、DB インスタンスのパラメータグループの max_connections パラメータを使用します。詳細については、「データベース接続の最大数」および「DB パラメータグループを使用する」を参照してください。

次のクエリを実行すると、MySQL または MariaDB DB インスタンスに許可されている最大接続数を取得できます。

SELECT @@max_connections;

次のクエリを実行すると、MySQL または MariaDB DB インスタンスへのアクティブな接続数を取得できます。

SHOW STATUS WHERE `variable_name` = 'Threads_connected';

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

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

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

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

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

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

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

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

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

  • リードレプリカの 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 または 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 リードレプリカに関する問題のトラブルシューティング」を参照してください。

バイナリログが有効な場合に SUPER 権限が必要になるトリガーの作成

RDS の MySQL または MriaDB DB インスタンスにトリガーを作成しようとすると、次のエラーが表示される場合があります。

"You do not have the SUPER privilege and binary logging is enabled"

バイナリログが有効なときにトリガーを使用するには、RDS MySQL および MriaDB DB インスタンスに制限されている SUPER 権限が必要です。バイナリログが有効なときに SUPER 権限なしでトリガーを作成するには、log_bin_trust_function_creators パラメータを true に設定します。log_bin_trust_function_creators を true に設定するには、新しい DB パラメータグループを作成するか、既存の DB パラメータグループを変更します。

バイナリログが有効なときに RDS MySQL または MriaDB DB インスタンスにトリガーを作成可能にする新しい DB パラメータグループを作成するには、次の CLI コマンドを使用します。既存のパラメータグループを変更するには、ステップ 2 から開始してください。

CLI を使用して新しいパラメータグループを作成し、バイナリログが有効なトリガーを許可するには

  1. 新しいパラメータグループを作成します。

    Linux、macOS、Unix の場合:

    aws rds create-db-parameter-group \ --db-parameter-group-name allow-triggers \ --db-parameter-group-family mysql8.0 \ --description "parameter group allowing triggers"

    Windows の場合:

    aws rds create-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --db-parameter-group-family mysql8.0 ^ --description "parameter group allowing triggers"
  2. トリガーを許可するように DB パラメータグループを変更します。

    Linux、macOS、Unix の場合:

    aws rds modify-db-parameter-group \ --db-parameter-group-name allow-triggers \ --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

    Windows の場合:

    aws rds modify-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"
  3. 新しい DB パラメータグループを使用するように DB インスタンスを変更します。

    Linux、macOS、Unix の場合:

    aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --db-parameter-group-name allow-triggers \ --apply-immediately

    Windows の場合:

    aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --db-parameter-group-name allow-triggers ^ --apply-immediately
  4. 変更を有効にするために、手動で DB インスタンスを再起動します。

    aws rds reboot-db-instance --db-instance-identifier mydbinstance

ポイントインタイム復元のエラーの診断と解決

一時テーブルを含む DB インスタンスの復元

MySQL または MriaDB DB インスタンスでポイントインタイム復元 (PITR) を実行しようとすると、次のエラーが発生する場合があります。

Database instance could not be restored because there has been incompatible database activity for restore functionality. Common examples of incompatible activity include using temporary tables, in-memory tables, or using MyISAM tables. In this case, use of Temporary table was detected.

PITR は、特定の時点への DB インスタンスの復元を MySQL または MariaDB のバックアップスナップショットとバイナリログ (binlog) の両方に依存します。binlog 内の一時テーブル情報は信頼できない場合があり、PITR の障害の原因となる可能性があります。MySQL または MriaDB DB インスタンスで一時テーブルを使用する場合は、より頻繁にバックアップを実行することによって、PITR の障害が発生する可能性を最小限に抑えることができます。PITR の障害が発生する可能性は、一時テーブルの作成から次のバックアップスナップショットまでの間で最も高くなります。

メモリ内テーブルを含む DB インスタンスの復元

メモリ内テーブルが含まれるデータベースを復元するときに問題が発生する可能性があります。メモリ内テーブルは再開時に消去されます。その結果、再起動後、メモリ内テーブルは空である可能性があります。メモリ内テーブルを使用する場合は、再開時に空のテーブルを処理するようにソリューションを設計することをお勧めします。インメモリテーブルをレプリケートされた DB インスタンスで使用している場合は、再起動後にリードレプリカを再作成する必要がある場合があります。これは、リードレプリカが再起動して空のインメモリテーブルからデータを復元できない場合に必要になる場合があります。

バックアップと PITR の詳細については、「バックアップの使用」および「特定の時点への DB インスタンスの復元」を参照してください。

レプリケーション停止エラー

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);

致命的なエラー 1236 によるリードレプリカの作成の失敗またはレプリケーションの中断

MySQL または MariaDB DB インスタンスのデフォルトパラメータ値を変更した後、以下のいずれかの問題が発生する可能性があります。

  • DB インスタンスのリードレプリカを作成できない。

  • レプリケーションが fatal error 1236 により失敗します。

MySQL および MariaDB DB インスタンスのいくつかのデフォルトパラメータ値は、データベースが ACID に準拠し、リードレプリカをクラッシュセーフにするために役立ちます。これは、コミットする前にトランザクションをバイナリログに書き込むことによって、各コミットが完全に同期されるようにすることで行います。パフォーマンスを上げるためにこれらのパラメータをデフォルト値から変更すると、トランザクションがバイナリログにまだ書き込まれていない場合にレプリケーションが失敗することがあります。

この問題を解決するには、次のパラメータ値を設定します。

  • sync-binlog = 1

  • innodb_support_xa = 1

  • innodb_flush_log_at_trx_commit = 1

バックアップ保持期間を 0 に設定できない

バックアップ保持期間を 0 に設定するのには、いくつかの理由があります。たとえば、保持期間を 0 に設定すると、自動バックアップをすぐに無効にすることができます。

場合によっては、値を 0 に設定すると、保持期間は 1 から 35 の間にする必要があるというメッセージが表示されることがあります。そのような場合は、インスタンスにリードレプリカが設定されていないことを確認します。リードレプリカでは、リードレプリカのログを管理するためにバックアップが必要なため、保持期間を 0 に設定することはできません。