记录 TiDB v5.2.3 迁移到 v6.1.0 的升级过程

网友投稿 616 2024-04-27



一.环境简介

1.1生产硬件资源

组件

记录 TiDB v5.2.3 迁移到 v6.1.0 的升级过程

CPU

内存

磁盘

网络

私网IP

公网IP

TiDB

8C

16g

100G

万兆

xxx.xxx.15.4

10.147.1.55

TiDB8C16g100G万兆

xxx.xxx.15.5

10.147.1.56

TiDB8C16g100G万兆

xxx.xxx.15.6

10.147.1.57

PD

8C

16g

100G

万兆

xxx.xxx.15.4

10.147.1.55

PD8C16g100G万兆

xxx.xxx.15.5

10.147.1.56

PD8C16g100G万兆

xxx.xxx.15.6

10.147.1.57

TiKV

8C

16g

100G

万兆

xxx.xxx.15.5

10.147.1.56

TiKV8C16g100G万兆

xxx.xxx.15.6

10.147.1.57

TiKV8C16g100G万兆

xxx.xxx.15.7

10.147.1.58

Prometheus/Grafana/Alertmanager

8C

16g

100G

万兆

xxx.xxx.15.7

10.147.1.58

1.2生产集群信息

Cluster name

Cluster version

tidb1

V5.2.3

1.3迁移数据库信息

数据库名称

数据量大小

db01

约40MB

db02

约640MB

1.4新集群硬件资源

组件

CPU

内存

磁盘

网络

私网IP

公网IP

monitor/alertmanager/prometheus/tiup

8C

16G

100G

万兆

xxx.xxx.48.4

10.141.12.180

pd1

8C

16G

100G

万兆

xxx.xxx.48.5

10.141.12.181

pd2

8C

16G

100G

万兆

xxx.xxx.48.6

10.141.12.182

pd3

8C

16G

100G

万兆

xxx.xxx.48.7

10.141.12.183

tidb1

8C

16G

100G

万兆

xxx.xxx.48.8

10.141.12.184

tidb2

8C

16G

100G

万兆

xxx.xxx.48.9

10.141.12.185

tidb3

8C

16G

100G

万兆

xxx.xxx.48.10

10.141.12.186

tidb4

8C

16G

100G

万兆

xxx.xxx.48.11

10.141.12.187

tikv1

16C

32G

200G

万兆

xxx.xxx.48.12

10.141.12.188

tikv2

16C

32G

200G

万兆

xxx.xxx.48.13

10.141.12.189

tikv3

16C

32G

200G

万兆

xxx.xxx.48.14

10.141.12.190

tikv4

16C

32G

200G

万兆

xxx.xxx.48.15

10.141.12.191

tikv5

16C

32G

200G

万兆

xxx.xxx.48.16

10.141.12.192

tikv6

16C

32G

200G

万兆

xxx.xxx.48.17

10.141.12.193

tiem

8C

16G

300G

万兆

xxx.xxx.48.18

10.141.12.194

1.5新集群信息

Cluster name

Cluster version

tidb2

V6.1.0

二.迁移前提条件

1)由于客户环境两个TiDB集群网络不相通,只能通过开放网络策略进行生产和新集群之间的连通。

2) 提前进行两个集群配置文件和系统变量参数进行收集,因为两集群版本不一样,有很多迁移后新增或删除的参数进行一个对比修改

三.迁移方案

方案一:tidb-binlog

备份恢复过程中不停机(dumpling+lightning+tidb binlog增量同步)

1.dumpling备份生产集群全量数据

2.lightning恢复全量数据到新集群

4.生产停业务

5.确认业务已停

6.部署tidb binlog进行增量同步

7.验证数据一致性

8.切应用到新集群

方案二:tidbcdc

备份恢复过程中不停机(dumpling+lightning+tidbcdc增量同步)

1.dumpling备份生产集群全量数据

2.lightning恢复全量数据到新集群

4.生产停业务

5.确认业务已停

6.部署tidbcdc进行增量同步

7.验证数据一致性

8.切应用到新集群

方案三:dumpling+lightning(建议)

1.生产停业务

2.确认业务已停

3.dumpling备份生产集群全量数据

4.lightning恢复全量数据到新集群

5.验证数据一致性

6.切应用到新集群

方案四:DM全量数据迁移和增量数据同步

1.部署DM集群

2.进行全量数据迁移和增量数据同步

3.生产停业务

4.确认业务已停

5.验证数据一致性

6.切应用到新集群

因为客户迁移数据量比较少和资源不满足组件搭建,建议使用方案三、而不采用方案一、二、四方式进行TiDB集群数据迁移。

注意:方案三没有部署增量实时同步组件,迁移过程中要保证TiDB集群业务暂停使用来保证数据的一致性。

四.迁移过程

4.1 确认业务已停

业务已停后,tidb开启全局只读模式并重启集群

4.1.1 tidb设置只读

show variables like %read_only%;

set global tidb_restricted_read_only=on;

4.1.2重启集群

show processlist;

tiup cluster restart tidb1 -R tidb

4.2逻辑导出导入

4.2.1 Dumpling导出

mkdir -p /data/backup

chown -R tidb:tidb /data/backup

cd /home/tidb/tidb-community-server-v5.2.3-linux-amd64

./dumpling -uroot -P4000 -hxxx.xxx.15.4 -p123456 --filetype sql -t 8 -r 200000 -F256MiB -o /data/backup --filter "db01.*" >> /data/backup/dumpling1.log

./dumpling -uroot -P4000 -hxxx.xxx.15.4 -p123456 --filetype sql -t 8 -r 200000 -F256MiB -o /data/backup --filter "db02.*" >> /data/backup/dumpling2.log

#查看日志是否有报错

tail -100f /data/backup/dumpling1.log

tail -100f /data/backup/dumpling2.log

4.2.2 用户和权限导出

vi /data/mysql_exp_grants.sh

#执行脚本

chmod u+x /data/mysql_exp_grants.sh

sh /data/mysql_exp_grants.sh

cat /data/backup/mysql_exp_grants_out_2022xxxx.sql

4.2.3 Lightning

#先确认新集群对应数据库没有数据

show create database db01;

show create database db02;

drop database db01;

drop database db02;

CREATE DATABASE db01 PLACEMENT POLICY czpool;

CREATE DATABASE db02 PLACEMENT POLICY zjpool;

vi /data/tidb-lightning.toml

[lightning]

level = "info"

file = "/data/backup/tidb-lightning.log"

check-requirements = true

[mydumper]

data-source-dir = "/data/backup"

character-set = "auto"

[tikv-importer]

backend = "local"

sorted-kv-dir = "/sort"

[tidb]

host = "xxx.xxx.48.8"

port = 4000

user = "root"

password = "12345678"

status-port = 10080

pd-addr = "xxx.xxx.48.5:2379"

log-level = "error"

[checkpoint]

enable = true

driver = "file"

dsn = "/data/backup/tidb_lightning_checkpoint.pb"

keep-after-success = false

4.2.4 用户和权限导入

修改/data/backup/mysql_exp_grants_out_20220905.sql

cd /data/backup/

cp mysql_exp_grants_out_2022xxxx.sql mysql_exp_grants_out_2022xxxx.sql.bak

vi mysql_exp_grants_out_2022xxxx.sql

删除root用户的

source /data/backup/mysql_exp_grants_out_20221108.sql

4.2.5 验证数据一致性

vi /home/tidb/sync-diff-inspector.toml

export-fix-sql = true

[data-sources.tidb1]

host = "xxx.xxx.1.55"

    port = 4000

    user = "root"

    password = "12345678"

[data-sources.tidb0]

    host = "xxx.xxx.12.184"

    port = 4000

    user = "root"

    password = "123456"

[task]

    output-dir = "/data/output"

    source-instances = ["tidb1"]

    target-instance = "tidb0"

    target-check-tables = ["db01.*", "db02.*"]

#执行对比

cd /home/tidb/soft/tidb-enterprise-toolkit-v6.1.0-linux-amd64/

./sync_diff_inspector --config /home/tidb/sync-diff-inspector.toml

4.2.6 新集群进行参数修改

因为旧集群修改过系统变量和参数,可能会对应用造成一定的影响。

迁移后,需要根据之前的参数进行判断修改。

4.2.7 应用切到新集群

4.2.8 取消tidb只读

set global tidb_restricted_read_only=off;

set global tidb_super_read_only=off;

tiup cluster restart tidb2

show variables like %read_only%;

五、总结

1.TiDB集群之间迁移方法有很多种,根据客户实际情况进行一个方案选择。

2.迁移前需要比对两集群参数文件和系统变量,迁移后进行参数判断修改。

3.用户权限的导出和导入,防止旧集群用户登录不了新集群。

4.迁移前,最好数据库进行设置只读模式,防止数据还有新增等意外情况。

5.因为新集群placement rule in放置策略,此导入模式需要数据库为空,删除数据库前提前记录数据库属性,迁移后进行相应配置

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:解锁 DM 数据迁移旅程分库分表协调难题
下一篇:评测 TiDB 作为 HTAP 系统的性能
相关文章