# Amazon Aurora のトラブルシューティング 以下のシナリオを使用して、Amazon RDS や Amazon Aurora の DB インスタンスで発生する問題をトラブルシューティングします。 **Topics** + [Amazon RDS DB インスタンスに接続できない](#CHAP_Troubleshooting.Connecting) + [Amazon RDS のセキュリティの問題](#CHAP_Troubleshooting.Security) + [DB インスタンス所有者のパスワードのリセット](#CHAP_Troubleshooting.ResetPassword) + [Amazon RDS DB インスタンスの停止または再起動](#CHAP_Troubleshooting.Reboots) + [Amazon RDS DB パラメータの変更が有効にならない](#CHAP_Troubleshooting.Parameters) + [Amazon Aurora の解放可能なメモリの問題](#Troubleshooting.FreeableMemory) + [Amazon Aurora MySQL レプリケーションの問題](#CHAP_Troubleshooting.MySQL) Amazon RDS API を使用した問題のデバッグについては、「[Aurora のアプリケーションのトラブルシューティング](APITroubleshooting.md)」を参照してください。 ## Amazon RDS DB インスタンスに接続できない DB インスタンスに接続できない場合、一般的な原因として次のようなものがあります。 + **インバウンドルール** - ローカルのファイアウォールによって適用されているアクセスルールと DB インスタンスへのアクセスが許可された IP アドレスが一致していない可能性があります。問題の原因として最も多いのは、セキュリティグループのインバウンドルールです。 デフォルトでは、DB インスタンスへのアクセスは許可されていません。アクセスは、DB インスタンスとの間のトラフィックを許可する VPC に関連付けられたセキュリティグループによって許可されます。必要に応じて、特定の状況のインバウンドルールとアウトバウンドルールをセキュリティグループに追加します。IP アドレス、IP アドレスの範囲、または別の VPC セキュリティグループを指定できます。 **注記** 新しいインバウンドルールを追加するときに [**出典**] に [**マイ IP**] を選択すると、ブラウザで検出された IP アドレスから DB インスタンスへのアクセスを許可できます。 セキュリティグループの設定の詳細については、「[セキュリティグループを作成して VPC 内の DB クラスターへのアクセスを提供する](CHAP_SettingUp_Aurora.md#CHAP_SettingUp_Aurora.SecurityGroup)」を参照してください。 **注記** 169.254.0.0/16 の範囲内の IP アドレスからのクライアント接続は許可されていません。これは、ローカルリンクのアドレス指定に使用される Automatic Private IP Addressing Range (APIPA) です。 + **パブリックアクセス** - クライアントアプリケーションを使用するなど、VPC の外部から DB インスタンスに接続するには、インスタンスにパブリック IP アドレスが割り当てられている必要があります。 インスタンへのパブリックアクセスを許可するには、インスタンスを変更し、[**Public accessibility (パブリックアクセス)**] で [**Yes (はい)**] を選択します。詳細については、「[VPC 内の DB クラスターをインターネットから隠す](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding)」を参照してください。 + **ポート** - DB インスタンスの作成時に指定したポートが、ローカルのファイアウォールの制限によって通信の送受信に使用できない場合があります。指定したポートをインバウンドおよびアウトバウンドの通信に使用することがネットワークで許可されているかどうかを判断するには、ネットワーク管理者に確認します。 + **可用性** - 新しく作成された DB インスタンスでは、DB インスタンスが使用できるようになるまで、DB インスタンスのステータスは `creating` になります。ステータスが `available` になると、DB インスタンスに接続できます。DB インスタンスのサイズによっては、インスタンスが利用可能になるまでに最大 20 分かかることがあります。 + **内部ゲートウェイ** - DB インスタンスをパブリックにアクセス可能にするには、その DB サブネットグループのサブネットにインターネットゲートウェイが必要です。 **サブネットのインターネットゲートウェイを設定するには** 1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。 1. ナビゲーションペインで、[**データベース**] を選択し、DB インスタンスの名前を選択します。 1. [**接続とセキュリティ**] タブで、[**VPC**] の下の VPC ID と [**サブネット**] の下のサブネット ID の値を書き留めます。 1. Amazon VPC コンソール ([https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)) を開きます。 1. ナビゲーションペインで、[**Internet Gateways**] を選択してください。ご使用の VPC にアタッチされているインターネットゲートウェイがあることを確認します。それ外の場合は、[**Create Internet Gateway**] を選択してインターネットゲートウェイを作成します。インターネットゲートウェイを選択し、[**VPC にアタッチ**] を選択して指示どおりにインターネットゲートウェイを VPC にアタッチします。 1. ナビゲーションペインで [**Subnets**] を選択し、サブネットを選択します。 1. [**Route Table**] タブで、送信先として `0.0.0.0/0`、ターゲットとして VPC のインターネットゲートウェイが指定されたルートがあることを確認します。 IPv6 アドレスを使用してインスタンスに接続する場合はインターネットゲートウェイを指しているすべての IPv6 トラフィック (`::/0`) 用のルートがあることを確認します。それ以外の場合は以下の作業を行います。 1. ルートテーブルの ID (rtb-*xxxxxxxx*) を選択して、ルートテーブルに移動します。 1. [**ルーター**] タブで、[**ルーター編集**] を選択してください。[**Add route**] を選択して、`0.0.0.0/0` を送信先として追加し、インターネットゲートウェイをターゲットとして使用します。 IPv6 の場合は、[**Add route**] を選択して、`::/0` を送信先として追加し、インターネットゲートウェイをターゲットとして使用します。 1. [**ルートの保存**] を選択します。 また、IPv6 エンドポイントに接続する場合は、クライアントの IPv6 アドレス範囲が DB インスタンスへの接続を認可されていることを確認してください。 詳細については、「[VPC 内の DB クラスターの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md)」を参照してください。 ### 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 アカウントルートユーザー E メールアドレスとパスワードをユーザーアカウントに使用しないでください。ベストプラクティスは、ルートユーザーを使用してユーザーを作成し、DB ユーザーアカウントに割り当てることです。また、必要に応じて、ルートユーザーを使用して他のユーザーアカウントを作成することもできます。 ユーザーの作成の詳細については、「[AWS アカウント での IAM ユーザーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html)」を参照してください。AWS IAM アイデンティティセンター でのユーザー作成の詳細については、「[Manage identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)」(IAM Identity Center での ID の管理) を参照してください。 ### エラーメッセージ「アカウント属性の取得に失敗しました。コンソールの特定の機能が損なわれる可能性があります。」 このエラーが発生する原因はいくつかあります。アカウントにアクセス許可がないか、アカウントが正しく設定されていない可能性があります。新規のアカウントの場合は、アカウントの準備がまだ整っていない可能性があります。既存のアカウントの場合は、DB インスタンスの作成などの特定の操作を実行するためのアクセスポリシーでアクセス許可が設定されてない可能性があります。問題を修正するには、管理者が必要なロールをアカウントに与える必要があります。詳細については、「[IAM ドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/)」を参照してください。 ## DB インスタンス所有者のパスワードのリセット DB クラスターからロックアウトされた場合は、マスターユーザーとしてログインできます。その後、他の管理ユーザーまたはロールの認証情報をリセットできます。マスターユーザーとしてログインできない場合は、AWS アカウントの所有者がマスターユーザーのパスワードをリセットできます。リセットする必要がある管理アカウントまたはロールの詳細については、「[マスターユーザーアカウント権限](UsingWithRDS.MasterAccounts.md)」を参照してください。 DB インスタンスのパスワードは、Amazon RDS コンソール、AWS CLI コマンドの [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)、または [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API オペレーションを使用して変更できます。DB クラスターの DB インスタンスの変更の詳細については、「[DB クラスター内の DB インスタンスの変更](Aurora.Modifying.md#Aurora.Modifying.Instance)」を参照してください。 ## 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 インスタンスを再起動できます。または、[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html) API オペレーションを明示的に呼び出すこともできます。DB インスタンスがマルチ AZ 配置にある場合は、フェイルオーバーなしで再起動できます。静的パラメータの変更後に関連付けられている DB インスタンスの再起動を求める要件は、パラメータの誤った設定が API コールに影響を及ぼすリスクを低減するために役立ちます。例えば、`ModifyDBInstance` を呼び出して DB インスタンスクラスを変更する場合があります。詳細については、「[Amazon Aurora の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。 ## Amazon Aurora の解放可能なメモリの問題 *解放可能なメモリ*は、データベースエンジンで使用できる DB インスタンスの合計ランダムアクセスメモリ (RAM) です。これは、空きオペレーティングシステム (OS) メモリと使用可能なバッファとページキャッシュメモリの合計です。データベースエンジンは、ホスト上のほとんどのメモリを使用しますが、OS プロセスも一部の RAM を使用します。データベースエンジンに現在割り当てられているメモリや OS プロセスによって使用されているメモリは、空きメモリには含まれません。データベースエンジンのメモリが不足している場合、DB インスタンスは、バッファリングとキャッシュに通常使用される一時スペースを使用できます。前述のように、この一時スペースは空きメモリに含まれます。 Amazon CloudWatch の `FreeableMemory` メトリクスを使用して、空きメモリを監視します。詳細については、「[Amazon Aurora のモニタリングツール](MonitoringOverview.md)」を参照してください。 DB インスタンスの解放可能なメモリが常に不足またはスワップ領域を使用する場合、DB インスタンスクラスへのスケールアップを検討する必要があります。詳細については、「[Amazon Aurora DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。 メモリ設定を変更することもできます。例えば、Aurora MySQL と指定すると、`innodb_buffer_pool_size`パラメータのサイズを調整することもできます。このパラメータはデフォルトで物理メモリの 75% に設定されています。MySQL のトラブルシューティングのヒントについては、「[Amazon RDS for MySQL データベースの空きメモリ不足のトラブルシューティング方法を教えてください](https://aws.amazon.com/premiumsupport/knowledge-center/low-freeable-memory-rds-mysql-mariadb/)」を参照してください。 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-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring)」を参照してください。 ## Amazon Aurora MySQL レプリケーションの問題 MySQL のレプリケーションの問題のいくつかは、Aurora MySQL にも該当します。これらの問題を診断して修正できます。 **Topics** + [リードレプリカ間の遅延の診断と解決](#CHAP_Troubleshooting.MySQL.ReplicaLag) + [MySQL のリードレプリケーションのエラーの診断と解決](#CHAP_Troubleshooting.MySQL.RR) + [レプリケーション停止エラー](#CHAP_Troubleshooting.MySQL.ReplicationStopped) + [リードレプリカのレプリケーションがメタデータ構造の初期化に失敗する](#CHAP_Troubleshooting.MySQL.ReadReplicas.ReplicationErrorMetadata) ### リードレプリカ間の遅延の診断と解決 MySQL のリードレプリカを作成してそのリードレプリカが使用可能になると、Amazon RDS はリードレプリカの作成オペレーションがスタートされた時点以降に出典の DB インスタンスに対して行われた変更を初期にレプリケートします。このフェーズでは、リードレプリカのレプリケーション遅延時間が 0 より大きくなります。これは、Amazon CloudWatch で Amazon RDS の `AuroraBinlogReplicaLag` メトリクスを参照することによってモニタリングできます。 `AuroraBinlogReplicaLag` メトリクスには、MySQL `Seconds_Behind_Master` コマンドの `SHOW REPLICA STATUS` フィールドの値が報告されます。詳細については、MySQL ドキュメントの「[SHOW REPLICA STATUS ステートメント](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html)」を参照してください。 `AuroraBinlogReplicaLag` メトリクスが 0 に達すると、レプリカがソース DB インスタンスに追いついています。`AuroraBinlogReplicaLag` メトリクスが -1 を返す場合、レプリケーションがアクティブではない可能性があります。レプリケーションのエラーをトラブルシューティングする場合は、「[MySQL のリードレプリケーションのエラーの診断と解決](#CHAP_Troubleshooting.MySQL.RR)」を参照してください。`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 ドキュメントの「[レプリケーション実装の詳細](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation-details.html)」を参照してください。 出典の DB インスタンスに対する更新とそれに続くリードレプリカに対する更新の間の遅延を低減するには、次のような方法があります。 + リードレプリカの DB インスタンスクラスが出典の DB インスタンスと同程度のストレージサイズを持つように設定します。 + 出典の DB インスタンスとリードレプリカによって使用される DB パラメータグループのパラメータ設定の互換性を保ちます。詳細と例については、次のセクションにある `max_allowed_packet` パラメータの説明を参照してください。 + クエリのキャッシュを無効にします。頻繁に変更されるテーブルでは、クエリのキャッシュを使用すると、キャッシュが頻繁にロックされ、更新されるため、レプリカの遅延が増加する可能性があります。このような場合、クエリのキャッシュを無効にすると、レプリカの遅延が小さくなることがあります。DB インスタンスの DB パラメータグループで `query_cache_type parameter` を 0 に設定することによって、クエリのキャッシュを無効にできます。クエリのキャッシュの詳細については、「[クエリのキャッシュの設定](https://dev.mysql.com/doc/refman/5.7/en/query-cache-configuration.html)」を参照してください。 + InnoDB for MySQL のリードレプリカのバッファプールをウォームします。例えば、頻繁に更新される一連の小さなテーブルがあり、InnoDB または XtraDB のテーブルスキーマを使用しているとします。その場合、それらのテーブルをリードレプリカにダンプします。そうすることで、データベースエンジンはそれらのテーブルの行をディスクからスキャンしてバッファプールにキャッシュします。これにより、レプリカの遅延を低減することができます。例を以下に示します。 Linux、macOS、Unix の場合: ``` PROMPT> mysqldump \ -h {{}} \ --port={{}} \ -u={{}} \ -p {{}} \ database_name {{table1 table2}} > /dev/null ``` Windows の場合: ``` PROMPT> mysqldump ^ -h {{}} ^ --port={{}} ^ -u={{}} ^ -p {{}} ^ database_name {{table1 table2}} > /dev/null ``` ### MySQL のリードレプリケーションのエラーの診断と解決 Amazon RDS では、リードレプリカのレプリケーションステータスをモニタリングします。RDS では、何らかの理由でレプリケーションが停止した場合、リードレプリカのインスタンスの **[Replication State]** (レプリケーションステータス) フィールドを `Error` に更新します。MySQL** または MariaDB** エンジンによりスローされた関連するエラーの詳細は、[] フィールドを参照することで確認できます。リードレプリカのステータスを示すイベントが生成されます ([RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045)、[RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046)、[RDS-EVENT-0057](USER_Events.Messages.md#RDS-EVENT-0057) など)。イベントについてとイベントへのサブスクライブの詳細については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。MySQL のエラーメッセージが返された場合は、[MySQL のエラーメッセージのドキュメント](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html)でエラーを確認してください。 レプリケーションエラーを引き起こす可能性がある一般的な状況は次のとおりです。 + リードレプリカの `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 . engine=innodb;` + `SYSDATE()` など、安全でない非決定的クエリを使用している。詳細については、MySQL ドキュメントの「[バイナリロギングでの安全および安全でないステートメントの判断](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html)」を参照してください。 以下のステップは、レプリケーションエラーを解決するのに役立ちます。 + 論理的なエラーが発生し、安全にエラーをスキップできる場合は、「[現在のレプリケーションエラーのスキップ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.SkipError.html)」のステップに従ってください。Aurora MySQL DB インスタンスは、`mysql_rds_skip_repl_error` プロシージャを含むバージョンを実行している必要があります。詳細については、「[mysql\_rds\_skip\_repl\_error](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_skip_repl_error.html)」を参照してください。 + バイナリログ (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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_next_master_log.html)」を参照してください。 + DML の高負荷によって一時パフォーマンスの問題が発生した場合は、リードレプリカの DB パラメータグループで `innodb_flush_log_at_trx_commit` パラメータを 2 に設定できます。これを行うことによって、一時的に ACID 特性 (不可分性、整合性、分離性、耐久性の高い) が低下しますが、リードレプリカの遅延を解消するのに役立ちます。 + リードレプリカを削除し、同じ DB インスタンス識別子を使用してインスタンスを作成できます。この方法では、エンドポイントは前のリードレプリカと同じままになります。 レプリケーションエラーが解決すると、[**Replication State**] は [**replicating**] に変化します。詳細については、「[MySQL リードレプリカに関する問題のトラブルシューティング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.Troubleshooting.html)」を参照してください。 ### レプリケーション停止エラー `mysql.rds_skip_repl_error` コマンドを呼び出すと、レプリケーションがダウンまたは無効であることを示すエラーメッセージが表示されることがあります。 このエラーメッセージは、レプリケーションが停止して再開できないために表示されます。 多数のエラーをスキップする必要がある場合は、レプリケーションの遅延により、バイナリログファイルがデフォルトの保持期間を超えて増大する場合があります。この場合、バイナリログファイルがレプリカで再生される前に破棄されるため、致命的なエラーが発生することがあります。この破棄によりレプリケーションが停止し、`mysql.rds_skip_repl_error` コマンドを呼び出してレプリケーションエラーをスキップすることができなくなります。 この問題は、レプリケーション出典でバイナリログファイルの保持時間を増加させることで軽減できます。バイナリログ保持時間を長くすると、レプリケーションを再開し、必要に応じて `mysql.rds_skip_repl_error` コマンドを使用できるようになります。 バイナリログの保持期間を設定するには、[mysql\_rds\_set\_configuration](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.Troubleshooting.html) プロシージャを使用します。設定パラメータの「binlog retention hours」と DB クラスターでバイナリログファイルを保持する時間数を最大 2,160 時間 (90 日) で指定します。Aurora MySQL のデフォルトは 24 (1 日) です。以下の例では、バイナリログファイルの保持期間を 48 時間に設定しています。 ``` CALL mysql.rds_set_configuration('binlog retention hours', 48); ``` ### リードレプリカのレプリケーションがメタデータ構造の初期化に失敗する レプリケーションを開始しようとして、次のエラーメッセージが表示されました。 ``` Read Replica Replication Error - SQLError: 13124, reason: Replica failed to initialize applier metadata structure from the repository ``` このエラーは、レプリカのメタデータ構造に問題がある場合に発生します。メタデータ構造を修正するには、新しいレプリカを作成する必要があります。 このエラーが今後発生しないようにするには、次のいずれかのアクションを実行します。 + 可能であれば、レプリカのマルチスレッドを無効にします。MySQL 8.0.27 以降、マルチスレッドはデフォルトで有効になっています。 + レプリカでマルチスレッドを使用する必要がある場合は、GTID ベースのレプリケーションを使用することをお勧めします。詳細については、「[GTID ベースレプリケーションを使用する](mysql-replication-gtid.md)」を参照してください。