数据迁移实践：单库迁移策略

前言

采用Dumpling+Lightning+TiDB Binlog的方式进行

Dumpling介绍： 导出数据的格式可分为：SQL格式、CSV格式 支持将数据导出到Amazon S3当中 还可以针对SQL文件进行压缩为gz格式

Lightning介绍： 将全量数据告诉导入导TiDB集群的工具 导入数据的格式：Dumpling输出的数据、CSV文件和Amazon生成的Apache Parquet文件

TiDB Binlog介绍： 收集 TiDB 的 binlog，并提供准实时备份和同步功能 拥有Pump、Drainer组件，支持水平扩容

+ +

Dumpling参数介绍参数用法说明--filetype--filetype sql | --filetype csv指定导出数据的格式-（默认为SQL格式）-o-o /data/dumping指定存储dumpling导出数据的目录--filter / -f-f "*.*" -f "test.*" -f "!test.t2" --fileter "*.*" --filter "test.*" --filter "!test.t2"指定导出库表（）正则表达式 过滤之前，需要保证可以查到规则的库，即 -f "*.*"-t-t 8指定导出的线程数，通过增加线程提升dumpling导出速度 根据实际情况来进行合理规划，防止内存消耗过大，负载太高-r-r 1 | -r 200000开启后 Dumpling 会开启表内并发，提高导出大表的速度 3.0版本以前，需要指定固定值来进行，3.0版本以后>0代表开启-F / --filesize-F 1GiB | --filesize 500MiB划分table数据的大小（注明单位如：B、KiB、MiB、GiB）-T / --tables-list-T test.t1,test.t3,schema.table --tables-list test.t1,test.t3,schema.table指定导出的库.表 （用于导出多个库的某个个表进行）Lightning参数介绍[lightning][checkpoint][tikv-importer][mydumper][tidb][post-restore]levelenablebackenddata-source-dir hostchecksumfileschemasorted-kv-dirxportanalyzecheck-requirementsxxxuserxtable-concurrencyxxxpasswordxregion-concurrencyxxxstatus-portxio-concurrencyxxxpd-addrxTiDB Binlog参数介绍PumpDrainerdata-dirdata-dirgcinitial-commit-tslog-filelog-filegen-binlog-intervallog-levelheartbeat-intervaldetect-intervalxsyncer.replicate-do-table

注释：以上参数只是列举出采用了的参数，并不代表所有参数，具体配置还需根据官方文档进行添加、更改。

背景

在制定迁移任务之前，我们通常会考虑数据库的数据量大小，与为了尽量不影响业务，可能通常会在深夜进行导出，白天停止导出计划。 1、在这种供我们导出时间有明确规定的情况下，可能会因为数据量过大的情况，导致数据导入时间不够而执行失败 2、GC时间我们也没法强行进行过大的设置，有很大的风险导致意外发生

在这种情况之下，我们需要考虑好针对于数据迁移的规划，为此写了一偏关于单库分表导出的内容，以此来解决不可能长时间进行的问题。

规划

一、从导出的数据量入手，来判断进行导出的数据量大小

可以通过sql来进行估算数据量的大小

select table_name,concat(round(DATA_LENGTH/1024/1024/1024,),G) as data_size from INFORMATION_SCHEMA.TABLES where table_schema="test" order by 2 desc;

也可以通过监控信息来确定数据量的大小（监控只能看到整个TiDB的大小或各个节点的大小，并不能看到指定库的大小）

二、判断数据导出需要的大致时间，进行规划

当我们确定了大致的数据量大小后，我们可以在测试环境进行一下试验，判断数据导出所需要消耗的时间

根据我们得出的判断，再根据业务给的允许我们导出的时间来进行制定计划

假设我这里给的是一晚上5h时间，那我由于单库过大，所以需要将指定的库拆分为两次进行数据导出

实施

一、通过上面判断我们可以得到单表的数据量估算值，通过这个估算值来对单表进行划分假设有t1/t2/t3/t4/t....个库 我会将这库分为两次导出,将两张大表单独导出，剩下小表统一导出，保证导出时间足够。 dumpling_test1：导出t1、t2 dumpling_test2：导出t3、t4、t......二、划分好导出的顺序之后我们就会针对此次导出进行脚本编写vim dumpling_start_test.sh ------------------------------------------ #!/bin/bashnohup ./dumpling -h -P -u -p "password" \ -T test.t1,test.t2 \ -F 1GiB -t 4 -r 200000 \ -o /data/dumpling_test1/ > nohup.out1 &vim dumpling_start.sh ------------------------------------------ #!/bin/bashnohup ./dumpling -h -P -u -p "password" \ -f test.* -f !test.t1 -f !test.t2 \ -F 1 GiB -t 4 -r 200000 -o /data/dumpling_test2/ > nohup.out2 &三、对导出数据的命令执行，这样我们会通过两次来进行单库的导出sh dumpling_start_test.sh

注意：不要忘记调整GC的时间，防止在导出过程中GC过期导致任务报错

update mysql.tidb set VARIABLE_VALUE="5h " where VARIABLE_NAME="tikv_gc_life_time";

四、对导出数据进行导入1、编辑Lightning配置文件 vim lightning.toml -------------------------------配置文件------------------------------------------------------------------------------ [lightning] level = "info" file = "日志目录/lightning.log" index-concurrency = 2 table-concurrency = 6 region-concurrency = 10 io-concurrency = 5 check-requirements = false [checkpoint] enable = true schema = "lightning_full_checkpoint" [tikv-importer] backend = "local" sorted-kv-dir = "目录" [mydumper] data-source-dir = "Dumpling导出数据目录" [tidb] host = "$host" port = $port user = "$user" password = "$password" status-port = "$status_port" pd-addr = "$ip:$port" build-stats-concurrency = 16 distsql-scan-concurrency = 32 index-serial-scan-concurrency = 16 checksum-table-concurrency = 32 [post-restore] checksum = "required" analyze = "required" 2、编辑启动lightning脚本 vim lightning_start.sh ------------------------启动脚本--------------------------------------------------------------------------------------#!/bin/bash nohup ./tidb-lightning -config lightning.toml > nohup_lightning.out & 3、启动Lightning脚本，观察导入进度 sh lightning_start.sh

注意事项：Dumpling导出数据的目录要明确

五、Lightning导入数据后，开启binlog做增量同步

而pump的GC时间是有限制的，不能开太长，如果导出的过多，肯定是不能放在一起在进行增量同步的，那样会导致drainer调取不到pump的binlog

所以在执行一个导入计划之后，就针对一个计划开启增量同步 注意事项： 1、过滤同步的时候需要注意优先级别 2、下游自动生成的tidb_binlog库，我们需要设置不同的名字来进行区分 3、迁移的上游需要提前开启了binlog、pump

1、编辑drainer扩容文件 vim drainer.toml ----------------------- drainer_servers: -host: port: deploy_dir: "/data/drainer/deploy" log_dir: "/data/drainer/log" data_dir: "/data/drainer/data" commit_ts: xxxxxxxxxxxx config: syncer.db-type: "tidb" syncer.to.host: "" syncer.to.user: "" syncer.to.password: "" syncer.to.port: syncer.replicate-do-table:- db-name ="test" - tbl-name = "t1" syncer.to.checkpoint: schema: "tidb_binlog_test" #syncer.replicate-do-table同步指定表 #syncer.ignore-table排除指定表 排除之前需要有可排除的库，可以用syncer.replicate-do-db指定 2、扩容drainer tiup cluster scale-out $cluster_name drainer.toml六、当我们所有的数据都迁移完毕之后，我们现在有多个drainer，这时候我们可以把drainer进行合并

当所有的drainer将增量数据追平以后，我们可以在扩容一个drainer以最小的checkpoint为时间点，进行整个库的增量同步

查看延迟，追平后，将其他drainer进行缩容即可

七、当我们的drainer合并完以后，开始进行数据校验sync-diff-inspector

合并drainer可以防止我们需要执行多次sync-diff-inspector 如果表中有double、json、bit、blob，需要找出来进行忽略 snapshot通过对应的下游checkpoint获取

采用的5.4版本的sync-diff-inspector #每个版本的数据校验参数差距不小

1、查找该表中是否有double、json、bit、blob select TABLE_NAME,TABLE_NAME,COLUMN_NAME,DATA_TYPE,COLUMN_TYPE from information_schema.columns where COLUMN_TYPE in (double,json,bit,blob) and TABLE_SCHEMA="test"; 2、编辑sync-diff-inspector配置文件vim sync-diff-inspector.toml -------------------------------check-thread-count = 4 export-fix-sql = true check-struct-only = false [data-sources] [data-sources.tidb1] host = "" port = user = "" password = "" snapshot = "" [data-sources.tidb2] host = "" port = user = "" password = "" snapshot = "" [task] output-dir = "/data/sync-tidb" source-instances = ["tidb1"] target-instance = "tidb2" target-check-tables = ["tbasic.*"]###有double、json、bit、blob的列需要添加config条件进行过滤 3、编辑启动sync-diff-inspector脚本 vim sync-diff.sh -------------------------------------- #!/bin/bash nohup ./sync-diff-inspector --config ./sync-diff-inspector.toml > nohup_sync-diff.out &

总结

整体来说，这篇文章主要是介绍对于大数据量迁移过程中使用的一种策略，针对数据量过大带来的烦恼，结合自己做过的实践来进行编写的，有几个值得注意的地方，在每个步骤的过程中进行了标记，注释。

本文并没有过多的介绍相应的理论，而是大概的讲述了整体的一个步骤流程。