このトピックでは、増分データタスクのレイテンシの一般的な原因について説明し、関連するソリューションを提供します。 これらの原因に基づいて問題をトラブルシューティングし、ソリューションに基づいてタスクを再開できます。
発行
Data Transmission Service (DTS) が増分データ移行または同期を実行している場合、1,000ミリ秒を超えるレイテンシが発生します。
考えられる原因
原因1: インスタンスの仕様がビジネス要件を満たすことができず、増分タスクのデータ量が制限を超えています。 DTSのデータ移行インスタンスまたはデータ同期インスタンスには、1秒あたりのレコード数 (RPS) に制限があります。 DTSが増分移行または同期タスクを実行するときに、ソースデータベースに書き込まれるデータ量がRPS制限に達すると、レイテンシが発生します。 たとえば、ソースデータベースには大きなトランザクションが存在します。
DTSコンソールで、タスクに関連するデータボリュームを表示するか、[クイック診断] をクリックして、現在のデータ移行または同期インスタンスのRPS制限に達しているかどうかを確認できます。 詳細については、「タスクのパフォーマンスの監視」、「データ同期インスタンスの仕様」、および「データ移行インスタンスの仕様」をご参照ください。
原因2: ターゲットデータベースインスタンスの仕様がビジネス要件を満たすことができません。 ターゲットデータベースインスタンスの書き込みパフォーマンスがボトルネックになりました。
たとえば、ターゲットデータベースインスタンスがApsaraDB RDS For MySQLインスタンスの場合、ApsaraDB RDSコンソールのインスタンスの [モニタリングとアラート] ページで、インスタンスのCPU使用率、メモリ使用量、およびI/O負荷を表示できます。 インスタンスの制限に達しているかどうかを確認することもできます。 詳細については、「モニタリング情報の表示」および「標準プライマリApsaraDB RDS For MySQLインスタンス (オリジナルのx86アーキテクチャ) のインスタンスタイプ」をご参照ください。
原因3: パフォーマンスはホットスポットの更新によって影響を受けます。 主キーのないテーブルは、ホット行の更新を含む場合があります。 ソースデータベースの単一のテーブルまたは単一の行で頻繁に更新すると、ホットスポットが更新される可能性もあります。
たとえば、ソースデータベースインスタンスがApsaraDB RDS For MySQLインスタンスの場合、ApsaraDB RDSコンソールのインスタンスの [SQLエクスプローラーと監査] ページで、インスタンスで実行されたトランザクションを表示できます。 これにより、ホットスポットの更新が存在するかどうかを確認できます。 たとえば、トランザクションが一部のテーブルに集中しているかどうかを確認できます。 詳細については、「SQLエクスプローラーと監査機能の使用」をご参照ください。
原因4: ソースデータベースインスタンスの読み取りパフォーマンスがボトルネックになっているか、ソースデータベースインスタンスのネットワーク帯域幅が使い果たされています。
たとえば、ソースデータベースインスタンスがApsaraDB RDS For MySQLインスタンスの場合、ApsaraDB RDSコンソールのインスタンスの [モニタリングとアラート] ページでインスタンスのIOPSなどのメトリックを表示できます。 詳細については、「モニタリング情報の表示」および「標準プライマリApsaraDB RDS For MySQLインスタンス (オリジナルのx86アーキテクチャ) のインスタンスタイプ」をご参照ください。
原因5: DTSがターゲットデータベースに接続できない場合、またはDTSがターゲットデータベースにデータを書き込むときに例外が発生した場合、DTSは複数回再試行します。 その結果、データ同期中にレイテンシが発生します。 この場合、タスクのステータスが [再試行] であるかどうかを確認し、[トラブルシューティング] をクリックしてDTSコンソールで原因を確認し、問題を修正できます。
たとえば、ターゲットデータベースインスタンスがAnalyticDB For MySQLインスタンスであり、フィールドタイプを変更するためにソースデータベースでDDL操作が実行される場合、データ同期中にレイテンシが発生し、タスクは [再試行] 状態になります。 これは、ターゲットAnalyticDB for MySQLインスタンスがフィールドタイプの変更をサポートしていないためです。 ただし、DTSはAnalyticDB for MySQLインスタンスでDDL操作を複数回再試行し、実行は常に失敗します。 その結果、データ同期中にレイテンシが発生します。
原因6: ターゲットデータベースにトリガーが含まれているため、レイテンシが高くなります。
たとえば、次のステートメントを実行して、MySQLデータベースにトリガーが含まれているかどうかを確認できます。
select * from information_schema.triggers where trigger_schema='<データベース名>';原因7: ターゲットデータベースに同期されるテーブルに複雑なスキーマがあります。 たとえば、テーブルには主キーと一意キーの両方があります。 この場合、DTS以外のシステムが宛先データベースにデータを書き込むと、テーブルがロックされ、低速のSQLクエリが発生する可能性があります。
原因8: ソースデータベースで多数のDDL操作が実行されます。
たとえば、ソースデータベースインスタンスがApsaraDB RDS For MySQLインスタンスの場合、ApsaraDB RDSコンソールのインスタンスの [SQL Explorerおよび監査] ページで、インスタンス内のDDLステートメントの実行ステータスを表示できます。 これにより、インスタンスに対して多数のDDL操作が実行されているかどうかを確認できます。 詳細については、「SQLエクスプローラーと監査機能の使用」をご参照ください。
原因9: ネットワーク遅延は長距離伝送によって発生します。
DTSコンソールの [データ移行] ページと [データ同期] ページで、ソースデータベースインスタンスとターゲットデータベースインスタンスが存在するリージョンを表示できます。
原因10: ソースデータベースとターゲットデータベースのテーブルのスキーマが異なります。
原因11: DTSコンソールの2つの連続したデータ更新の間にレイテンシが存在します。
解決策
解決策1: データ移行インスタンスまたはデータ同期インスタンスの仕様をアップグレードして、パフォーマンスを向上させます。 詳細については、「DTSインスタンスのアップグレード」をご参照ください。
解決策2: ターゲットデータベースインスタンスの仕様をアップグレードして、書き込みパフォーマンスを向上させます。
ApsaraDB RDS For MySQLインスタンスの仕様をアップグレードする方法の詳細については、「インスタンス仕様の変更」をご参照ください。 ターゲットデータベースインスタンスの仕様をアップグレードするには、このトピックを参照してください。
解決策3: ホット行が更新されている場合は、更新が完了するまで待ちます。 ビジネス上の考慮事項については、ホットスポットの更新を実行しないことを推奨します。
解決策4: ソースデータベースインスタンスの仕様またはネットワーク帯域幅をアップグレードします。
ApsaraDB RDS For MySQLインスタンスの仕様をアップグレードする方法の詳細については、「インスタンス仕様の変更」をご参照ください。 ターゲットデータベースインスタンスの仕様をアップグレードするには、このトピックを参照してください。
解決策5: DTSコンソールで特定のエラーメッセージを表示し、それに応じてエラーを修正します。
この例では、DTSはターゲットAnalyticDB for MySQLインスタンスでDDL操作を複数回実行できません。 その結果、データ同期中にレイテンシが発生し、タスクは再試行状態になります。 データ同期タスクを再開するには、次の手順を実行します。同期するオブジェクトからDDL操作が実行されるテーブルを削除します。 同期レイテンシが0ミリ秒になるまで待ちます。 対応するテーブルをターゲットデータベースから削除します。 次に、同期するオブジェクトにテーブルを追加します。 詳細については、「データ同期に関するFAQ」および「同期するオブジェクトの変更」をご参照ください。
解決策6: ターゲットデータベースのトリガーを削除または無効にすることを推奨します。
たとえば、
DROP TRIGGER [ IF EXISTS ] [Database name] <Trigger name>;ステートメントを実行して、MySQLデータベースからトリガーを削除できます。説明ソースデータベースにトリガーが含まれている場合のDTSタスクの設定方法の詳細については、「トリガーを含むソースデータベースのデータ同期タスクの設定」をご参照ください。
解決策7: ロックステータス、低速SQLクエリ、およびターゲットデータベースのスキーマを確認します。 ターゲットデータベースの書き込み設定またはスキーマを変更して、書き込みロックや低速SQLクエリを削除します。
たとえば、ターゲットデータベースがMySQLデータベースの場合、次の方法を使用して問題をトラブルシューティングできます。
ロックステータスおよび低速SQLクエリ:
SHOW PROCESSLIST;ステートメントを実行して、ロックされたテーブルまたは低速SQLプロセスを表示します。 次に、KILL [CONNECTION | QUERY]thread_idステートメントを実行して、プロセスを削除します。スキーマ:
show create table <Database name>.<Table name>;ステートメントを実行して、指定されたテーブルのスキーマを表示します。 たとえば、テーブルに一意のキーがある場合、一意のキーが必要かどうかを評価します。 一意のキーが必要でない場合は、宛先データベースでalter table <Database name>.<Table name> drop index <unique key name>;ステートメントを実行して、一意のキーを削除します。
解決策8: DTSタスクが実行されている場合は、ソースデータベースに対して一度に複数のDDL操作を実行しないことをお勧めします。 DDL操作を実行する必要がある場合は、オフピーク時に操作を実行することを推奨します。
説明タスクを設定するときは、同期する必要があるDDL操作のみを選択することをお勧めします。
解決策9: 長距離伝送によるネットワーク待ち時間を回避できない。 Express connectを介してソースデータベースインスタンスとターゲットデータベースインスタンスを接続して、遅延を短縮できます。
解決策10: ビジネス要件に基づいて、ソースデータベースまたはターゲットデータベースのテーブルのスキーマを変更して、ソースデータベースとターゲットデータベースのテーブルのスキーマが一貫していることを確認します。
解決策11: 数分待ってからページを更新します。
関連ドキュメント
フルデータタスクの速度が低下する問題のトラブルシューティング方法の詳細については、完全なデータタスクが停止または速度低下した場合はどうすればよいですか?