写点什么

一个 39.3T 的集群从 TiDB v3.1.0 迁移升级到 TiDB v7.1.2 的实践

  • 2023-12-29
    北京
  • 本文字数:3161 字

    阅读完需:约 10 分钟

作者: xingzhenxiang 原文来源:https://tidb.net/blog/0629c299

集群目前情况

数据 39.3T

tidb 版本


数据导出方式选择

1、BR 这个版本刚开始支持,不知道有什么未知 bug,暂时没有选择

2、逻辑导出,首先考虑同版本发行对应的 mydumper,出现 tidb server 内存耗尽,放弃

3、最后选择 dumpling v7.1.2,看文档说事兼容以前版本

导出命令

./dumpling -u root -ppassword -h 10.10.110.47 -P3306 -f 'mydatabase.*' --tidb-mem-quota-query=1073741824  --filetype sql -t 24 -o /data/backup -r 200000 -F256MiB  -L  /tmp/dumplinglog.txt
复制代码

注意密码需要显示配置,否则会报如下错

Release version: v7.1.2Git commit hash: aa6ed99ae63191bc98e883fd4c369ae7482cccb7Git branch:      heads/refs/tags/v7.1.2Build timestamp: 2023-10-21 07:38:45ZGo version:      go version go1.20.10 linux/amd64meet some unparsed arguments, please check again: [10.10.110.47]
复制代码

导入测试

1、逻辑导入

导入配置文件

[lightning]region-concurrency = 14# 日志level = "info"file = "tidb-lightning.log"max-size = 256 # MBmax-days = 28max-backups = 14
# 启动之前检查集群是否满足最低需求。check-requirements = true
[mydumper]# 本地源数据目录或外部存储 URLdata-source-dir = "/data/backup"
[checkpoint]# 是否启用断点续传。# 导入数据时,TiDB Lightning 会记录当前表导入的进度。# 所以即使 TiDB Lightning 或其他组件异常退出,在重启时也可以避免重复再导入已完成的数据。enable = true# 存储断点的数据库名称。schema = "tidb_lightning_checkpoint"# 存储断点的方式。# - file:存放在本地文件系统。# - mysql:存放在兼容 MySQL 的数据库服务器。driver = "file"
# dsn 是数据源名称 (data source name),表示断点的存放位置。# 若 driver = "file",则 dsn 为断点信息存放的文件路径。#若不设置该路径,则默认存储路径为“/tmp/CHECKPOINT_SCHEMA.pb”。# 若 driver = "mysql",则 dsn 为“用户:密码@tcp(地址:端口)/”格式的 URL。# 若不设置该 URL,则默认会使用 [tidb] 部分指定的 TiDB 服务器来存储断点。# 为减少目标 TiDB 集群的压力,建议指定另一台兼容 MySQL 的数据库服务器来存储断点。# dsn = "/tmp/tidb_lightning_checkpoint.pb"
# 所有数据导入成功后是否保留断点。设置为 false 时为删除断点。# 保留断点有利于进行调试,但会泄漏关于数据源的元数据。# keep-after-success = false
[tikv-importer]# 导入模式配置,设为 tidb 即使用 Logical Import Modebackend = "tidb"
# Logical Import Mode 插入重复数据时执行的操作。# - replace:新数据替代已有数据# - ignore:保留已有数据,忽略新数据# - error:中止导入并报错on-duplicate = "replace"
[tidb]# 目标集群的信息。tidb-server 的地址,填一个即可。host = "10.21.109.11"port = 3306user = "root"# 设置连接 TiDB 的密码,可为明文或 Base64 编码。password = ""# tidb-lightning 引用了 TiDB 库,并生成产生一些日志。# 设置 TiDB 库的日志等级。log-level = "error"sql-mode = "ONLY_FULL_GROUP_BY,NO_ENGINE_SUBSTITUTION"
复制代码

遇到问题

报错内容,考虑导入并发参数过大,所以修改并发参数为 cpu 的 75%(region-concurrency = 42,第三次调整为 32, 第四次调整为 24,第五次调整为 14 就不报错了)


[2023/11/23 10:59:05.172 +08:00] [ERROR] [tidb.go:708] [“execute statement failed”] [rows=“[”] [error=“Error 9005 (HY000): Region is unavailable”][2023/11/23 10:59:05.172 +08:00] [ERROR] [tidb.go:708] [“execute statement failed”] [rows=“[)]”] [stmt=“REPLACE INTO db.table VALUES()”] [error=“Error 9005 (HY000): Region is unavailable”]
复制代码

2、物理导入

物理导入配置文件(只有一个 lightning 导入)

[lightning]# 日志level = "info"file = "tidb-lightning.log"max-size = 256 # MBmax-days = 28max-backups = 14
# 启动之前检查集群是否满足最低需求。check-requirements = true
[mydumper]# 本地源数据目录或外部存储 URI。关于外部存储 URI 详情可参考 https://docs.pingcap.com/zh/tidb/v6.6/backup-and-restore-storages#uri-%E6%A0%BC%E5%BC%8F。data-source-dir = "/data/backup"
[tikv-importer]# 导入模式配置,设为 local 即使用物理导入模式incremental-import = truedisk-quota = "200GB"backend = "local"
# 冲突数据处理方式duplicate-resolution = 'remove'
# 本地进行 KV 排序的路径。sorted-kv-dir = "/localimport/tempdata"
# 限制 TiDB Lightning 向每个 TiKV 节点写入的带宽大小,默认为 0,表示不限制。# store-write-bwlimit = "128MiB"
# 物理导入模式是否通过 SQL 方式添加索引。默认为 `false`,表示 TiDB Lightning 会将行数据以及索引数据都编码成 KV pairs 后一同导入 TiKV,实现机制和历史版本保持一致。如果设置为 `true`,即 TiDB Lightning 会导完数据后,再使用 add index 的 SQL 来添加索引。# 通过 SQL 方式添加索引的优点是将导入数据与导入索引分开,可以快速导入数据,即使导入数据后,索引添加失败,也不会影响数据的一致性。# add-index-by-sql = false
[tidb]# 目标集群的信息。tidb-server 的地址,填一个即可。host = "10.21.109.11"port = 3306user = "root"# 设置连接 TiDB 的密码,可为明文或 Base64 编码。password = ""# 必须配置。表结构信息从 TiDB 的“status-port”获取。status-port = 10080# 必须配置。pd-server 的地址,填一个即可。pd-addr = "10.21.109.11:2379"# tidb-lightning 引用了 TiDB 库,并生成产生一些日志。# 设置 TiDB 库的日志等级。log-level = "error"
[post-restore]# 配置是否在导入完成后对每一个表执行 `ADMIN CHECKSUM TABLE <table>` 操作来验证数据的完整性。# 可选的配置项:# - "required"(默认)。在导入完成后执行 CHECKSUM 检查,如果 CHECKSUM 检查失败,则会报错退出。# - "optional"。在导入完成后执行 CHECKSUM 检查,如果报错,会输出一条 WARN 日志并忽略错误。# - "off"。导入结束后不执行 CHECKSUM 检查。# 默认值为 "required"。从 v4.0.8 开始,checksum 的默认值由此前的 "true" 改为 "required"。## 注意:# 1. Checksum 对比失败通常表示导入异常(数据丢失或数据不一致),因此建议总是开启 Checksum。# 2. 考虑到与旧版本的兼容性,依然可以在本配置项设置 `true` 和 `false` 两个布尔值,其效果与 `required` 和 `off` 相同。checksum = "required"# 配置是否在 CHECKSUM 结束后对所有表逐个执行 `ANALYZE TABLE <table>` 操作。# 此配置的可选配置项与 `checksum` 相同,但默认值为 "optional"。analyze = "optional"
复制代码


遇到问题


正常现象相关解释(https://asktug.com/t/topic/1018802/1


meet error and handle the job laterput job back to jobCh to retry laterBR:Restore:ErrRestoreSplitFailed]fail to split region
复制代码

导入测试结果对比

逻辑导入(导入时长 14 天)

物理导入(导入时长 4 天)

数据记录 count(*) 两种方式是一样的


物理导入压缩比更高,导入时长更短,为啥不直接使用物理导入,因为官网限制说明有歧义,一个说单表一个说单实例,只能自己测试验证一下,还有一个原因就是我这是单库数据量为 17.30T(sql 文件)



正式导入

配置 mysql 二进制日志周期为 30 天,采用 lighting 物理导入方式导入,导入完后同步增量数据到最新。

版本信息

验证数据

select count(*)from table_xxx where create_date_time<‘2012-12-25’



所有重要表验证完毕,任务完成


发布于: 刚刚阅读数: 2
用户头像

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

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

评论

发布
暂无评论
一个 39.3T 的集群从TiDB v3.1.0迁移升级到 TiDB v7.1.2 的实践_迁移_TiDB 社区干货传送门_InfoQ写作社区
vConsole