《数据迁移》-- 单库迁移

2022-10-14
北京
本文字数：3282 字
阅读完需：约 11 分钟

作者： Ming 原文来源：https://tidb.net/blog/7606d56c

前言

采用 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 参数介绍

Lightning 参数介绍

TiDB Binlog 参数介绍

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

背景

在制定迁移任务之前，我们通常会考虑数据库的数据量大小，与为了尽量不影响业务，可能通常会在深夜进行导出，白天停止导出计划。1、在这种供我们导出时间有明确规定的情况下，可能会因为数据量过大的情况，导致数据导入时间不够而执行失败 2、GC 时间我们也没法强行进行过大的设置，有很大的风险导致意外发生
在这种情况之下，我们需要考虑好针对于数据迁移的规划，为此写了一偏关于单库分表导出的内容，以此来解决不可能长时间进行的问题。

规划

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

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

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

当我们确定了大致的数据量大小后，我们可以在测试环境进行一下试验，判断数据导出所需要消耗的时间
根据我们得出的判断，再根据业务给的允许我们导出的时间来进行制定计划
假设我这里给的是一晚上 5h 时间，那我由于单库过大，所以需要将指定的库拆分为两次进行数据导出

实施

一、通过上面判断我们可以得到单表的数据量估算值，通过这个估算值来对单表进行划分

假设有t1/t2/t3/t4/t....个库
我会将这库分为两次导出,将两张大表单独导出，剩下小表统一导出，保证导出时间足够。dumpling_test1：导出t1、t2dumpling_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 = 2table-concurrency = 6region-concurrency = 10io-concurrency = 5check-requirements = false
[checkpoint]enable = trueschema = "lightning_full_checkpoint"
[tikv-importer]backend = "local"sorted-kv-dir = "目录"
[mydumper]data-source-dir = "Dumpling导出数据目录"
[tidb]host = "$host"port = $portuser = "$user"password = "$password"status-port = "$status_port"pd-addr = "$ip:$port"
build-stats-concurrency = 16distsql-scan-concurrency = 32index-serial-scan-concurrency = 16checksum-table-concurrency = 32
[post-restore]checksum = "required"analyze = "required"
2、编辑启动lightning脚本vim lightning_start.sh------------------------启动脚本--------------------------------------------------------------------------------------#!/bin/bashnohup ./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、扩容drainertiup 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、blobselect 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 = 4export-fix-sql = truecheck-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/bashnohup ./sync-diff-inspector --config ./sync-diff-inspector.toml > nohup_sync-diff.out &

复制代码

总结

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

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

发布于: 刚刚阅读数: 3

原文链接:【http://xie.infoq.cn/article/0984c7c97fd8c387770e661cc】。文章转载请联系作者。

TiDB 社区干货传送门

关注

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

发布

暂无评论

创作场景

《数据迁移》-- 单库迁移

前言

Dumpling 参数介绍

Lightning 参数介绍

TiDB Binlog 参数介绍

背景

规划

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

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

实施

一、通过上面判断我们可以得到单表的数据量估算值，通过这个估算值来对单表进行划分

二、划分好导出的顺序之后我们就会针对此次导出进行脚本编写

三、对导出数据的命令执行，这样我们会通过两次来进行单库的导出

四、对导出数据进行导入

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

六、当我们所有的数据都迁移完毕之后，我们现在有多个 drainer，这时候我们可以把 drainer 进行合并

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

总结

TiDB 社区干货传送门

评论