MySQL リードレプリカに関する問題のトラブルシューティング - Amazon Relational Database Service

MySQL リードレプリカに関する問題のトラブルシューティング

MySQL DB インスタンスでは、リードレプリカとソース DB インスタンスの間のレプリケーションエラーやデータの不整合 (またはその両方) がリードレプリカで発生する場合があります。この問題は、リードレプリカまたはソースの DB インスタンスの障害時に、一部のバイナリログ (binlog) イベントまたは InnoDB redo ログがフラッシュされない場合に発生します。その場合、リードレプリカを手動で削除して作成し直します。次のパラメータ値 (sync_binlog=1、innodb_flush_log_at_trx_commit=1) を設定することで、これが発生する可能性を減らすことができます。これらの設定によりパフォーマンスが低下することがあるため、本稼働環境で変更を実装する前に影響をテストしてください。

警告

ソース DB インスタンスに関連付けられたパラメータグループでは、パラメータ値 sync_binlog=1 および innodb_flush_log_at_trx_commit=1 を保持することをお勧めします。これらのパラメータは動的です。これらの設定を使用しない場合、ソース DB インスタンスで再起動する可能性のある操作を実行する前に、これらの値を一時的に設定することをお勧めします。該当する操作には、再起動、フェイルオーバーによる再起動、データベースバージョンのアップグレード、DB インスタンスクラスまたはそのストレージの変更が含まれますが、これらに限定されません。同じ推奨事項が、ソース DB インスタンスの新しいリードレプリカを作成する場合にも適用されます。

このガイダンスに従わない場合、リードレプリカとソースの DB インスタンス間のレプリケーションエラーやデータの不整合 (またはその両方) がリードレプリカで発生するリスクが高くなります。

MySQL のレプリケーションテクノロジーは非同期です。非同期であるため、ソースの DB インスタンスの BinLogDiskUsage やリードレプリカの ReplicaLag が増加する場合があります。例えば、ソース DB インスタンスへの大量の書き込みオペレーションは並行して実行できます。一方、リードレプリカへの書き込みオペレーションは単一の I/O スレッドでシリアルで行われるため、ソースのインスタンスとリードレプリカの間で遅延が発生する場合があります。読み取り専用レプリカの詳細については、MySQL ドキュメントの「レプリケーション実装の詳細」を参照してください。

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

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

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

Amazon RDS は、リードレプリカのレプリケーションの状態をモニタリングし、何らかの理由でレプリケーションが停止した場合はリードレプリカのインスタンスの Replication State フィールドを Error に更新します。これには、リードレプリカで実行された DML クエリがソースの DB インスタンスで行われた更新と競合した場合などがあります。

Replication Errorフィールドを参照することで、MySQL エンジンによりスローされた関連するエラーの詳細を確認できます。リードレプリカのステータスを示すイベントが生成されます (RDS-EVENT-0045、RDS-EVENT-0046、RDS-EVENT-0047 など)。イベントについてとイベントへのサブスクライブの詳細については、「Amazon RDS イベント通知の操作」を参照してください。MySQL のエラーメッセージが返された場合は、MySQL のエラーメッセージのドキュメントでエラー番号を確認してください。

レプリケーションエラーを引き起こす一般的な問題は、リードレプリカの max_allowed_packet パラメータの値がソース DB インスタンスの max_allowed_packet パラメータより小さいことです。max_allowed_packet パラメータは、DB パラメータグループで設定できるカスタムパラメータです。max_allowed_packet は、データベースで実行できる DML コードの最大サイズを指定するために使用します。場合によっては、リードレプリカに関連付けらている DB パラメータグループの max_allowed_packet の値が、ソース DB インスタンスに関連付けられている DB パラメータグループの max_allowed_packet の値より小さいことがあります。このような場合、レプリケーションプロセスは Packet bigger than 'max_allowed_packet' bytes エラーをスローし、レプリケーションを停止する可能性があります。このエラーを修正するには、ソース DB インスタンスとリードレプリカの DB パラメータグループで max_allowed_packet パラメータに同じ値を使用します。

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

  • リードレプリカのテーブルに書き込んでいる。場合によっては、リードレプリカにソースの DB インスタンスのインデックスとは異なるインデックスを作成することがあります。その場合は、read_only パラメータを 0 に設定してインデックスを作成してください。リードレプリカのテーブルに書き込む場合、リードレプリカとソースの DB インスタンスの互換性がなくなると、レプリケーションが中断する可能性があります。リードレプリカのメンテナンスタスクを実行したら、read_only パラメータは 1 に戻すことをお勧めします。

  • MyISAM などの非トランザクションストレージエンジンを使用している。リードレプリカにはトランザクションストレージエンジンが必要です。レプリケーションは、MySQL 上の InnoDB ストレージエンジンでのみサポートされます。

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

エラーを安全にスキップできると判断した場合、「現在のレプリケーションエラーのスキップ」セクションで説明されているステップに従うことができます。そうでない場合は、まずリードレプリカを削除します。その上で、同じ DB インスタンス識別子を使用してインスタンスを作成することで、エンドポイントを前のリードレプリカと同じままにすることができます。レプリケーションエラーが解決すると、[Replication State] は [レプリケーション中] に変化します。