sync-diff-inspector ユーザーガイド
同期差分インスペクターは、データベースに保存されているデータを MySQL プロトコルと比較するために使用されるツールです。たとえば、MySQL のデータと TiDB のデータ、MySQL のデータと MySQL のデータ、TiDB のデータと TiDB のデータを比較できます。さらに、このツールを使用して、少量のデータに一貫性がないシナリオでデータを修復することもできます。
このガイドでは、sync-diff-inspector の主な機能を紹介し、このツールを構成して使用する方法について説明します。 sync-diff-inspector をダウンロードするには、次のいずれかの方法を使用します。
バイナリパッケージ。 sync-diff-inspector バイナリ パッケージはTiDB Toolkitに含まれています。 TiDB Toolkitをダウンロードするには、 TiDB ツールをダウンロードを参照してください。
Docker イメージ。次のコマンドを実行してダウンロードします。
docker pull pingcap/tidb-enterprise-tools:nightly
主な機能
- テーブル スキーマとデータを比較する
- データの不整合が存在する場合にデータを修復するために使用される SQL ステートメントを生成する
- サポートスキーマまたはテーブル名が異なるテーブルのデータ チェック
- サポートシャーディング シナリオでのデータ チェック
- サポートTiDB アップストリーム-ダウンストリーム クラスタのデータ チェック
- サポートDM レプリケーション シナリオでのデータ チェック
sync-diff-inspector の制限事項
MySQL と TiDB 間のデータ移行では、オンライン チェックはサポートされていません。上流下流チェックリストにデータが書き込まれていないこと、および特定の範囲のデータが変更されていないことを確認します。
range
を設定すると、この範囲のデータを確認できます。TiDB と MySQL では、
FLOAT
、DOUBLE
、およびその他の浮動小数点型の実装が異なります。FLOAT
とDOUBLE
は、チェックサムの計算にそれぞれ 6 桁と 15 桁の有効数字を使用します。この機能を使用しない場合は、ignore-columns
を設定してこれらの列のチェックをスキップします。主キーまたは一意のインデックスを含まないテーブルのチェックをサポートします。ただし、データに一貫性がない場合、生成された SQL ステートメントはデータを正しく修復できない可能性があります。
sync-diff-inspector のデータベース権限
sync-diff-inspector は、テーブル スキーマの情報を取得し、データをクエリする必要があります。必要なデータベース権限は次のとおりです。
- アップストリーム データベース
SELECT
(比較のためにデータをチェック)SHOW_DATABASES
(ビュー データベース名)RELOAD
(ビュー テーブル スキーマ)
- ダウンストリーム データベース
SELECT
(比較のためにデータをチェック)SHOW_DATABASES
(ビュー データベース名)RELOAD
(ビュー テーブル スキーマ)
Configuration / コンフィグレーションファイルの説明
sync-diff-inspector の構成は、次の部分で構成されます。
Global config
: チェックするスレッドの数、矛盾したテーブルを修正するために SQL ステートメントをエクスポートするかどうか、データをキャンプするかどうかなどの一般的な構成。Databases config
: アップストリーム データベースとダウンストリーム データベースのインスタンスを構成します。Routes
: アップストリームの複数のスキーマ名がダウンストリームの単一のスキーマ名と一致するためのルール(オプション) 。Task config
: チェック用のテーブルを構成します。アップストリーム データベースとダウンストリーム データベースの間に特定のマッピング関係があるテーブルや、特別な要件があるテーブルがある場合は、これらのテーブルを構成する必要があります。Table config
: 指定された範囲や列を無視するなど、特定のテーブルの特別な構成(オプション) 。
以下は、完全な構成ファイルの説明です。
- 注: 名前の後に
s
が付いている構成は複数の値を持つことができるため、角括弧[]
を使用して構成値を含める必要があります。
# Diff Configuration.
######################### Global config #########################
# The number of goroutines created to check data. The number of connections between sync-diff-inspector and upstream/downstream databases is slightly greater than this value.
check-thread-count = 4
# If enabled, SQL statements is exported to fix inconsistent tables.
export-fix-sql = true
# Only compares the table structure instead of the data.
check-struct-only = false
######################### Datasource config #########################
[data-sources]
[data-sources.mysql1] # mysql1 is the only custom ID for the database instance. It is used for the following `task.source-instances/task.target-instance` configuration.
host = "127.0.0.1"
port = 3306
user = "root"
password = ""
# (optional) Use mapping rules to match multiple upstream sharded tables. Rule1 and rule2 are configured in the following Routes section.
route-rules = ["rule1", "rule2"]
[data-sources.tidb0]
host = "127.0.0.1"
port = 4000
user = "root"
password = ""
# (optional) Use TLS to connect TiDB.
# security.ca-path = ".../ca.crt"
# security.cert-path = ".../cert.crt"
# security.key-path = ".../key.crt"
# (optional) Use the snapshot feature. If enabled, historical data is used for comparison.
# snapshot = "386902609362944000"
# When "snapshot" is set to "auto", the last syncpoints generated by TiCDC in the upstream and downstream are used for comparison. For details, see <https://github.com/pingcap/tidb-tools/issues/663>.
# snapshot = "auto"
########################### Routes ##############################
# To compare the data of a large number of tables with different schema names or table names, or check the data of multiple upstream sharded tables and downstream table family, use the table-rule to configure the mapping relationship. You can configure the mapping rule only for the schema or table. Also, you can configure the mapping rules for both the schema and the table.
[routes]
[routes.rule1] # rule1 is the only custom ID for the configuration. It is used for the above `data-sources.route-rules` configuration.
schema-pattern = "test_*" # Matches the schema name of the data source. Supports the wildcards "*" and "?"
table-pattern = "t_*" # Matches the table name of the data source. Supports the wildcards "*" and "?"
target-schema = "test" # The name of the schema in the target database
target-table = "t" # The name of the target table
[routes.rule2]
schema-pattern = "test2_*" # Matches the schema name of the data source. Supports the wildcards "*" and "?"
table-pattern = "t2_*" # Matches the table name of the data source. Supports the wildcards "*" and "?"
target-schema = "test2" # The name of the schema in the target database
target-table = "t2" # The name of the target table
######################### task config #########################
# Configures the tables of the target database that need to be compared.
[task]
# output-dir saves the following information:
# 1 sql: The SQL file to fix tables that is generated after error is detected. One chunk corresponds to one SQL file.
# 2 log: sync-diff.log
# 3 summary: summary.txt
# 4 checkpoint: a dir
output-dir = "./output"
# The upstream database. The value is the unique ID declared by data-sources.
source-instances = ["mysql1"]
# The downstream database. The value is the unique ID declared by data-sources.
target-instance = "tidb0"
# The tables of downstream databases to be compared. Each table needs to contain the schema name and the table name, separated by '.'
# Use "?" to match any character and "*" to match characters of any length.
# For detailed match rules, refer to golang regexp pkg: https://github.com/google/re2/wiki/Syntax.
target-check-tables = ["schema*.table*", "!c.*", "test2.t2"]
# (optional) Extra configurations for some tables, Config1 is defined in the following table config example.
target-configs = ["config1"]
######################### Table config #########################
# Special configurations for specific tables. The tables to be configured must be in `task.target-check-tables`.
[table-configs.config1] # config1 is the only custom ID for this configuration. It is used for the above `task.target-configs` configuration.
# The name of the target table, you can use regular expressions to match multiple tables, but one table is not allowed to be matched by multiple special configurations at the same time.
target-tables = ["schema*.test*", "test2.t2"]
# (optional) Specifies the range of the data to be checked
# It needs to comply with the syntax of the WHERE clause in SQL.
range = "age > 10 AND age < 20"
# (optional) Specifies the column used to divide data into chunks. If you do not configure it,
# sync-diff-inspector chooses an appropriate column (primary key, unique key, or a field with index).
index-fields = ["col1","col2"]
# (optional) Ignores checking some columns such as some types (json, bit, blob, etc.)
# that sync-diff-inspector does not currently support.
# The floating-point data type behaves differently in TiDB and MySQL. You can use
# `ignore-columns` to skip checking these columns.
ignore-columns = ["",""]
# (optional) Specifies the size of the chunk for dividing the table. If not specified, this configuration can be deleted or be set as 0.
chunk-size = 0
# (optional) Specifies the "collation" for the table. If not specified, this configuration can be deleted or be set as an empty string.
collation = ""
sync-diff-inspector を実行する
次のコマンドを実行します。
./sync_diff_inspector --config=./config.toml
このコマンドは、 output-dir
of config.toml
とログsync_diff.log
でチェック レポートsummary.txt
を出力します。 output-dir
では、 config. toml
ファイルのハッシュ値で名前が付けられたフォルダーも生成されます。このフォルダーには、ブレークポイントのチェックポイント ノード情報と、データが矛盾している場合に生成される SQL ファイルが含まれます。
進捗情報
sync-diff-inspector は、実行時に進捗情報をstdout
に送信します。進行状況情報には、テーブル構造の比較結果、テーブル データの比較結果、進行状況バーが含まれます。
ノート:
表示効果を確保するには、表示ウィンドウの幅を 80 文字以上にしてください。
A total of 2 tables need to be compared
Comparing the table structure of ``sbtest`.`sbtest96`` ... equivalent
Comparing the table structure of ``sbtest`.`sbtest99`` ... equivalent
Comparing the table data of ``sbtest`.`sbtest96`` ... failure
Comparing the table data of ``sbtest`.`sbtest99`` ...
_____________________________________________________________________________
Progress [==========================================================>--] 98% 193/200
A total of 2 tables need to be compared
Comparing the table structure of ``sbtest`.`sbtest96`` ... equivalent
Comparing the table structure of ``sbtest`.`sbtest99`` ... equivalent
Comparing the table data of ``sbtest`.`sbtest96`` ... failure
Comparing the table data of ``sbtest`.`sbtest99`` ... failure
_____________________________________________________________________________
Progress [============================================================>] 100% 0/0
The data of `sbtest`.`sbtest99` is not equal
The data of `sbtest`.`sbtest96` is not equal
The rest of tables are all equal.
The patch file has been generated in
'output/fix-on-tidb2/'
You can view the comparision details through 'output/sync_diff.log'
出力ファイル
出力ファイルのディレクトリ構造は次のとおりです。
output/
|-- checkpoint # Saves the breakpoint information
| |-- bbfec8cc8d1f58a5800e63aa73e5 # Config hash. The placeholder file which identifies the configuration file corresponding to the output directory (output/)
│ |-- DO_NOT_EDIT_THIS_DIR
│ └-- sync_diff_checkpoints.pb # The breakpoint information
|
|-- fix-on-target # Saves SQL files to fix data inconsistency
| |-- xxx.sql
| |-- xxx.sql
| └-- xxx.sql
|
|-- summary.txt # Saves the summary of the check results
└-- sync_diff.log # Saves the output log informatiion when sync-diff-inspector is running
ログ
sync-diff-inspector のログは${output}/sync_diff.log
に保存され、そのうち${output}
はconfig.toml
ファイルのoutput-dir
の値です。
進捗
実行中の sync-diff-inspector は定期的に (10 秒ごとに) チェックポイントの進行状況を出力します。これは${output}/checkpoint/sync_diff_checkpoints.pb
にあり、そのうち${output}
はconfig.toml
ファイルのoutput-dir
の値です。
結果
チェックが完了すると、sync-diff-inspector がレポートを出力します。これは${output}/summary.txt
にあり、 ${output}
はconfig.toml
ファイルのoutput-dir
の値です。
+---------------------+--------------------+----------------+
| TABLE | STRUCTURE EQUALITY | DATA DIFF ROWS |
+---------------------+--------------------+----------------+
| `sbtest`.`sbtest99` | true | +97/-97 |
| `sbtest`.`sbtest96` | true | +0/-101 |
+---------------------+--------------------+----------------+
Time Cost: 16.75370462s
Average Speed: 113.277149MB/s
TABLE: 対応するデータベース名とテーブル名
STRUCTURE EQUALITY: テーブル構造が同じかどうかをチェックします
データ差分行:
rowAdd
/rowDelete
.テーブルを修正するために追加/削除する必要がある行の数を示します
不整合データを修正するための SQL ステートメント
データ チェック プロセス中に異なる行が存在する場合、それらを修正するために SQL ステートメントが生成されます。チャンク内にデータの不整合が存在する場合、 chunk.Index
という名前の SQL ファイルが生成されます。 SQL ファイルは${output}/fix-on-${instance}
にあり、 ${instance}
はconfig.toml
ファイルのtask.target-instance
の値です。
SQL ファイルには、チャンクが属する tale と範囲情報が含まれています。 SQL ファイルについては、次の 3 つの状況を考慮する必要があります。
- ダウンストリーム データベースの行が欠落している場合、REPLACE ステートメントが適用されます。
- ダウンストリーム データベースの行が冗長な場合、DELETE ステートメントが適用されます。
- ダウンストリーム データベースの行の一部のデータに一貫性がない場合、REPLACE ステートメントが適用され、一貫性のない列は SQL ファイル内の注釈でマークされます。
-- table: sbtest.sbtest99
-- range in sequence: (3690708) < (id) <= (3720581)
/*
DIFF COLUMNS ╏ `K` ╏ `C` ╏ `PAD`
╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╋╍╍╍╍╍╍╍╍╍╋╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╋╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍
source data ╏ 2501808 ╏ 'hello' ╏ 'world'
╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╋╍╍╍╍╍╍╍╍╍╋╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╋╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍
target data ╏ 5003616 ╏ '0709824117-9809973320-4456050422' ╏ '1714066100-7057807621-1425865505'
╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╋╍╍╍╍╍╍╍╍╍╋╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╋╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍
*/
REPLACE INTO `sbtest`.`sbtest99`(`id`,`k`,`c`,`pad`) VALUES (3700000,2501808,'hello','world');
ノート
- sync-diff-inspector は、データをチェックするときに一定量のサーバーリソースを消費します。営業時間のピーク時に sync-diff-inspector を使用してデータをチェックすることは避けてください。
- MySQL のデータと TiDB のデータを比較する前に、テーブルの照合順序構成に注意してください。主キーまたはユニークキーが
varchar
型で、MySQL と TiDB の照合順序構成が異なる場合、照合順序の問題により、最終的なチェック結果が正しくない可能性があります。 sync-diff-inspector 構成ファイルに照合順序を追加する必要があります。 - sync-diff-inspector は、最初に TiDB 統計に従ってデータをチャンクに分割します。統計の正確性を保証する必要があります。 TiDB サーバーのワークロードが軽い場合は、
analyze table {table_name}
コマンドを手動で実行できます。 table-rules
に特に注意してください。schema-pattern="test1"
、およびtable-pattern = "t_1"
をtarget-table = "t_2"
するtest1
target-schema="test2"
ソース データベースのt_1
スキーマとtest2
.ターゲット データベースのt_2
個のスキーマが比較されます。シャーディングは sync-diff-inspector でデフォルトで有効になっているため、ソース データベースにtest2
がある場合。t_2
テーブル、test1
。t_1
テーブルとtest2
。シャーディングとして機能するソース データベースのt_2
のテーブルがtest2
と比較されます。ターゲット データベースのt_2
テーブル。- 生成された SQL ファイルは、データを修復するための参照としてのみ使用され、これらの SQL ステートメントを実行してデータを修復する前に確認する必要があります。