TiDBデータ移行のパフォーマンス問題への対処
このドキュメントでは、DM に存在する可能性のある一般的なパフォーマンスの問題とその対処方法について説明します。
問題を診断する前に、 DMベンチマークレポートを参照してください。
パフォーマンスの問題を診断して処理するときは、次の点を確認してください。
- DM 監視コンポーネントが正しく構成およびインストールされています。
- Grafana 監視ダッシュボードで監視メトリック表示できます。
- 診断するコンポーネントは正常に動作しています。そうでない場合、監視メトリックの例外が発生する可能性があり、パフォーマンスの問題の診断に影響する可能性があります。
データ移行のレイテンシーが大きい場合、ボトルネックが DMコンポーネント内にあるか、TiDB クラスター内にあるかを素早く判断するには、まず下流にSQL文を書き込むのDML queue remain length確認します。
リレーログユニット
リレーログユニットのパフォーマンス問題を診断するには、監視メトリックbinlog file gap between master and relay確認します。このメトリックの詳細については、 リレーログの監視メトリクスを参照してください。このメトリックが長時間にわたって1より大きい場合、通常はパフォーマンス問題が発生していることを示します。このメトリックが0の場合、通常はパフォーマンス問題が発生していないことを示します。
binlog file gap between master and relayの値が 0 であるにもかかわらず、パフォーマンスに問題があると思われる場合は、 binlog pos確認してください。このメトリックのmaster relayよりも大幅に大きい場合は、パフォーマンスに問題がある可能性があります。その場合は、問題を診断し、適切に対処してください。
binlogデータを読み取る
read binlog event duration 、リレーログが上流データベース（MySQL/MariaDB）からbinlogを読み取る時間を表します。理想的には、このメトリックは DM ワーカーと MySQL/MariaDB インスタンス間のネットワークレイテンシーに近い値になります。
単一データセンター内でのデータ移行では、 binlogデータの読み取りはパフォーマンスのボトルネックにはなりません。値が
read binlog event durationに設定されている場合は、DM-workerとMySQL/MariaDB間のネットワーク接続を確認してください。地理的に分散された環境でのデータ移行では、DM ワーカーと MySQL/MariaDB を 1 つのデータ センターにデプロイし、TiDB クラスターをターゲット データ センターにデプロイするようにしてください。
アップストリーム データベースからbinlogデータを読み取るプロセスには、次のサブプロセスが含まれます。
- 上流のMySQL/MariaDBはbinlogデータをローカルで読み取り、ネットワーク経由で送信します。MySQL/MariaDBの負荷に例外が発生しない限り、このサブプロセスは通常ボトルネックにはなりません。
- binlogデータは、MySQL/MariaDBが配置されているマシンからDM-workerが配置されているマシンへネットワーク経由で転送されます。このサブプロセスがボトルネックになるかどうかは、主にDM-workerと上流のMySQL/MariaDB間のネットワーク接続に依存します。
- DM-workerはネットワークデータストリームからbinlogデータを読み取り、binlogイベントとして構築します。DM-workerの負荷に例外が発生しない限り、このサブプロセスは通常ボトルネックにはなりません。
注記：
read binlog event durationという値が大きい場合、上流の MySQL/MariaDB の負荷が低いことが原因として考えられます。これは、一定期間 DM にbinlogイベントを送信する必要がなく、リレーログユニットが待機状態にあることを意味します。そのため、この値には追加の待機時間が含まれています。
binlogデータのデコードと検証
DMのリレー処理ユニットは、binlogイベントをDMメモリに読み込んだ後、データをデコードして検証します。これは通常、パフォーマンスのボトルネックにはならないため、デフォルトでは監視ダッシュボードに関連するパフォーマンスメトリックは表示されません。このメトリックを表示する必要がある場合は、Grafanaで手動で監視項目を追加できます。この監視項目は、Prometheusのメトリックdm_relay_read_transform_durationに対応しています。
リレーログファイルを書き込む
binlogイベントをリレーログファイルに書き込む場合、関連するパフォーマンスメトリックはwrite relay log durationです。3 binlog event size大きすぎる場合は、この値はマイクロ秒単位にする必要があります。5 write relay log duration大きすぎる場合は、ディスクの書き込みパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。
負荷ユニット
ロードユニットの主な操作は、ローカルからSQLファイルデータを読み取り、下流に書き込むことです。関連するパフォーマンスメトリックはtransaction execution latencyです。この値が大きすぎる場合は、下流データベースの監視をチェックして、下流のパフォーマンスを確認してください。また、DMと下流データベース間のネットワークレイテンシーが大きいかどうかも確認する必要があります。
Binlogレプリケーションユニット
Binlogレプリケーションユニットのパフォーマンス問題を診断するには、 binlog file gap between master and syncer監視メトリックを確認できます。このメトリックの詳細については、 Binlogレプリケーションの監視メトリクス参照してください。
- このメトリックが長時間にわたって 1 より大きい場合、通常はパフォーマンスの問題があることを示します。
- このメトリックが 0 の場合、通常はパフォーマンスの問題がないことを示します。
binlog file gap between master and syncer長期間にわたって1より大きい場合は、 binlog file gap between relay and syncer確認して、レイテンシーが主にどのユニットに存在しているかを特定してください。この値が通常0の場合、レイテンシーはリレーログユニットに存在している可能性があります。その場合はリレーログユニットを参照して問題を解決してください。それ以外の場合は、引き続きBinlogレプリケーションユニットを確認してください。
binlogデータを読み取る
Binlogレプリケーションユニットは、設定に応じて、上流のMySQL/MariaDBからbinlogイベントを読み取るか、リレーログファイルから読み取るかを決定します。関連するパフォーマンスメトリックはread binlog event durationで、通常は数マイクロ秒から数十マイクロ秒の範囲です。
DM のBinlogレプリケーション処理ユニットがアップストリーム MySQL/MariaDB からbinlogイベントを読み取る場合、問題を特定して解決するには、「リレー ログ ユニット」セクションのbinlogデータを読み取る参照してください。
DMのBinlogレプリケーション処理ユニットがリレーログファイルからbinlogイベントを読み取る場合、
binlog event sizeが大きすぎない場合、read binlog event durationの値はマイクロ秒単位にする必要があります。5read binlog event duration大きすぎる場合は、ディスクの読み取りパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。
binlogイベント変換
Binlogレプリケーションユニットは、DMLを構築し、DDLを解析し、 binlogイベントデータからテーブルルーター変換を実行します。関連メトリックはtransform binlog event durationです。
実行時間は主に上流の書き込み操作によって影響を受けます。例えば、 INSERT INTO文を例に挙げると、1 個のVALUES変換するのにかかる時間は、大量のVALUES変換するのにかかる時間とは大きく異なります。処理時間は数十マイクロ秒から数百マイクロ秒の範囲に及ぶ可能性があります。しかし、通常、これがシステムのボトルネックとなることはありません。
下流にSQL文を書き込む
Binlogレプリケーション ユニットが変換された SQL ステートメントをダウンストリームに書き込む場合、関連するパフォーマンス メトリックはDML queue remain lengthとtransaction execution latencyなります。
DMはbinlogイベントからSQL文を構築した後、 worker-countキューを使用してこれらの文を下流に同時に書き込みます。ただし、監視エントリが過度に多くなりすぎないようにするため、DMは同時キューのIDに対して8法とする演算を実行します。つまり、すべての同時キューはq_0からq_7までの1つのアイテムに対応します。
DML queue remain length 、同時処理キューにおいて、消費されておらず、下流への書き込みが開始されていないDML文の数を示します。理想的には、各q_*に対応する曲線はほぼ同じです。そうでない場合、同時処理負荷が極端に不均衡であることを示します。
負荷が分散されていない場合は、移行対象のテーブルに主キーまたは一意キーがあるかどうかを確認してください。これらのキーが存在しない場合は、主キーまたは一意キーを追加してください。負荷が分散されていない状態でこれらのキーが存在する場合は、DMをv1.0.5以降にアップグレードしてください。
データ移行リンク全体に顕著なレイテンシーがない場合、対応する曲線
DML queue remain lengthはほぼ常に 0 になり、最大値はタスク構成ファイルの値batchを超えません。データ移行リンクに顕著なレイテンシーが見られ、各
q_*に対応するDML queue remain lengthの曲線がほぼ同じで、ほぼ常に0である場合、DMが上流からのデータの読み取り、変換、または同時書き込みを時間内に実行できていないことを意味します（ボトルネックはリレーログユニットにある可能性があります）。トラブルシューティングについては、このドキュメントの前のセクションを参照してください。
DML queue remain lengthに対応する曲線が0でない場合（通常、最大値は1024以下）、下流へのSQL文の書き込み時にボトルネックが発生していることを示します。3 transaction execution latency使用すると、下流への単一トランザクションの実行に要した時間を表示できます。
transaction execution latencyは通常数十ミリ秒です。この値が大きすぎる場合は、下流データベースの監視に基づいて下流のパフォーマンスを確認してください。また、DMと下流データベース間のネットワークレイテンシーが大きくないか確認することもできます。
BEGIN 、 INSERT 、 UPDATE 、 DELETE 、 COMMITなどの単一のステートメントをダウンストリームに書き込むのに費やされた時間を表示するには、 statement execution latencyもチェックできます。