このトピックでは、プライマリApsaraDB RDS for MySQLインスタンスと読み取り専用RDSインスタンス間のデータレプリケーション中のレイテンシの原因と解決策について説明します。
問題の説明
読み取り専用RDSインスタンスは、MySQLのネイティブログベースの非同期または半非同期レプリケーションメカニズムを使用して、プライマリRDSインスタンスからデータを同期します。 このメカニズムは、複製待ち時間を引き起こす。 レプリケーションの待ち時間は、読み取り専用RDSインスタンスとプライマリRDSインスタンスの間でデータの不整合を引き起こし、ワークロードに影響を与えます。 また、複製待ち時間は、ログの蓄積を引き起こす可能性がある。 その結果、蓄積されたログは、読み取り専用RDSインスタンスのストレージ容量をすぐに使い果たします。
プライマリRDSインスタンスに対して多数のログが生成されている場合、読み取り専用RDSインスタンスがロックされる可能性があります。
SHOW SLAVE STATUS \Gステートメントの出力にあるsecond_behind_masterパラメーターは、ログベースのレプリケーションのレイテンシを示します。レイテンシの計算: レイテンシ=現在の時刻-セカンダリRDSインスタンスに適用されているトランザクションがプライマリRDSインスタンスでコミットされた時点。 現在の時刻は、
SHOW SLAVE STATUS \Gステートメントを実行した時点を示します。
レプリケーションのレイテンシは、レイテンシの期間に基づいて次のタイプに分類できます。
1秒以下のレイテンシ。 このタイプのレイテンシは、計算精度、計算方法、サンプリングポイント、およびモニタリング粒度によって発生します。 このタイプのレイテンシが発生した場合、データレプリケーションは通常どおり実行され、問題は無視できます。
1秒より大きいレイテンシ。 このタイプのレイテンシは、次のシナリオで発生します。読み取り専用RDSインスタンスの仕様が低く、プライマリRDSインスタンスの1秒あたりのトランザクション (TPS) が大きく、プライマリRDSインスタンスに大きなトランザクションが存在し、プライマリRDSインスタンスのDDLステートメントが長期間実行されます。 このタイプのレイテンシが発生した場合は、原因を特定して問題を解決する必要があります。
原因
レイテンシが1秒以下の原因
レイテンシが1秒未満: 監視時間範囲が大きい値に設定されています。 このタイプの実際のレイテンシは発生せず、問題は無視できます。
指定されたモニタリング時間範囲が長期間をカバーする場合、モニタリングの粒度は大きくなります。 例えば、モニタリング時間範囲が3時間である場合、デフォルトのモニタリング粒度は30秒までであってもよい。 毎回算出されるデータは、30秒間の平均値であり、1秒未満のレイテンシが報告されてもよい。 ただし、計算されるレイテンシの最小粒度は1秒です。
より正確なレイテンシを取得するには、ApsaraDB RDSコンソールにログインし、[パフォーマンストレンド] タブに移動して、モニタリング時間範囲を6分未満の値に設定します。 これにより、1秒のモニタリング粒度でレイテンシを表示できます。 詳細については、「ApsaraDB RDS For MySQLインスタンスのダッシュボード機能の使用」をご参照ください。
レイテンシ1秒: このタイプのレイテンシは、計算精度、計算方法、サンプリングポイント、およびクロス秒トランザクションによって発生します。 このタイプの実際のレイテンシは発生せず、問題は無視できます。
ApsaraDB RDS for MySQLでは、サンプリングポイントは常に1秒単位に切り捨てられます。 たとえば、00:00:00.95のサンプリングポイントは00:00:00のサンプリングポイントと見なされ、00:00:01.05のサンプリングポイントは00:00:01のサンプリングポイントと見なされます。 たとえば、サンプリングポイントが次の秒に交差する場合、実際のレイテンシが1秒未満であるかどうかにかかわらず、レイテンシは1秒として計算されます。 これは、以下の表の行4に示されている。
取引
プライマリRDSインスタンスのコミット時間
セカンダリRDSインスタンスのコミット時間
現在時刻
レイテンシ正確な秒
Trx1
00:00:00.30
00:00:00.50
00:00:00.35
0(0.35) - 0(0.3) = 0
00:00:00.45
0(0.45) - 0(0.3) = 0
Trx2
00:00:00.90
00:00:01.10
00:00:00.95
0(0.95) - 0(0.9) = 0
00:00:01.05
1(1.05) - 0(0.9) = 1
データは1秒の間隔で収集され、各サンプリングポイントは次の秒に渡ります。 ワークロードが重いか、または秒を超えるトランザクションが存在する場合、各サンプリングポイントで1秒のレイテンシが取得され得る。 サンプリングポイントが次の秒 (00:00:00.95など) に交差しない場合、前の表の行3に示すように、0秒のレイテンシが取得されます。
レイテンシが1秒を超える原因
このタイプのレイテンシは、次の原因で発生する可能性があります。
原因1: 読み取り専用RDSインスタンスの仕様が低い
読み取り専用RDSインスタンスの仕様はプライマリRDSインスタンスの仕様よりも低く、読み取り専用RDSインスタンスのワークロードは重いです。 たとえば、読み取り専用RDSインスタンスのIOPSが高いとします。 データの整合性のために、読み取り専用RDSインスタンスはMySQLのネイティブログベースのレプリケーションメカニズムを使用して、プライマリRDSインスタンスからのデータを同期します。 このメカニズムは、I/OスレッドおよびSQLスレッドを起動する。 I/OスレッドはプライマリRDSインスタンスからログを読み取り、SQLスレッドはログを読み取り専用RDSインスタンスに適用します。 どちらのスレッドも、読み取り専用RDSインスタンスのI/Oリソースを消費します。 読み取り専用RDSインスタンスが適切なIOPSを維持するのに十分なリソースを提供できない場合、読み取り専用RDSインスタンスとプライマリRDSインスタンスの間でデータ同期レイテンシが発生します。 ApsaraDB RDSコンソールにログインし、[モニタリングとアラート] ページでIOPSを表示できます。
原因2: プライマリRDSインスタンスのTPSが高い
読み取り専用RDSインスタンスは、スレッドを使用してプライマリRDSインスタンスからのデータを同期します。 プライマリRDSインスタンスが同時マルチスレッド書き込みを処理し、プライマリRDSインスタンスのTPSが大幅に高い場合、読み取り専用RDSインスタンスとプライマリRDSインスタンスの間でデータ同期レイテンシが発生します。
原因3: 大規模なトランザクション
大量のデータに対してUPDATE、DELETE、INSERT...SELECT、REPLACE...SELECTなどの操作を実行するトランザクションは、プライマリRDSインスタンスで実行されます。 大量のログデータが生成され、読み取り専用RDSインスタンスに送信する必要があります。 読み取り専用RDSインスタンスは、トランザクションを完了するためにプライマリRDSインスタンスと同じ期間を必要とします。 これは、データ同期待ち時間を引き起こす。 たとえば、プライマリRDSインスタンスで80秒間続く削除操作を実行する場合、読み取り専用RDSインスタンスが同じ操作を完了するまでにも80秒かかります。 その結果、データ同期レイテンシが発生する。
複数のテーブルでの同時トランザクションがサポートされています。 ただし、テーブル上のトランザクションをレプリケートするために使用できるスレッドは1つだけです。 これは、複製期間を延長する。
原因4: プライマリRDSインスタンスで長期間実行されたDDLステートメント
読み取り専用RDSインスタンスとそのプライマリRDSインスタンス間のデータ同期は、順番に実行されます。 大きなテーブルでDDLステートメントが長期間実行された場合、またはプライマリRDSインスタンスで多数のスロークエリが実行された場合、多数の一時テーブルが生成されます。 これにより、ストレージが不足し、ディスクI/Oが増加し、レイテンシが発生します。 一般的なDDLステートメントには、CREATE INDEX、REPAIR TABLE、およびALTER TABLE ADD COLUMNが含まれます。
読み取り専用RDSインスタンスで実行されるクエリまたは進行中のトランザクションは、プライマリRDSインスタンスから同期されるDDLステートメントをブロックします。
原因5: 特別なケース
データをレプリケートするために実行されるSQL文には、適切なインデックスがありません。 その結果、多数のフルテーブルスキャンが実行され、論理読み取りの数が大幅に増加します。
テーブルにNULL値を持つ一意のインデックスのみがあり、プライマリキーがない場合、セカンダリRDSインスタンスがデータを複製するときに、オプティマイザによって選択された実行プランではなく、一意のインデックスの実行プランが優先的に使用されます。 これは、WHERE句を使用してクエリ条件を指定する場合でも適用されます。
識別方法
レイテンシが1秒以下の場合は、問題を無視できます。 ここでは、レイテンシが1秒を超える原因を特定する方法について説明します。
原因1の特定方法
ApsaraDB RDSコンソールの読み取り専用RDSインスタンスの [基本情報] ページの [設定情報] セクションで、読み取り専用RDSインスタンスのインスタンスタイプを表示します。 詳細については、「読み取り専用ApsaraDB RDS For MySQLインスタンス (x86) のインスタンスタイプ」および「読み取り専用ApsaraDB RDS for MySQLインスタンス (ARM) のインスタンスタイプ」をご参照ください。
ApsaraDB RDSコンソールの読み取り専用RDSインスタンスの [モニタリングとアラート] ページで、CPU使用率、メモリ使用量、I/O帯域幅、接続数などのモニタリング情報を表示します。 次に、モニタリング情報に基づいて、読み取り専用RDSインスタンスにリソースのボトルネックが存在するかどうかを確認します。
原因2の識別方法
RDSインスタンスのダッシュボードページで、プライマリまたは読み取り専用RDSインスタンスのTPSを表示します。 詳細については、「ApsaraDB RDS For MySQLインスタンスのダッシュボード機能の使用」をご参照ください。
原因3の識別方法
RDSインスタンスにログインし、
SHOW SLAVE STATUS \Gステートメントを実行して、Seconds_Behind_Masterパラメーターの値が継続的に変更されているかどうかを確認します。 この場合、読み取り専用RDSインスタンスのSQLスレッドは、大規模なトランザクションまたはDDL操作を実行しています。 次の図のような出力が表示されます。
次に、
SHOW PROCESSLISTステートメントを実行して、特定のスレッドを識別します。読み取り専用RDSインスタンスで
SHOW SLAVE STATUS \Gステートメントを実行して、メタデータロック (MDL) が存在するかどうかを確認します。バイナリログ形式がROWに設定されている場合、大きなトランザクションは大きなバイナリログファイルになります。
SHOW BINARY LOGS;ステートメントを実行して、File_sizeパラメーターの値を表示できます。 値がmax_binlog_sizeパラメーターの値より大きい場合、大きなトランザクションが存在します。
原因4の識別方法
読み取り専用RDSインスタンスのバイナリログの量を確認して、DDL操作が存在するかどうかを確認します。 バイナリログファイルが適時に切り捨てられない場合、大きなバイナリログファイルが生成されます。
プライマリキーを含まないテーブルが、読み取り専用RDSインスタンスで削除または更新されているかどうかを確認します。 出力結果を表示するには、読み取り専用RDSインスタンスで
SHOW ENGINE INNODB STATUS \Gステートメントを実行します。SHOW OPEN TABLES;ステートメントを実行して、in_use列の値が1であるテーブルを表示することもできます。低速クエリログに関する情報を表示して、OPTIMIZE、ALTER、REPAIR、CREATEなどのDDL操作が存在するかどうかを確認します。 詳細については、「スロークエリログ分析」をご参照ください。
原因5の識別方法 (NULL値を持つ一意のキー)
sys.schema_index_statisticsビューを使用して、テーブルにプライマリキーがなく、一意のインデックスのみがあるかどうかを確認します。
一意のインデックスにNULL値が含まれているかどうかを確認します。
解決策
インスタンスの設定やデータの変更など、リスクの高い操作を実行する前に、インスタンスのディザスタリカバリ機能とフォールトトレランス機能を確認して、データのセキュリティを確保することを推奨します。
ECS (Elastic Compute Service) インスタンスやRDSインスタンスなどのインスタンスの設定またはデータを変更する前に、インスタンスのスナップショットを作成するか、バックアップを有効にすることを推奨します。 たとえば、RDSインスタンスのログバックアップを有効にできます。
Alibaba Cloud管理コンソールで機密情報または送信された機密情報に対する権限を付与した場合は、できるだけ早い機会に機密情報を変更することを推奨します。 機密情報には、ユーザー名とパスワードが含まれます。
このセクションでは、一般的な処理方法について説明します。 特定された原因に基づいて、次のいずれかの方法を使用できます。
原因1の処理方法
読み取り専用RDSインスタンスの仕様をアップグレードし、読み取り専用RDSインスタンスの仕様がプライマリRDSインスタンスの仕様以上であることを確認することを推奨します。 これにより、読み取り専用RDSインスタンスの仕様が小さいために発生するレプリケーション遅延が防止されます。 詳細については、「ApsaraDB RDS For MySQLインスタンスの仕様の変更」をご参照ください。
原因2の処理方法
プライマリRDSインスタンスのTPSが高い場合は、トランザクションを最適化または分割します。
原因3の処理方法
大きなトランザクションを小さなトランザクションに分割します。 たとえば、DELETEステートメントにWHERE句を追加して、一度に削除できるデータの量を制限し、削除操作をより小さな操作に分割できます。 これにより、読み取り専用RDSインスタンスは、遅延なしで大規模なトランザクションを迅速に完了できます。
原因4の処理方法
読み取り専用RDSインスタンスのデータ同期遅延がDDL操作に起因する場合は、オフピーク時にDDL操作を実行することを推奨します。 次のいずれかの方法を使用できます。
サービスサポート: 自動ストレージ拡張機能を有効にします。 手動ストレージ拡張をトリガーするためのしきい値を90% に設定することもできます。 詳細については、「ApsaraDB RDSインスタンスのスケーリング方法」をご参照ください。
SQL最適化: SQL Explorerを有効にして、SQL文のパフォーマンスを定期的に確認します。 詳細については、「ApsaraDB RDS For MySQLインスタンスでのSQLエクスプローラーと監査機能の使用」をご参照ください。
ロード: ディスク使用量のアラートルールを設定するか、 仕様を手動でアップグレードします。 詳細については、「ApsaraDB RDS For MySQLインスタンスの仕様の変更」をご参照ください。
プライマリRDSインスタンスから同期されるDDL操作が読み取り専用RDSインスタンスでブロックされている場合は、次の手順を実行します。
読み取り専用RDSインスタンスで
SHOW PROCESSLIST;ステートメントを実行して、ステータスがテーブルメタデータロックを待機しているSQLスレッドを特定します。killコマンドを実行して、読み取り専用RDSインスタンスのブロックが読み取り専用RDSインスタンスとそのプライマリRDSインスタンス間のデータ同期を再開する原因となったセッションを終了します。 詳細については、「DMSを使用したメタデータロックの解放」をご参照ください。
原因5の処理方法
プライマリキーがないテーブルに明示的なプライマリキーを追加します。
よくある質問
一部の読み取り専用RDSインスタンスで1秒のレイテンシが発生するのはなぜですか。
読み取り専用RDSインスタンスの収集手順と起動時間は互いに異なります。 一部の読み取り専用RDSインスタンスのサンプリングポイントが次の秒に交差すると、1秒のレイテンシが発生します。 一部の読み取り専用RDSインスタンスのサンプリングポイントが次の秒に交差しない場合、1秒のレイテンシは発生しません。 詳細については、「レイテンシが1秒以下の原因」をご参照ください。
RDSインスタンスで1秒のレイテンシが発生した場合、RDSインスタンスは影響を受けますか?
いいえ、RDSインスタンスは影響を受けません。 1秒のレイテンシは、RDSインスタンスで実際のレイテンシが発生したことを示すものではありません。 たとえば、実際のレイテンシが0.1秒であるが、サンプリングポイントが次の秒に交差する場合、1秒のレイテンシが報告されます。 この場合、1秒のレイテンシは、計算精度、計算方法、サンプリングポイントに起因します。 詳細については、「レイテンシが1秒以下の原因」をご参照ください。
プロキシの読み取り遅延しきい値を指定するか、ビジネス要件に基づいてアラートをトリガーすることを推奨します。 指定したしきい値が1秒より大きいことを確認してください。
ReplicationInterruptedエラーメッセージが表示された場合、または読み取り専用RDSインスタンスに対してSlave_SQL_RunningまたはSlave_IO_Runningアラートが報告された場合はどうすればよいですか。
エラーの原因を特定する必要があります。
読み取り専用RDSインスタンスのストレージ容量が十分かどうかを確認します。
ストレージ容量が不十分な場合、読み取り専用RDSインスタンスはプライマリRDSインスタンスのバイナリログを同期できません。
説明基本情報 ページの 使用状況 セクションで、読み取り専用RDSインスタンスのストレージ使用状況を確認できます。
レプリケーションの待ち時間を確認します。
レプリケーションのレイテンシが5分以内に5秒を連続して超えると、読み取り専用RDSインスタンスのレイテンシが高くなり、アラートがトリガーされます。 データが頻繁にプライマリRDSインスタンスに書き込まれるか、大規模なトランザクションがプライマリRDSインスタンスに存在する場合、データレプリケーションが中断される可能性があります。
説明読み取り専用RDSインスタンスの 基本情報 ページに移動します。 ページの左側のナビゲーションウィンドウで、モニターとアラーム をクリックします。 [標準モニタリング] タブで、[セカンダリインスタンスのレプリケーション遅延時間 (秒)] メトリックの値を表示します。
遅いクエリログを確認します。
低速クエリログはインスタンスのパフォーマンスに大きく影響し、レプリケーションの遅延が増加する可能性があります。
説明次のいずれかの方法を使用して、読み取り専用RDSインスタンスの 基本情報 ページで低速クエリログを確認できます。
左側のナビゲーションウィンドウで、ログ管理 をクリックします。 次に、Slow Log の情報タブでスロークエリログを確認します。
左側のナビゲーションウィンドウで、自律型サービス (CloudDBA) > 低速 SQL を選択して、スロークエリログを確認します。
上記の原因によってレプリケーションの中断が発生していない場合は、エラーを無視できます。 システムは自動的にインスタンスをチェックし、レプリケーション中断の問題を解決します。