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 インスタンス間のネットワークレイテンシーに近くなります。
1 つのデータセンターでのデータ移行の場合、 binlogデータの読み取りはパフォーマンスのボトルネックにはなりません。1
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 の負荷が低いことが考えられます。これは、一定期間、binlogイベントを DM に送信する必要がなく、リレー ログ ユニットが待機状態にあることを意味し、この値には追加の待機時間が含まれます。
binlogデータのデコードと検証
binlogイベントを DMメモリに読み込んだ後、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ステートメントを例にとると、単一の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もチェックできます。