本文简要介绍了TiDB工具生态中的数据导出工具Dumpling和数据快速导入工具Lightning，并结合场景进行测试使用。
1、全量导出工具Dumpling
Dumpling是go语言开发的数据备份工具，可以将TiDB/MySQL中的数据导出为SQL/CSV格式，可以实现逻辑上的全量备份或者导出。Dumpling针对TiDB进行了专门的优化，比如：
- 支持配置TiDB单条SQL内存限制
- 针对TiDB v4.0.0以上版本支持自动调整 TiDB GC 时间
- 使用TiDB的隐藏列_tidb_rowid优化了单表内数据的并发导出性能
- 对于TiDB可以设置 tidb_snapshot 的值指定备份数据的时间点，从而保证备份的一致性，而不是通过FLUSH TABLES WITH READ LOCK 来保证备份一致性
在使用Dumpling时，需要在已经启动的集群上执行导出命令
所有通过Dumpling导出的数据都可以通过Lightning导入到TiDB中。
1.1 安装Dumpling工具
TiDB工具包中包括了TiDB Binlog、TiDB Lightning、BR备份恢复工具、TiDB Data Migration、Dumpling等，下载链接为https://download.pingcap.org/tidb-toolkit-{version}-linux-amd64.tar.gz
1.2 从TiDB/MySQL导出数据
1）导出到SQL文件
Dumpling默认导出数据格式为sql文件，可以通过设置–filetype sql导出数据到sql文件：
2）输出文件格式
- metadata：此文件包含导出的起始时间，以及 master binary log 的位置。
- {schema}-schema-create.sql：创建schema的SQL文件。
- {schema}.{table}.{0001}.{sql|csv}：数据源文件
- -schema-view.sql、-schema-trigger.sql、*-schema-post.sql：其他导出文件
3）导出到CSV文件
4）输出文件格式
- metadata：此文件包含导出的起始时间，以及 master binary log 的位置。
- {schema}.{table}.{0001}.{sql|csv}：数据源文件
1.3 筛选导出的数据
1）使用 --where 选项筛选数据
默认情况下，Dumpling会导出系统数据库（包括 mysql 、sys 、INFORMATION_SCHEMA 、PERFORMANCE_SCHEMA、METRICS_SCHEMA 和 INSPECTION_SCHEMA）外所有其他数据库。可以使用 --where 来选定要导出的记录，比如：
上述命令将会导出各个表的 id < 10 的数据
2）使用–filter选项筛选数据
Dumpling可以通过–filter指定table-filter来筛选特定的库表
上述命令将会导出所有数据库中的tab01表
3）使用-B或-T选项筛选数据
Dumpling也可以通过-B或-T选项导出特定的数据库/数据表，-B导出指定的数据库、-T导出指定的表。
注：–filter与-T不可同时使用；-T只能是完整的表名形式“库名.表名”
1.4 提高Dumpling的并发
默认情况下，导出的文件会存储到 https://blog.csdn.net/solihawk/article/details/export- 目录下。常用选项如下：
- -o用于选择存储导出文件的目录
- -F选项用于指定单个文件的最大大小，默认单位为 MiB，也可以是GiB或者KiB
- -r选项用于指定单个文件的最大记录数，开启后 Dumpling 会开启表内并发，提高导出大表的速度。
利用以上选项可以提高Dumpling的并行度
1.5 Dumpling的数据一致性
Dumpling通过–consistency 标志控制导出数据的一致性，有以下几种方式
- flush：使用 FLUSH TABLES WITH READ LOCK 来保证一致性。
- snapshot：获取指定时间戳的一致性快照并导出。
- lock：为待导出的所有表上读锁。
- none：不做任何一致性保证。
- auto：对 MySQL 使用 flush，对 TiDB 使用 snapshot。
默认情况下，TiDB会通过获取某个时间戳的快照来保证一致性（即 --consistency snapshot）。在使用snapshot来保证一致性的时候，可以使用–snapshot选项指定要备份的时间戳。
1.6 导出TiDB历史数据快照
Dumpling可以通过–snapshot指定导出某个 tidb_snapshot 时的数据。–snapshot选项可设为 TSO（SHOW MASTER STATUS 输出的 Position 字段）或有效的 datetime 时间，例如：
即可导出TSO为422913627203829761或2021-02-14 15:12:00 时的TiDB历史数据快照。
1.7 导出TiDB大表时的内存控制
Dumpling导出TiDB较大单表时，可能会因为导出数据过大导致TiDB内存溢出(OOM)，从而使连接中断导出失败。可以通过以下参数减少TiDB的内存使用。
- 设置–rows 参数，通过减少导出数据区块以减少TiDB扫描数据的内存开销，同时也可开启表内并发提高导出效率
- 调整–tidb-mem-quota-query参数到8GB或更小。该参数默认为32GB，可控制TiDB单条查询语句的内存使用
- 调整–params “tidb_distsql_scan_concurrency” 参数，即设置导出时的session变量 tidb_distsql_scan_concurrency 从而减少 TiDB scan 操作的并发度
2、全量数据快速导入工具TiDB lightning
TiDB Lighting是将全量数据快速导入TiDB的工具，支持Dumpling或CSV格式的数据源。主要有以下使用场景：
- 迅速导入大量新的数据
- 恢复所有备份数据
使用TiDB Lightning时需要注意以下几点：
- TiDB Lightning运行后，TiDB集群将无法正常对外提供服务
- 若tidb-lightning崩溃，集群会留在“导入模式”。若忘记转回“普通模式”，集群会产生大量未压缩的文件，继而消耗CPU并导致延迟。此时，需要使用 tidb-lightning-ctl 手动将集群转回“普通模式”：
2.1 TiDB Lightning整体架构
2）配置tidb-lightning.toml
3）运行tidb-lightning
查看日志信息：
2.3 TiDB Lighting特性说明
2.3.1 断点续传
由参数“enable = true”控制是否启用断点续传；导入数据时，TiDB Lightning会记录当前表导入的进度，所以即使Lightning或其他组件异常退出，在重启时也可以避免重复再导入已完成的数据。TiDB Lightning支持两种断点存储方式：本地文件或MySQL数据库。
- 若driver = “file”，断点会存放在一个本地文件，其路径由 dsn 参数指定。由于断点会频繁更新，建议将这个文件放到写入次数不受限制的盘上，例如RAM disk。
- 若driver = “mysql”，断点可以存放在MySQL数据库中，在没有选择的情况下，默认会存在目标数据库里。建议另外部署一台兼容MySQL的临时数据库服务器，导入完毕后可以删除。
如果Tidb-lightning因为不可恢复的错误退出，重启的时候不会使用断点而是直接报错，因此需要先解决这些错误才能继续，此时可以使用tidb-lightning-ctrl工具：
- –checkpoint-error-destroy：失败的表从头开始整个导入过程
- –checkpoint-error-ignore：清除表的出错状态
- –checkpoint-remove：无论是否出错，清除断点
- –checkpoint-dump：将断点备份到文件夹，主要用于技术支持
2.3.2 表库过滤
TiDB 4.0开始，所有的TiDB工具集都可以使用通用的过滤语法来定义子集，比如：
- 命令行：使用–filter参数https://blog.csdn.net/solihawk/article/details/dumpling -f ‘foo*.’ -f 'bar.*’ -P 3306 -o /tmp/data/
- TOML配置文件：filter = [‘foo*.’, 'bar.*’]
表库的过滤方法可以使用通配符，也可以使用正则表达式
2.3.3 TiDB Lightning后端
TiDB Lightning的后端决定 tidb-lightning 组件将如何把将数据导入到目标集群中，目前支持以下几种后端方式
- importer-backend：tidb-lightning先将SQL或CSV数据编码成键值对，由tikv-importer对写入的键值对进行排序，然后把这些键值对Ingest到TiKV节点中。
- Local-backend：tidb-lightning先将数据编码成键值对并排序存储在本地临时目录，然后批量将这些键值对写到各个TiKV节点，然后由TiKV将它们Ingest到集群中。和 importer-backend 原理相同，不过不依赖额外的 tikv-importer 组件。
- TiDB-backend：tidb-lightning 先将数据编码成 INSERT 语句，然后直接在TiDB节点上运行这些SQL语句进行数据导入。
如果导入的目标集群为v4.0或以上版本，优先考虑使用Local-backend模式。Local-backend部署更简单并且性能也较其他两个模式更高。
2.3.4 TiDB Lightning Web界面
TiDB Lightning支持服务器模式，可以在Web端查看导入的进度以及执行简单的任务，在启动的时候加入“–server-mode --status-addr :8289”参数或者配置文件中将server-mode设置为true即可。
TiDB Lightning启动后，访问http://192.168.112.10:8289来管理任务
2.4 从CSV文件迁移到MySQL
1）CSV文件名
CSV文件需命名为db_name.table_name.csv，该文件会被解析为数据库db_name里名为table_name的表。如果一个表分布于多个CSV文件，这些CSV文件命名需加上文件编号的后缀，如 db_name.table_name.001.csv，数字部分不需要连续但必须递增，并用零填充。
2） 表结构
CSV文件没有表结构，在导入TiDB过程中，需提供表结构，可通过以下方法实现：
- 创建包含DDL语句CREATE TABLE的文件db_name.table_name-schema.sql以及包 CREATE DATAbase DDL语句的文件db_name-schema-create.sql
- 首先在TiDB中直接创建空表，然后在 tidb-lightning.toml 中设置“[mydumper] no-schema = true”
3）配置文件
4）创建表
5）启动
源文件格式如下：
查看导入结果如下
2.5 从SQL文件迁移到MySQL
1）通过Dumpling工具生成SQL文件
修改输出文件的名称及schema为新表tab03
2）配置文件
3）监控配置
- tidb-lightning.toml 中配置监控端口
- 配置Prometheus后，将服务器地址直接添加至 scrape_configs 部分
修改配置后重启Prometheus服务
4）运行任务
5）查看导入的数据
到这里，已经完成了TiDB Lightning的数据导入测试，在使用时需要注意以下几点：
- TiDB Lightning运行后，TiDB集群将无法正常对外提供服务
- CSV格式文件导入时候需要先准备好表结构DDL或者创建表
- SQL格式文件导入到目标库的时候，可以通过修改sql文件来调整目标库的表名称
- Dumpling和Lightning实现的是逻辑上的数据导出导入，通过snapshot指定，可以实现一致性时间点的数据恢复导入操作
参考资料：
- https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-overview
- https://docs.pingcap.com/zh/tidb/stable/dumpling-overview