集群目前情况
数据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.2
Git commit hash: aa6ed99ae63191bc98e883fd4c369ae7482cccb7
Git branch: heads/refs/tags/v7.1.2
Build timestamp: 2023-10-21 07:38:45Z
Go version: go version go1.20.10 linux/amd64
meet some unparsed arguments, please check again: [10.10.110.47]
导入测试
1、逻辑导入
导入配置文件
[lightning]
region-concurrency = 14
# 日志
level = "info"
file = "tidb-lightning.log"
max-size = 256 # MB
max-days = 28
max-backups = 14
# 启动之前检查集群是否满足最低需求。
check-requirements = true
[mydumper]
# 本地源数据目录或外部存储 URL
data-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 Mode
backend = "tidb"
# Logical Import Mode 插入重复数据时执行的操作。
# - replace：新数据替代已有数据
# - ignore：保留已有数据，忽略新数据
# - error：中止导入并报错
on-duplicate = "replace"
[tidb]
# 目标集群的信息。tidb-server 的地址，填一个即可。
host = "10.21.109.11"
port = 3306
user = "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 # MB
max-days = 28
max-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 = true
disk-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 = 3306
user = "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 later
put job back to jobCh to retry later
BR: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'
所有重要表验证完毕，任务完成