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

相关推荐
赵渝强老师1 天前
【赵渝强老师】TiDB SQL层的工作机制
数据库·sql·tidb
观测云9 天前
TiDB 可观测性最佳实践
tidb
赵渝强老师12 天前
【赵渝强老师】使用TiDB的审计日志
数据库·tidb
可观测性用观测云14 天前
TiDB 可观测性最佳实践
tidb
Sirius Wu14 天前
TiDB 深度解析与 K8S 实战指南
容器·kubernetes·tidb
PingCAP15 天前
PingCAP“一号员工”唐刘:回顾我与 TiDB 的十年成长之旅
数据库·tidb
转转技术团队16 天前
告别人工搬运!TiDB/MySQL双库同步工具如何为业务提效100%?
mysql·tidb·测试
MiniFlyZt21 天前
分布式数据库TiDB:架构、核心特性与生产实践(分库分表)
java·数据库·分布式·spring cloud·微服务·tidb
PingCAP22 天前
从单一到多活,麦当劳中国的数据库架构迁移实战
数据库·tidb
XMYX-01 个月前
TiDB 部署指南(单机模式)& CentOS 7 安装 MariaDB 教程
centos·tidb·mariadb