メニュー
Amazon Relational Database Service
ユーザーガイド (API Version 2014-10-31)

トラブルシューティング

以下のセクションは、Amazon RDS の問題をトラブルシューティングするのに役立ちます。

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

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

  • ローカルファイアウォールによって実施されるアクセスルールと、インスタンスのセキュリティグループで DB インスタンスへのアクセスを許可した Ingress IP アドレスが同期していません。問題の原因はほとんどの場合、セキュリティグループの Ingress ルールです。デフォルトでは、DB インスタンスはアクセスを許可していません。アクセスはセキュリティグループを介して許可されます。アクセスを許可するには、状況に合わせて特定の Ingress ルールと Egress ルールを設定した独自のセキュリティグループを作成する必要があります。セキュリティグループのセットアップの詳細については、「セキュリティグループを作成して、VPC 内の DB インスタンスへのアクセスを提供します。」を参照してください。

  • DB インスタンスの作成時に指定したポートが、ローカルファイアウォールの制限によって、通信の送受信に使用できません。この場合、指定したポートをインバウンドおよびアウトバウンド通信に使用することがネットワークで許可されているかどうかを判断するには、ネットワーク管理者に確認します。

  • DB インスタンスは、まだ作成中であり、利用できません。DB インスタンスのサイズによっては、インスタンスが利用可能になるまでに最大 20 分かかることがあります。

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

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

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

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

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

Copy
$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 アクションは、接続のテスト以外についてはサポートされていないことに注意してください。接続に成功した場合、このアクションはメッセージを返しません。接続に成功しなかった場合、次のようなエラーメッセージが返されます。

Copy
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 アクションが成功を示している場合、セキュリティグループは適切に設定されています。

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

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 ロールに対する権限を復元したりできます。DB インスタンスのパスワードは、Amazon RDS コンソール、AWS CLI の modify-db-instance コマンド、または ModifyDBInstance アクションを使用して変更できます。SQL Server DB インスタンスの変更の詳細については、「Microsoft SQL Server データベースエンジンを実行する DB インスタンスの変更」を参照してください。

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

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

DB インスタンスの設定を変更したときは、[Apply Immediately] 設定を使用して、いつ変更が適用されたかを確認できます。DB インスタンスのアクションと [Apply Immediately] の値を設定することによる効果を示す表については、「Amazon RDS DB インスタンスを変更し、Apply Immediately パラメータを使用する」を参照してください。

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

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

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

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

  • ストレージのタイプを [Magnetic (Standard)] から [General Purpose (SSD)] または [Provisioned IOPS (SSD)] に変更、または [Provisioned IOPS (SSD)] または [General Purpose (SSD)] から [Magnetic (Standard)] に変更します。スタンダードから PIOPS に変更します。

以下のいずれかが発生したとき、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 RDS DB インスタンスのストレージ不足

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

データベースインスタンスのストレージが不足した場合、ストレージのステータスは storage-full に変化します。たとえば、ストレージをすべて使用した DB インスタンスについて、DescribeDBInstances アクションを呼び出すと、次のように出力されます。

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

このシナリオから復旧するには、ModifyDBInstance アクション、または次の AWS CLI コマンドを使用して、インスタンスにストレージ領域を追加します。

Linux、OS X、Unix の場合:

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

Windows の場合:

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

ここで DB インスタンスを表示すると、DB インスタンスは modifying ステータスであり、ストレージが拡張中であることを示します。

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

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

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

DescribeEvents アクションを使用すると、ストレージ領域がなくなったときに通知を受信できます。たとえば、このシナリオでは、これらのオペレーションの後に DescribeEvents の呼び出しを実行すると、次の出力が表示されます。

Copy
aws rds describe-events --source-type db-instance --source-identifier mydbinstance
Copy
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 インスタンス容量の不足

DB インスタンスクラスを変更しようとしたときに InsufficientDBInstanceCapacity エラーが発生した場合は、DB インスタンスが EC2-Classic プラットフォーム上にあり、VPC に存在しない可能性があります。一部の DB インスタンスクラスでは VPC が必要です。たとえば、EC2-Classic プラットフォームを使用していて、VPC が必要な DB インスタンスクラスに切り替えて容量を増やそうとすると、このエラーが発生します。VPC でのみ使用可能な Amazon Elastic Compute Cloud インスタンスタイプの詳細については、「VPC でのみ使用可能なインスタンスタイプ」 を参照してください。Amazon Elastic Compute Cloud ユーザーガイドに記載されています。

問題を解決するために、VPC 内に DB インスタンスを移動できます。詳細については、「VPC 外の DB インスタンスを VPC に移行する」を参照してください。

DB インスタンスの変更については、「Amazon RDS DB インスタンスを変更し、Apply Immediately パラメータを使用する」を参照してください。Amazon EC2 のインスタン容量問題のトラブルシューティングに関する詳細は、「インスタンス容量のトラブルシューティング」を参照してください。Amazon Elastic Compute Cloud ユーザーガイドに記載されています。

Amazon RDS MySQL および MariaDB の問題

インデックスマージの最適化で誤った結果が返される

この問題は MySQL DB インスタンスのみに適用されます。

インデックスマージの最適化を使用するクエリは、MySQL 5.5.37 で導入された MySQL クエリオプティマイザのバグのために誤った結果を返す場合があります。複数のインデックスを持つテーブルに対してクエリを実行すると、オプティマイザは複数のインデックスに基づいて行の範囲をスキャンしますが、結果を正しくマージしません。クエリのクエリオプティマイザのバグの詳細については、MySQL バグデータベースの http://bugs.mysql.com/bug.php?id=72745http://bugs.mysql.com/bug.php?id=68194 を参照してください。

たとえば、2 つのインデックスを持つテーブルで、検索引数がインデックス付き列を参照するクエリがあるとします。

Copy
SELECT * FROM table1 WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

この場合、検索エンジンは両方のインデックスを検索します。ただし、バグが原因で、マージされた結果は正しくありません。

この問題を解決するには、次のいずれかを実行します。

  • MySQL DB インスタンスの DB パラメータグループで optimizer_switch パラメータを index_merge=off に設定します。DB パラメータグループのパラメータの設定については、「DB パラメータグループを使用する」を参照してください。

  • MySQL DB インスタンスを MySQL バージョン 5.6 または 5.7 にアップグレードします。詳細については、「MySQL DB スナップショットのアップグレード」参照してください。

  • インスタンスをアップグレードできない場合や、optimizer_switch パラメータを変更できない場合は、明示的にクエリのインデックスを指定してバグを回避できます。たとえば、次のように指定します。

    Copy
    SELECT * FROM table1 USE INDEX covering_index WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

詳細については、「インデックスマージの最適化」を参照してください。

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

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

ReplicaLag メトリックは、MySQL の Seconds_Behind_Master フィールドまたは MariaDB の SHOW SLAVE STATUS コマンドの値を報告します。詳細については、「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 ドキュメントの「レプリケーションの概要」を参照してください。

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

  • リードレプリカの DB インスタンスクラスのストレージサイズを、ソース DB インスタンスのストレージサイズと同程度になるように設定します。

  • ソース DB インスタンスとリードレプリカにより使用される DB パラメータグループのパラメータ設定に互換性を確保します。詳細と例については、次のセクションにある max_allowed_packet パラメータの説明を参照してください。

  • クエリのキャッシュを無効にします。頻繁に変更されるテーブルでは、クエリのキャッシュを使用すると、キャッシュが頻繁にロックされ、更新されるため、レプリカの遅延が増加する可能性があります。このような場合、クエリのキャッシュを無効にすると、レプリカの遅延が小さくなることがあります。DB インスタンスの DB パラメータグループで query_cache_type parameter を 0 に設定することによって、クエリのキャッシュを無効にできます。クエリのキャッシュの詳細については、「クエリのキャッシュの設定」を参照してください。

  • MySQL の InnoDB またはリードレプリカの MariaDB のバッファープールの XtraDB のウォーミングを行います。頻繁に更新されているに小さい一連のテーブルがあり、InnoDB または XtraDB テーブルスキーマを使用している場合、リードレプリカでそれらのテーブルをダンプします。これを行うことで、データベースエンジンはディスクからそれらのテーブルの行をスキャンし、バッファープールにキャッシュするため、レプリカの遅延を短縮することができます。例を以下に示します。

    Linux、OS X、Unix の場合:

    Copy
    PROMPT> mysqldump \ –h <endpoint> \ --port=<port> \ -u=<username> \ -p <password> \ database_name table1 table2 > /dev/null

    Windows の場合:

    Copy
    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-0045RDS-EVENT-0046RDS-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 などの非トランザクションストレージエンジンを使用している。リードレプリカにはトランザクションストレージエンジンが必要です。複製は、MariaDB ストレージエンジンの MySQL と XtraDB の InnoDB でのみサポートされます。

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

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

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

Copy
"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、OS X、Unix の場合:

    Copy
    aws rds create-db-parameter-group \ --db-parameter-group-name allow-triggers \ --db-parameter-group-family mysql15.5 \ --description "parameter group allowing triggers"

    Windows の場合:

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

    Linux、OS X、Unix の場合:

    Copy
    aws rds modify-db-parameter-group \ --db-parameter-group-name allow-triggers \ --parameters "name=log_bin_trust_function_creators,value=true, method=pending-reboot"

    Windows の場合:

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

    Linux、OS X、Unix の場合:

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

    Windows の場合:

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

    Copy
    aws rds reboot-db-instance mydbinstance

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

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

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

Copy
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 内の一時テーブル情報は信頼できない場合があり、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」の手順を使用して、DB クラスターのバイナリログファイルの保持期間に合わせて、「binlog retention hours」の設定パラメータを指定します。最大値は 720 (30 日) です。以下の例では、バイナリログファイルの保持期間を 48 時間に設定しています。

Copy
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

Amazon Aurora の問題

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

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

Copy
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 インスタンスクラスによって異なります。R3 DB インスタンスタイプのローカル SSD ストレージの量を調べるには、「メモリ最適化 R3」を参照してください。

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

Amazon RDS Oracle GoldenGate の問題

十分な時間のログの保持

ソースデータベースでは、アーカイブされた再実行ログを保持する必要があります。ログを保持する期間は、時間単位で指定します。保持期間は、ソースインスタンスで発生する可能性があるダウンタイムや、通信/ネットワークの問題の期間に十分対応できる期間にする必要があります。これにより、Oracle GoldenGate では、必要に応じてソースインスタンスからログを復旧することができます。ログの保持で絶対的に必要となる最小時間は、1 時間です。ログの保持を有効にしていない場合や、保持期間の値が小さすぎる場合、次のエラーメッセージが表示されます。

Copy
2014-03-06 06:17:27 ERROR OGG-00446 error 2 (No such file or directory) opening redo log /rdsdbdata/db/GGTEST3_A/onlinelog/o1_mf_2_9k4bp1n6_.log for sequence 1306Not able to establish initial position for begin time 2014-03-06 06:16:55.

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

SQL Server Management Studio を使用して DB インスタンスに接続するときに問題が発生する場合、一般的な原因は次のとおりです。

  • ローカルファイアウォールによって実施されるアクセスルール、およびインスタンスのセキュリティグループで DB インスタンスへのアクセスを許可した IP アドレスが同期していません。Microsoft SQL Server Management Studio で DB インスタンスのエンドポイントとポートを使用して接続できない場合、問題の原因は、通常、ファイアウォールの Egress または Ingress ルールです。アクセスを許可するには、状況に合わせて特定の Ingress ルールと Egress ルールを設定した独自のセキュリティグループを作成する必要があります。セキュリティグループの詳細については、Amazon RDS セキュリティグループ を参照してください。

  • DB インスタンスの作成時に指定したポートが、ローカルファイアウォールの制限によって、通信の送受信に使用できません。この場合、指定したポートをインバウンドおよびアウトバウンド通信に使用することがネットワークで許可されているかどうかを判断するには、ネットワーク管理者に確認します。

  • DB インスタンスは、まだ作成中であり、利用できません。DB インスタンスのサイズによっては、インスタンスが利用可能になるまでに最大 20 分かかることがあります。

指定したポートで通信を送受信できる場合は、次の SQL Server のエラーを確認します。

  • SQL Server への接続を開けませんでした - Microsoft SQL Server, エラー: 53 – Microsoft SQL Server Management Studio を使用しているときは、サーバー名を指定するときにポート番号を含める必要があります。たとえば、 (ポート番号を含む) DB インスタンスのサーバー名は、「sqlsvr-pdz.c6c8mdfntzgv0.region.rds.amazonaws.com,1433」のようになります。

  • 対象のコンピュータによって能動的に拒否されたため、接続できません - Microsoft SQL Server, エラー: 10061 – この場合、DB インスタンスには到達できましたが、接続が拒否されました。このエラーは、通常、ユーザー名やパスワードが正しくないときに発生します。

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

PostgreSQL DB インスタンスに接続する際に発生する最も一般的な問題は、DB インスタンスに割り当てられたセキュリティグループに不適切なアクセスルールが含まれていることです。デフォルトでは、DB インスタンスはアクセスを許可していません。アクセスはセキュリティグループを介して許可されます。アクセスを許可するには、状況に合わせて特定の Ingress ルールと Egress ルールを設定した独自のセキュリティグループを作成する必要があります。DB インスタンスのセキュリティグループの作成の詳細については、「セキュリティグループを作成して、VPC 内の DB インスタンスへのアクセスを提供します。」を参照してください。

最も一般的なエラーは「could not connect to server: Connection timed out」です。このエラーが発生した場合、ホスト名が DB インスタンスのエンドポイントであること、およびポート番号が正しいことを確認します。ローカルファイアウォールを介したアクセスを許可するのに必要なルールが、DB インスタンスに割り当てられたセキュリティグループに設定されていることを確認します。