自学内容网 自学内容网

br实现大数据量的tidb机房迁移

要进行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、在新机房导入数据:

配置:

[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的恢复速度,因此,不限制的话,速度很快,达到了节约时间的目的。


原文地址:https://blog.csdn.net/u012565458/article/details/143080400

免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!