《数据迁移》--单库迁移
原创
©著作权归作者所有:来自51CTO博客作者TiDB社区干货传送门的原创作品,请联系作者获取转载授权,否则将追究法律责任
作者: Ming
前言
采用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] |
level
| enable
| backend
| data-source-dir
| host
| checksum
|
file
| schema
| sorted-kv-dir
| x
| port
| analyze
|
check-requirements
| x
| x
| x
| user
| x
|
table-concurrency
| x
| x
| x
| password
| x
|
region-concurrency
| x
| x
| x
| status-port
| x
|
io-concurrency
| x
| x
| x
| pd-addr
| x
|
TiDB Binlog参数介绍
Pump
| Drainer
|
data-dir
| data-dir
|
gc
| initial-commit-ts
|
log-file
| log-file
|
gen-binlog-interval
| log-level
|
heartbeat-interval
| detect-interval
|
x
| syncer.replicate-do-table
|
注释:以上参数只是列举出采用了的参数,并不代表所有参数,具体配置还需根据官方文档进行添加、更改。
背景
在制定迁移任务之前,我们通常会考虑数据库的数据量大小,与为了尽量不影响业务,可能通常会在深夜进行导出,白天停止导出计划。 1、在这种供我们导出时间有明确规定的情况下,可能会因为数据量过大的情况,导致数据导入时间不够而执行失败 2、GC时间我们也没法强行进行过大的设置,有很大的风险导致意外发生
在这种情况之下,我们需要考虑好针对于数据迁移的规划,为此写了一偏关于单库分表导出的内容,以此来解决不可能长时间进行的问题。
规划
一、从导出的数据量入手,来判断进行导出的数据量大小
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/bash
nohup ./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/bash
nohup ./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 &
总结
整体来说,这篇文章主要是介绍对于大数据量迁移过程中使用的一种策略,针对数据量过大带来的烦恼,结合自己做过的实践来进行编写的,有几个值得注意的地方,在每个步骤的过程中进行了标记,注释。
本文并没有过多的介绍相应的理论,而是大概的讲述了整体的一个步骤流程。