要进行tidb机房迁移，机房在不同的洲，网络延迟较高，需要新建集群导数据迁移。因此使用br迁移。

1、数据量有8张表。有2张大表，有接近6T数据。其余6张表共有1T数据。

2、网络带宽每秒传输数据30M 每秒。

首先使用这个sql统计每张表大小。

select  table_schema,table_name,TABLE_SIZE/1000 from INFORMATION_SCHEMA.TABLE_STORAGE_STATS where table_schema='库名'  and table_name='表名';

最后，尝试了多种方案，迁移数据速度都太慢了，想要实现一天迁移完成数据，

形成了2种比较快的方案配合实现了迁移。

1、6张表共有1T数据用dumpling和lightning迁移数据。

2、2张大表共有6T数据用BR进行数据迁移。

安装软件

使用这个命令安装：

TiDB 工具下载 | PingCAP 归档文档站

wget "https://download.pingcap.org/tidb-toolkit-{version}-linux-amd64.tar.gz"

wget "https://download.pingcap.org/tidb-toolkit-v5.0.3-linux-amd64.tar.gz"

一、用dumpling和lightning迁移数据

1、在原机房dumpling导出数据：

./dumpling -uroot -P 4000 -p 'jinfan' -h 10.31.1.1 --filetype sql -t 8 -o /data1/tidb_backupdata/  -r 10000000 -F 256MiB -B ff_test  -T ff_test.
test01,ff_test.test02

备注：按表导出时，表名用逗号隔开。

2、传输数据

压缩：

压缩的线程30，对cpu消耗比较大。

tar -cf - tidb_backupdata | pigz -p 30 > tidb_backupdata.tar.gz

传输

解压：

解压线程30，对cpu消耗比较大。

pigz -p 30  -d tidb_backupdata.tar.gz

tar -xf tidb_backupdata.tar.gz

3、在新机房导入数据：

配置：

tidb-lightning -config tidb-lightning.toml 

[lightning]

# 转换数据的并发数，默认为逻辑 CPU 数量，不需要配置。
# 混合部署的情况下可以配置为逻辑 CPU 的 75% 大小。
# region-concurrency =

# 日志
level = "info"
file = "tidb-lightning.log"

[tikv-importer]
# backend 设置为 tidb 模式
backend = "tidb"
 

[mydumper]
# 源数据目录。
data-source-dir = "/data3/tidb_backupdata/"

[tidb]
# 目标集群的信息。tidb-server 的监听地址，填一个即可。
host = "10.31.40.59"
port = 4004
user = "root"
password = "xxxxxxxxx"
# 表架构信息在从 TiDB 的“状态端口”获取。
status-port = 10083
# pd-server 的地址，填一个即可
pd-addr = "10.31.40.32:2385"

二、用br迁移数据

br恢复数据报错：

ERROR] [restore.go:35] ["failed to restore"] [error="No such file or directory (os error 2): [BR:KV:ErrKVDownloadFailed]download sst failed; No such file or directory (os error 2): [BR:KV:ErrKVDownloadFailed]download sst failed; No such file or directory (os error 2):

上面的报错原因，就是恢复原理没有搞清楚，在恢复时，需要在本地读取数据，因此恢复数据时也要挂载。

1 使用br迁移导出数据时，需要进行nfs挂载到老集群所有的tikv节点；

2 使用br迁移导入数据时，需要进行nfs挂载到新集群所有的tikv节点。

需要指出的是：

1 、br导出的数据是单副本的数据，因此数据量是1/3

2、br导出的数据是压缩后的数据，因此数据量是很小。

因此：br导出的数据不需要很大的磁盘，但是iops需要很高，需要ssd磁盘。

1、在原机房nfs挂载

1、server端安装

yum -y install nfs-utils rpcbind

2、编辑配置文件

vim /etc/exports 写入如下内容 /data/nfs 10.111.111.0/23(rw,sync,no_root_squash) #/data/nfs 为共享目录 #ip地址是共享的范围

3.再次修改后，执行exportfs -rv 让配置立即生效

启动server端，启动顺序是rpcbind->nfs：

systemctl start rpcbind.service

systemctl enable rpcbind.service

systemctl start nfs.service

systemctl enable nfs.service

4.查看挂载：

showmount -e server_ip

client 安装

yum install -y nfs-utils rpcbind

启动client

systemctl start rpcbind

systemctl enable rpcbind

挂载

直接（临时）挂载

mkdir /remote 

mount -o rw -t nfs 10.111.111.111:/data1/nfs   /remote

永久挂载（重启后自动挂载）

vim /etc/fstab

写入如下内容： 10.240.82.190:/data1/nfs /remote nfs defaults,_netdev 0 0

加载fstab配置立即生效生效

mount -a

注意：nfs挂载，server和client 用tidb用户导出数据，但是tidb用户在server和client 端，uid和gid可能不一致，导致client没有写入的权限，导致报错。因此解决方案，给server和client端的挂载目录都要给777的权限。

2.使用br导出数据。

./br backup table \
    --pd "10.21.17.35:2379" \
    --db ff_test \
    --table ff_test.test01 \
    --storage "local:///remote/milktea_tidb/$cur_date" \
    --ratelimit 60 \
    --check-requirements=false \
    --log-file ${bak_dir}/backup_log/${cur_date}_backuptable.log

备注：--ratelimit 60限制速度，可以减少对原实例影响。

3、压缩传输解压，参考上面

4、恢复数据

./br restore table \
    --pd "10.31.40.32:2385" \
    --db "ff_test" \
    --table "test01" \
    --storage "local:///remote/test_tidb/20241017" \
    --log-file restorefull.log    

注意：如果是空库，不要限制速度，--ratelimit 128 。这个速度是每个tikv的恢复速度，因此，不限制的话，速度很快，达到了节约时间的目的。