【SOP 系列 31 】TiDB 4.0 集群迁移实践

【 TiDB 版本】4.0.15

一、背景介绍

由于当前群集磁盘IO瓶颈,采购了一批支持PCIE的机器来替换。当前一共2套集群,9 * TiKV(共享存储)、3 * PD、4 * TIDB混合部署。使用到的组件有:TiKV、PD、TIDB、CDC、DM、PUMP、Drainer

二、存储规划

由于预算问题,当前部分节点仍使用SSD。2套集群 TiKV 仍然混部,使用不同的磁盘IO隔离。

1、14台 TiKV 节点使用2组Raid10(每组6块SSD盘),存储各5T
2、2台 TiKV 节点使用2块PCIE盘,存储各6T
3、3台 PD 节点使用1组Raid10(6块SSD盘)
4、4台 TiDB 节点使用1组Raid5(3块盘)

三、TiKV 迁移

1、扩容 TiKV

由于服务器资源共享,resource_control 对资源使用做了限制。避免互相影响。

我这边一次性把所有 TiKV 节点都扩容了,避免多次均衡数据。

tikv_servers:
- host: 172.16.10.21
  deploy_dir: /clean_data
  data_dir: /clean_data/data
  log_dir: /clean_data/log
  port: 20160
  status_port: 20180
  resource_control:
    cpu_quota: "4000%"
    memory_limit: "150G"

2、均衡数据

这里注意,4.0 以后单个TiKV 的 add-peer 和 remove-peer 受 store limit 控制。

config set leader-schedule-limit 64
config set region-schedule-limit 64
config set replica-schedule-limit 128
config set hot-region-schedule-limit 16

store limit all 128

3、缩容 TiKV

leader 与 region 都均衡了之后,需要缩容 TiKV。缩容后 region 会平均均衡到所有 TiKV。所以这边使用调整权重的方式减少旧 TiKV 上的 region,然后再缩容 TiKV,加快速度减少对线上的影响。

设置 store id 为 1 的 store 的 leader weight 为 0.1,Region weight 为 0.1。多个store可同时设置。

store weight 1 0.1 0.1

缩容 TiKV,这里每个节点执行完 scale-in 后,通过 display 查看节点状态为 Pending offline ,当所有region 迁移到其他 store 后,状态会变成 Tombstone 。tiup cluster prune cluster_name 清除墓碑,然后在继续缩容其他节点。

这里要注意,如果一个节点同时部署了多个组件,当缩容一个组件时会把监控组件同时缩容掉,导致其他组件无法使用 prune ,这里可以使用 --force 强制缩容。

四、TiCDC 迁移

老规矩,先上配置,TiCDC节点和 PD 混合部署。

cdc_servers:
- host: 172.16.10.55
  port: 8300
  deploy_dir: /clean_data/cdc
  data_dir: /clean_data/cdc/data
  log_dir: /clean_data/cdc/log
  resource_control:
    memory_limit: 300G
    cpu_quota: 2000%

先扩容后缩容节点。 这里要注意一下。 扩缩容都会导致 changfeed 迁移,并且同步延迟。为了保险起见,这边每缩容一个 cdc 节点都会等同步完全恢复后在继续缩容。

遇到一个情况,缩容后所有同步任务都延迟了。 cdc操作无效。 最后停止了所有的 cdc 节点,然后启动才恢复正常。
最后对所有 changfeed 执行一次 pause ,resume 操作保证所有同步任务正常运行。

五、PUMP 迁移

配置文件

pump_servers:
- host: 172.16.10.55
  deploy_dir: /clean_data/pump
  data_dir: /clean_data/pump/data
  log_dir: /clean_data/pump/log
  config:
    gc: 1

PUMP 迁移相对简单一些,先扩容然后缩容,最后通过 binlogctl 下线。通过show pump status查看node-id

binlogctl -pd-urls=http://172.16.10.18:2379 -cmd offline-pump -node-id 172.16.72.18:8250
binlogctl -pd-urls=http://172.16.10.18:2379 -cmd update-pump -node-id 172.16.72.18:8250 -state offline

其它注意事项:

(1)多个 pump 不能实现高可用,当 binlog.ignore-error: false ,如果其中一个 pump 挂掉,那么整个集群不可用。

(2)由 pump 异常,引起整个集群不可用时处理办法,将 binlog.ignore-error 设置为 true,并 reload tidb 节点。注意:此时所有数据都不会写入 pump,drainer 获取不到数据。

六、PD 迁移

配置文件

pd_servers:
  - host: 172.16.10.55
    deploy_dir: /clean_data/pd
    data_dir: /clean_data/pd/data
    log_dir: /clean_data/pd/log

PD 先扩容,切换 leader ,最后缩容。

获取 pd name

pd-ctl --pd="http://172.16.10.18:2379" member

切换 leader

member leader transfer "pd-172.16.10.59-2379"

七、Drainer 迁移
Drainer 独立部署的,然后用supervisorctl来进行管理的。修改下这2个参数重启就行了:addr 、
pd-urls。

八、代理迁移

前端使用的 haproxy + keepalived + 域名 的方式对外提供服务。

1、部署新的tidb节点,haproxy + keepalived(这里使用新的vip)

2、对tidb节点修改 proxy-protocol.networks ,然后重启

3、修改域名指向新的vip

到这里集群迁移就结束了。 后续还会对集群进行版本升级 4.0 -> 5.0 。