ApsaraDB RDS:読み取り専用 ApsaraDB RDS for MySQL インスタンスがプライマリインスタンスからデータを同期する際に遅延が発生した場合の対処方法

読み取り専用 RDS インスタンスは、MySQL のネイティブなログベースの非同期または準同期レプリケーションメカニズムを使用して、プライマリ RDS インスタンスからデータを同期します。このメカニズムにより、レプリケーション遅延が発生します。レプリケーション遅延は、読み取り専用 RDS インスタンスとプライマリ RDS インスタンス間のデータ不整合を引き起こし、ワークロードに影響を与えます。レプリケーション遅延は、ログの蓄積を引き起こす可能性もあります。その結果、蓄積されたログが読み取り専用 RDS インスタンスのストレージ容量を急速に使い果たしてしまいます。

レプリケーション遅延は、遅延の期間に基づいて次のタイプに分類できます。

• 1 秒以下の遅延。このタイプの遅延は、計算精度、計算方法、サンプリングポイント、および監視の粒度によって引き起こされます。このタイプの遅延が発生した場合、データレプリケーションは正常に実行されており、問題を無視できます。

• 1 秒を超える遅延。このタイプの遅延は、読み取り専用 RDS インスタンスの仕様が低い、プライマリ RDS インスタンスの 1 秒あたりのトランザクション数 (TPS) が大きい、プライマリ RDS インスタンスに大規模なトランザクションが存在する、プライマリ RDS インスタンスで DDL 文が長時間実行されるなどのシナリオで発生します。このタイプの遅延が発生した場合は、原因を特定して問題を解決する必要があります。

1 秒以下の遅延の原因

1 秒を超える遅延の原因

遅延が 1 秒以下の場合は、問題を無視できます。このセクションでは、1 秒を超える遅延の原因を特定する方法について説明します。

• 読み取り専用インスタンスの仕様が小さすぎる

  • ApsaraDB RDS コンソールの読み取り専用 RDS インスタンスの [基本情報] ページの [設定情報] セクションで、読み取り専用 RDS インスタンスのインスタンスタイプを表示します。詳細については、「標準読み取り専用 ApsaraDB RDS for MySQL インスタンスのインスタンスタイプ (元の x86 アーキテクチャ)」および「YiTian 読み取り専用 ApsaraDB RDS for MySQL インスタンスのインスタンスタイプ (元の ARM アーキテクチャ)」をご参照ください。

  • ApsaraDB RDS コンソールの読み取り専用 RDS インスタンスの [監視とアラート] ページで、CPU 使用率、メモリ使用量、I/O 帯域幅、接続数などの監視情報を表示します。次に、監視情報に基づいて、読み取り専用 RDS インスタンスにリソースのボトルネックが存在するかどうかを確認します。

• プライマリインスタンスの 1 秒あたりのトランザクション数 (TPS) が高すぎる。

  RDS インスタンスの [ダッシュボード] ページで、プライマリまたは読み取り専用 RDS インスタンスの TPS を表示します。詳細については、「ApsaraDB RDS for MySQL インスタンスのダッシュボード機能を使用する」をご参照ください。

• 大規模なトランザクションの書き込み

  • 大規模なトランザクションが読み取り専用インスタンスに同期され、遅延が発生した場合、データベースにログインして show slave status \G SQL 文を実行します。`Exec_Master_Log_Pos` パラメーターの値が変更されないままで `Seconds_Behind_Master` パラメーターの値が継続的に変更される場合、読み取り専用インスタンスの SQL スレッドが大規模なトランザクションまたは DDL 操作を実行していることを示します。次のような出力が表示されます:

    最後に、show processlist; 文を実行して、特定のスレッドを特定します。

  • 読み取り専用インスタンスで show slave status \G 文を実行して、メタデータロックが存在するかどうかを判断します。

  • バイナリログのフォーマットが ROW に設定されている場合、大規模なトランザクションは大きなバイナリログファイルになります。SHOW BINARY LOGS; コマンドを実行して、File_size の値を確認できます。値が `max_binlog_size` パラメーターの値より大きい場合、大規模なトランザクションが存在します。

• プライマリインスタンスでの DDL 文の実行時間が長い。

  • 読み取り専用 RDS インスタンスのバイナリログのボリュームをチェックして、DDL 操作が存在するかどうかを判断します。バイナリログファイルがタイムリーに切り捨てられない場合、大きなバイナリログファイルが生成されます。

  • 読み取り専用インスタンスでプライマリキーのないテーブルが削除または更新されているかどうかを確認します。show engine innodb status \G 文を実行して確認するか、show open tables; 文を実行し、[in_use] 列の値が 1 であるテーブルの出力を確認します。

  • スロークエリログの情報を表示して、OPTIMIZE、ALTER、REPAIR、CREATE などの DDL 操作が存在するかどうかを確認します。詳細については、「スロークエリログ分析」をご参照ください。

• 原因 5 の特定方法 (NULL 値を持つ一意なキー)

  1. sys.schema_index_statistics ビューを使用して、テーブルにプライマリキーがなく、一意なインデックスしかないかどうかを確認します。

  2. 一意なインデックスに NULL 値が含まれているかどうかを確認します。

このセクションでは、一般的な対処方法について説明します。特定された原因に基づいて、次のいずれかの方法を使用できます。

• 読み取り専用インスタンスの仕様が小さすぎる

  読み取り専用 RDS インスタンスの仕様をアップグレードし、読み取り専用 RDS インスタンスの仕様がプライマリ RDS インスタンスの仕様以上であることを確認することをお勧めします。これにより、読み取り専用 RDS インスタンスの仕様が小さいことによって引き起こされるレプリケーション遅延を防ぎます。詳細については、「ApsaraDB RDS for MySQL インスタンスの仕様を変更する」をご参照ください。

• プライマリインスタンスの TPS (1 秒あたりのトランザクション数) が高すぎる。

  プライマリ RDS インスタンスの TPS が高い場合は、トランザクションを最適化または分割します。

• 大規模なトランザクションの書き込み

  大規模なトランザクションをより小さなトランザクションに分割します。たとえば、DELETE 文に WHERE 句を追加して、一度に削除できるデータの量を制限し、削除操作をより小さな操作に分割できます。これにより、読み取り専用 RDS インスタンスは遅延なく大規模なトランザクションを迅速に完了できます。

• プライマリインスタンスでの DDL 文の実行時間が長すぎる。

  • 読み取り専用 RDS インスタンスのデータ同期遅延が DDL 操作によって引き起こされる場合は、オフピーク時に DDL 操作を実行することをお勧めします。次のいずれかの方法を使用できます。

    • サービスサポート: 自動ストレージ拡張機能を有効にします。手動ストレージ拡張をトリガーするしきい値を 90% に設定することもできます。詳細については、「ApsaraDB RDS インスタンスをスケーリングする方法」をご参照ください。

    • SQL 最適化: SQL Explorer を有効にして、SQL 文のパフォーマンスを定期的に確認します。詳細については、「ApsaraDB RDS for MySQL インスタンスで SQL Explorer と監査機能を使用する」をご参照ください。

    • 負荷: ディスク使用率のアラートルールを設定するか、自動ストレージ拡張を設定するか、手動で仕様をアップグレードします。

  • プライマリ RDS インスタンスから同期された DDL 操作が読み取り専用 RDS インスタンスでブロックされている場合は、次の手順を実行します。

    1. 読み取り専用インスタンスで show processlist; 文を実行し、SQL スレッドのステータスが 'waiting for table metadata lock' であることを確認します。

    2. kill コマンドを実行して、読み取り専用 RDS インスタンスでブロックを引き起こしたセッションを終了させ、読み取り専用 RDS インスタンスとそのプライマリ RDS インスタンス間のデータ同期を再開します。詳細については、「DMS を使用してメタデータロックを解放する」をご参照ください。

• 特殊なケース

  プライマリキーのないテーブルに明示的なプライマリキーを追加します。