从 TiDB 5.4.0 开始,你可以配置 TiDB Lightning 以跳过诸如无效类型转换、唯一键冲突等错误,让导入任务持续进行,就如同出现错误的行数据不存在一样。你可以依据生成的报告,手动修复这些错误。该功能适用于以下场景:
本文介绍了类型错误处理功能 (lightning.max-error
) 和重复问题处理功能 (tikv-importer.duplicate-resolution
) 的使用方法,以及保存这些错误的数据库 (lightning.task-info-schema-name
),并提供了一个示例。
你可以通过修改配置项 lightning.max-error
来增加数据类型相关的容错数量。如果设置为 N,那么 TiDB Lightning 允许数据源中出现 N 个错误,而且会跳过这些错误,一旦超过这个错误数就会退出。默认值为 0,表示不允许出现错误。
这些错误会被记录到数据库中。在导入完成后,你可以查看数据库中的数据,手动进行处理。请参见错误报告。
[lightning] max-error = 0
该配置对下列错误有效:
'Text'
'非常长的文字'
'0000-00-00'
和 '2021-12-00'
on-duplicate = "error"
时,TiDB 后端的唯一键/主键冲突下列错误是致命错误,不能通过配置 max-error
跳过:
在 Physical Import Mode 下,唯一键/主键的冲突是单独处理的。相关内容将在接下来的章节进行介绍。
如果 TiDB Lightning 在运行过程中收集到报错的记录,则在退出时会同时在终端和日志中输出各个类型报错数量的统计信息。
输出在终端的报错统计如下表所示:
# | ERROR TYPE | ERROR COUNT | ERROR DATA TABLE |
---|---|---|---|
1 | Data Type | 1000 | lightning_task_info .type_error_v1 |
输出在 TiDB Lightning 的 log 文件的结尾如下:
[2022/03/13 05:33:57.736 +08:00] [WARN] [errormanager.go:459] ["Detect 1000 data type errors in total, please refer to table `lightning_task_info`.`type_error_v1` for more details"]
所有错误都会写入下游 TiDB 集群 lightning_task_info
数据库中的表中。在导入完成后,如果收集到报错的数据,你可以根据数据库中记录的内容,手动进行处理。
你可以使用 lightning.task-info-schema-name
配置更改数据库名称。
[lightning] task-info-schema-name = 'lightning_task_info'
在此数据库中,TiDB Lightning 创建了 3 个表:
CREATE TABLE syntax_error_v1 ( task_id bigint NOT NULL, create_time datetime(6) NOT NULL DEFAULT now(6), table_name varchar(261) NOT NULL, path varchar(2048) NOT NULL, offset bigint NOT NULL, error text NOT NULL, context text ); CREATE TABLE type_error_v1 ( task_id bigint NOT NULL, create_time datetime(6) NOT NULL DEFAULT now(6), table_name varchar(261) NOT NULL, path varchar(2048) NOT NULL, offset bigint NOT NULL, error text NOT NULL, row_data text NOT NULL ); CREATE TABLE conflict_error_v1 ( task_id bigint NOT NULL, create_time datetime(6) NOT NULL DEFAULT now(6), table_name varchar(261) NOT NULL, index_name varchar(128) NOT NULL, key_data text NOT NULL, row_data text NOT NULL, raw_key mediumblob NOT NULL, raw_value mediumblob NOT NULL, raw_handle mediumblob NOT NULL, raw_row mediumblob NOT NULL, KEY (task_id, table_name) );
type_error_v1 记录由 max-error
配置项管理的所有类型错误 (Type error)。每个错误一行。
conflict_error_v1 记录所有后端中的唯一键/主键冲突,每对冲突有两行。
列名 | 语法 | 类型 | 冲突 | 说明 |
---|---|---|---|---|
task_id | ✓ | ✓ | ✓ | 生成此错误的 TiDB Lightning 任务 ID |
create_time | ✓ | ✓ | ✓ | 记录错误的时间 |
table_name | ✓ | ✓ | ✓ | 包含错误的表的名称,格式为 '`db`.`tbl`' |
path | ✓ | ✓ | 包含错误文件的路径 | |
offset | ✓ | ✓ | 文件中发现错误的字节位置 | |
error | ✓ | ✓ | 错误信息 | |
context | ✓ | 围绕错误的文本 | ||
index_name | ✓ | 冲突中唯一键的名称。主键冲突为 'PRIMARY' |
||
key_data | ✓ | 导致错误的行的格式化键句柄。该内容仅供人参考,机器不可读 | ||
row_data | ✓ | ✓ | 导致错误的格式化行数据。该内容仅供人参考,机器不可读 | |
raw_key | ✓ | 冲突的 KV 对的键 | ||
raw_value | ✓ | 冲突的 KV 对的值 | ||
raw_handle | ✓ | 冲突行的行句柄 | ||
raw_row | ✓ | 冲突行的编码值 |
注意
错误报告记录的是文件偏移量,不是行号或列号,因为行号或列号的获取效率很低。你可以使用下列命令在字节位实现快速跳转(以 183 为例):
shell:输出前面几行
head -c 183 file.csv | tail
shell,输出后面几行
tail -c +183 file.csv | head
vim::goto 183
或 183go
在该示例中,我们准备了一个包含一些已知错误的数据源。以下是处理这些错误的具体步骤:
准备数据库和表结构:
mkdir example && cd example echo 'CREATE SCHEMA example;' > example-schema-create.sql echo 'CREATE TABLE t(a TINYINT PRIMARY KEY, b VARCHAR(12) NOT NULL UNIQUE);' > example.t-schema.sql
准备数据:
cat <
配置 TiDB Lightning,启用严格 SQL 模式,使用 Local 后端模式进行导入,通过删除解决重复项,并最多跳过 10 个错误:
cat <
运行 TiDB Lightning。因为已跳过所有错误,该命令执行完会成功退出:
tiup tidb-lightning -c config.toml
验证导入的表仅包含两个正常行:
$ mysql -u root -h 127.0.0.1 -P 4000 -e 'select * from example.t' +---+-----+ | a | b | +---+-----+ | 1 | one | | 2 | two | +---+-----+
检查 type_error_v1
表是否捕获了涉及类型转换的三行:
$ mysql -u root -h 127.0.0.1 -P 4000 -e 'select * from lightning_task_info.type_error_v1;' -E *************************** 1. row *************************** task_id: 1635888701843303564 create_time: 2021-11-02 21:31:42.620090 table_name: `example`.`t` path: example.t.1.sql offset: 46 error: failed to cast value as varchar(12) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin for column `b` (#2): [table:1048]Column 'b' cannot be null row_data: (0,NULL) *************************** 2. row *************************** task_id: 1635888701843303564 create_time: 2021-11-02 21:31:42.627496 table_name: `example`.`t` path: example.t.1.sql offset: 183 error: failed to cast value as varchar(12) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin for column `b` (#2): [types:1406]Data Too Long, field len 12, data len 13 row_data: (77,'seventy-seven') *************************** 3. row *************************** task_id: 1635888701843303564 create_time: 2021-11-02 21:31:42.629929 table_name: `example`.`t` path: example.t.1.sql offset: 253 error: failed to cast value as tinyint(4) for column `a` (#1): [types:1690]constant 600 overflows tinyint row_data: (600,'six hundred')
检查 conflict_error_v1
表是否捕获了具有唯一键/主键冲突的四行:
$ mysql -u root -h 127.0.0.1 -P 4000 -e 'select * from lightning_task_info.conflict_error_v1;' --binary-as-hex -E *************************** 1. row *************************** task_id: 1635888701843303564 create_time: 2021-11-02 21:31:42.669601 table_name: `example`.`t` index_name: PRIMARY key_data: 40 row_data: (40, "forty") raw_key: 0x7480000000000000C15F728000000000000028 raw_value: 0x800001000000020500666F727479 raw_handle: 0x7480000000000000C15F728000000000000028 raw_row: 0x800001000000020500666F727479 *************************** 2. row *************************** task_id: 1635888701843303564 create_time: 2021-11-02 21:31:42.674798 table_name: `example`.`t` index_name: PRIMARY key_data: 40 row_data: (40, "fourty") raw_key: 0x7480000000000000C15F728000000000000028 raw_value: 0x800001000000020600666F75727479 raw_handle: 0x7480000000000000C15F728000000000000028 raw_row: 0x800001000000020600666F75727479 *************************** 3. row *************************** task_id: 1635888701843303564 create_time: 2021-11-02 21:31:42.680332 table_name: `example`.`t` index_name: b key_data: 54 row_data: (54, "fifty-four") raw_key: 0x7480000000000000C15F6980000000000000010166696674792D666FFF7572000000000000F9 raw_value: 0x0000000000000036 raw_handle: 0x7480000000000000C15F728000000000000036 raw_row: 0x800001000000020A0066696674792D666F7572 *************************** 4. row *************************** task_id: 1635888701843303564 create_time: 2021-11-02 21:31:42.681073 table_name: `example`.`t` index_name: b key_data: 42 row_data: (42, "fifty-four") raw_key: 0x7480000000000000C15F6980000000000000010166696674792D666FFF7572000000000000F9 raw_value: 0x000000000000002A raw_handle: 0x7480000000000000C15F72800000000000002A raw_row: 0x800001000000020A0066696674792D666F7572