Amazon RDS のトラブルシューティング - Amazon Relational Database Service
DB インスタンスに接続できないセキュリティの問題互換性のないネットワーク状態のトラブルシューティングDB インスタンス所有者のパスワードのリセットDB インスタンスの停止または再起動パラメータの変更が有効にならないDB インスタンスのストレージ不足DB インスタンス容量の不足RDS の解放可能なメモリの問題MySQL および MariaDB の問題バックアップ保持期間を 0 に設定できない

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

以下のシナリオを使用して、Amazon RDS や Amazon 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 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 インスタンスを変更します。

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

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 インスタンスクラスの変更。

  • マルチ AZ DB クラスターデプロイメントを使用するための DB インスタンスの変更。

  • メンテナンスイベントによるホストの交換。

  • 代替 DB インスタンスの起動。

  • スナップショットバックアップからの復元。

  • 以前に停止した DB インスタンスの開始。

解決方法

start-db-instance コマンドを使用する

互換性のないネットワーク状態にあるデータベースを修正するには、以下の手順に従ってください。

  1. https://console.aws.amazon.com/rds/ を開いて、[データベース]ナビゲーションペインを選択します。

  2. 非互換ネットワーク状態の DB インスタンスを選択し、[接続とセキュリティ] タブから DB インスタンス識別子、VPC ID、およびサブネット ID を書き留めます。

  3. AWS CLI を使用して start-db-instance コマンドを実行します。--db-instance-identifier 値を指定します。

    注記

    データベースが非互換モードのときにこのコマンドを実行すると、ある程度のダウンタイムが発生する可能性があります。

    start-db-instance コマンドを実行しても、SQL Server DB インスタンス用 RDS の問題は解決されません。

コマンドが正常に実行された場合、データベースのステータスは [使用可能] に変わります。

データベースが再起動すると、DB インスタンスは、非互換ネットワーク状態に移行する前にインスタンスで実行された最後の操作を実行する可能性があります。これにより、インスタンスは非互換ネットワーク状態に戻る可能性があります。

start-db-instance コマンドが失敗するか、インスタンスが互換性のないネットワーク状態に戻る場合は、RDS コンソールの [データベース] ページで、データベースを選択します。[ログとイベント] セクションに移動します。[最近のイベント] セクションには、今後の解決手順が表示されます。メッセージは次のように分類されます。

  • INTERNAL RESOURCE CHECK: 内部リソースに問題がある可能性があります。

  • DNS CHECK: VPC コンソールで VPC の DNS 解決とホスト名を確認します。

  • ENI CHECK: データベースの Elastic Network Interface (ENI) が存在しない可能性があります。

  • GATEWAY CHECK: 公開されているデータベースのインターネットゲートウェイは VPC にアタッチされていません。

  • IP CHECK: サブネットには空き IP アドレスがありません。

  • SECURITY GROUP CHECK: データベースに関連付けられているセキュリティグループがないか、セキュリティグループが無効です。

  • SUBNET CHECK: DB サブネットグループに有効なサブネットがないか、サブネットに問題があります。

  • VPC CHECK: データベースに関連付けられている VPC は無効です。

ポイントインタイムリカバリを実行する

データベースが互換性のないネットワーク状態になった場合に備えて、バックアップ (スナップショットまたは論理) を作成するのがベストプラクティスです。「バックアップの概要」を参照してください。自動化バックアップを有効にした場合は、データベースへの書き込みを一時的に停止し、ポイントインタイムリカバリを実行してください。

注記

インスタンスが互換性のないネットワーク状態になると、DB インスタンスにアクセスして論理バックアップを実行できなくなる可能性があります。

自動バックアップを有効にしていない場合は、新しい DB インスタンスを作成してください。次に、AWS Database Migration Service(AWS DMS) を使用してデータを移行するか、またはバックアップと復元ツールを使用します。

これで問題が解決しない場合は、AWS Support に問い合わせてサポートを受けてください。

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 に変更します。次に、[Apply Immediately] (すぐに適用) を 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 コンソールを使用して DB インスタンスを再起動できます。または、RebootDBInstance API オペレーションを明示的に呼び出すこともできます。DB インスタンスがマルチ AZ 配置にある場合は、フェイルオーバーなしで再起動できます。静的パラメータの変更後に関連付けられている 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 EC2 ユーザーガイドの「インスタンス容量の不足」を参照してください。

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

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

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

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

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

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

MySQL および MariaDB の問題

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

MySQL および MariaDB の最大接続数

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

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

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

SELECT @@max_connections;

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

SHOW STATUS WHERE `variable_name` = 'Threads_connected';

メモリ制限と互換性のないパラメータの状態の診断と解決

次の条件が満たされた場合、MariaDB インスタンスまたは MySQL DB インスタンスは、メモリ制限の incompatible-parameters ステータスになります。

  • DB インスタンスのステータスが 利用可能 の状態で、DB インスタンスが 1 時間に 3 回以上または 1 日で 5 回以上再起動される場合。

  • メンテナンスアクションまたはモニタリングプロセスが DB インスタンスを再起動できなかったため、DB インスタンスを再起動しようとして失敗した場合。

  • DB インスタンスの潜在的なメモリ使用量が、DB インスタンスクラスに割り当てられたメモリの 1.2 倍を超える場合。

DB インスタンスが 1 時間で 3 回再起動するか、1 日で 5 回再起動すると、その時点でメモリ使用量のチェックが実行されます。このチェックで、DB インスタンスの潜在的なメモリ使用量を計算します。計算によって、次の値の合計が返されます。

  • 値 1 - 次のパラメータの合計です。

    • innodb_additional_mem_pool_size

    • innodb_buffer_pool_size

      innodb_buffer_pool_size の値は変更することが可能です。ただし、値が入力内容と常に一致するとは限りません。この不一致は、いくつかの理由で発生します。まず、DB インスタンスがマイクロ DB インスタンスの場合は、デフォルト値を上書きして 256 MB に設定します。詳細については、「innodb_buffer_pool_size の上書き」を参照してください。

      次に、ホストマネージャー、エンジン、オペレーティングシステム、カーネル用に DB インスタンスに 500 MB のメモリが予約されていることを確認します。

      最後に、単位に分割して innodb_buffer_pool_size を最適化します。ホストマネージャーは、それらの単位のうち最も近い倍数に切り下げます。単位は、innodb_buffer_pool_chunk_size に innodb_buffer_pool_instances を乗算して計算されます。詳細については、「MySQL ドキュメント」の「Configuring InnoDB Buffer Pool Size」を参照してください。

      innodb_buffer_pool_size が 1 GB 未満でない限り、innodb_buffer_pool_instances のデフォルトは 8 です。innodb_buffer_pool_size が 1 GB 未満の場合、innodb_buffer_pool_instances のデフォルトは 1 です。innodb_buffer_pool_chunk_size のデフォルトは 128 MB です。

    • innodb_log_buffer_size

    • key_buffer_size

    • query_cache_size (MySQL バージョン 5.7 のみ)

    • tmp_table_size

  • 値 2 - max_connections パラメータに、次のパラメータの合計を乗算した結果です。

    • binlog_cache_size

    • join_buffer_size

    • read_buffer_size

    • read_rnd_buffer_size

    • sort_buffer_size

    • thread_stack

  • 値 3 - performance_schema パラメータが有効な場合は、max_connections パラメータに 429498 を乗算します。

    performance_schema パラメータが無効の場合、この値はゼロになります。

したがって、計算によって返される値は次のとおりです。

Value 1 + Value 2 + Value 3

この値が、DB インスタンスが使用する DB インスタンスクラスに割り当てられたメモリの 1.2 倍を超えると、DB インスタンスは incompatible-parameters ステータスになります。DB インスタンスクラスに割り当てられるメモリの詳細については、「DB インスタンスクラスのハードウェア仕様」を参照してください。

max_connections パラメータの値に複数のパラメータの合計を乗算して計算します。max_connections パラメータに大きな値が設定されている場合、DB インスタンスの潜在的なメモリ使用量として、非常に高い値をチェックが返す可能性があります。この場合、max_connections パラメータの値を小さくしてみてください。

この問題を解決するには、以下のステップを完了する必要があります。

  1. DB インスタンスに関連付けられた DB パラメータグループのメモリパラメータを調整します。調整する際に、潜在的なメモリ使用量が DB インスタンスクラスに割り当てられたメモリの 1.2 倍未満になるようにします。

    パラメータの設定の詳細については、「DB パラメータグループのパラメータの変更」を参照してください。

  2. DB インスタンスを再起動します。

    パラメータの設定の詳細については、「以前に停止した Amazon RDS DB インスタンスを開始する」を参照してください。

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

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

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

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

注記

MariaDB および MySQL の旧バージョンは、SHOW SLAVE STATUS ではなく SHOW REPLICA STATUS を使用していました。10.5 より前の MariaDB バージョン、または 8.0.23 より前の MySQL バージョンを使用している場合は、SHOW SLAVE STATUS を使用します。

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

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

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

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

  • リードレプリカの DB インスタンスクラスが出典の DB インスタンスと同程度のストレージサイズを持つように設定します。

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

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

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

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

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

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

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

  • 論理的なエラーが発生し、安全にエラーをスキップできる場合は、「現在のレプリケーションエラーのスキップ」で説明されているステップに従ってください。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 for MySQL または RDS for MriaDB の DB インスタンスにトリガーを作成しようとすると、次のエラーが表示される場合があります。

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

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

新しい DB パラメータグループを作成することで、バイナリログを有効にして RDS for MySQL または RDS for MriaDB 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 コマンドを呼び出すと、レプリケーションがダウンまたは無効であることを示すエラーメッセージが表示されることがあります。

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

多数のエラーをスキップする必要がある場合は、レプリケーションの遅延により、バイナリログファイルがデフォルトの保持期間を超えて増大する場合があります。この場合、バイナリログファイルがレプリカで再生される前に破棄され、致命的なエラーが発生することがあります。この破棄によりレプリケーションが停止し、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 に設定することはできません。