作者:莫善

某互联网公司高级 DBA。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


一、前言

线上tidb集群都是2.1.[5,7,8,17],因版本太低,面临诸多问题,比如管理难度大,热点问题,执行计划失效,性能瓶颈,其他已知/未知且无法解决的问题,现在需要升级至4.0.13版本。在调研后发现,如果原地升级将需要多次升级【2.1–> 3.0 –> 4.0】,担心原地升级遇到不可逆的故障,更担心的是解决不掉而影响业务,所以经过测试和评估,最终采用数据迁移的方式进行升级。

因为使用2.1版本的用户本身比较少,更别提升级了,所以可参考的迁移升级文档几乎没有,在升级中遇到了很多问题,也踩了很多坑,本文整理了升级操作流程,并标记每个步骤容易遇到什么问题及解决方案,权当经验交流,避坑指南。本文所有内容/操作命令仅供参考。

  • 因5.0基于MySQL 8.0协议,担心和业务不兼容,也因为5.0+的小版本都还比较小,担心稳定性,所以就不考虑了,当时4.0.13是4.0最新的版本,就选了这个版本。
  • 已经有24套tidb集群完成了从2.1到4.0.13的升级。

二、环境介绍

1、旧集群环境介绍

  • 已有的组件
角色 数量 端口
pd 3 5017
tidb 3 4000
tikv 3 20117
alertmanager 1 9093
prometheus 1 9100
grafana 1 3000
vip 192.168.1.100 4000
dns old.tdb.com 4000
  • 未列举的组件表示未启用该组件,因历史原因,集群并没有启用pump组件。
  • 端口规划也没什么规律
  • 预计增加的组件
角色 数量 端口
pump 3 23001
drainer 1 24001

2、旧集群访问信息

dns old.tdb.com
vip 192.168.1.100:4000 rs :
192.168.1.1:4000
192.168.1.2:4000
192.168.1.3:4000

3、新集群环境介绍

角色 数量 端口
pd 3 13002
tidb 3 15002
tikv 3 17002
ticdc 3 33002
alertmanager 1 21002
prometheus 1 19002
grafana 1 20002
vip 192.168.1.100 15002
dns new.tdb.com 15002
  • 端口采用2+3的格式,前两位是组件编号,后三位表示集群编号。即后三位一样的表示同一个集群,前两位一样表示同一个组件。

4、新集群访问信息

dns new.tdb.com
vip 192.168.1.100:15002 rs :
192.168.1.1:15002
192.168.1.2:15002
192.168.1.3:15002

三、流程介绍

  • 1、dba 打印当前连接tidb的ip列表让主业务方确认是否存在非本业务的ip。确保所有使用该集群的业务都参与进来。
  • 2、dba 跟业务确认是否有重连机制。(开启binlog需要重启tidb组件)。
  • 3、dba 开启binlog,这步需要滚动重启tidb组件,需要跟业务协商一个时间窗口。
  • 4、dba 部署4.0环境并导入全量数据。
  • 5、dba 同步增量数据。
  • 6、dba 校验新旧集群数据一致性。
  • 7、dba 交付新环境,提供新的域名 + 端口。
  • 8、dba 提供只读账户,业务测试,验证业务场景(仅限读,不能写)。
  • 9、dba 同步权限。
  • 10、切换流量。

四、升级操作

1、打印旧集群访问列表

ansible # /opt/soft/mysql57/bin/mysql -u root -h old.tdb1 -P 4000 -ppassword
mysql> select distinct host from information_schema.processlist


ansible # /opt/soft/mysql57/bin/mysql -u root -h old.tdb2 -P 4000 -ppassword
mysql> select distinct host from information_schema.processlist


ansible # /opt/soft/mysql57/bin/mysql -u root -h old.tdb3 -P 4000 -ppassword
mysql> select distinct host from information_schema.processlist

登录所有tidb节点,每个节点的输出结果追加到一个文件,然后排序去重进行统计客户端ip

2、确认是否有重连机制

3、开启binlog并全量备份

这步操作在ansible管理机执行

(1)编辑配置文件

ansible # vim /path/github/tidb-ansible-2.1.8/inventory.ini
  • 添加pump组件的监控
[monitored_servers]
monitor-pump1 ansible_host=xxxx deploy_dir=/path/tidb-data/pump-23001
monitor-pump2 ansible_host=xxxx deploy_dir=/path/tidb-data/pump-23001
monitor-pump3 ansible_host=xxxx deploy_dir=/path/tidb-data/pump-23001
  • 添加pump组件
[pump_servers]
#下面三个是pump组件的机器, 如果启用pump组件还需要打开 enable_binlog = True
pump1 ansible_host=xxxx deploy_dir=/path/tidb-data/pump-23001
pump2 ansible_host=xxxx deploy_dir=/path/tidb-data/pump-23001
pump3 ansible_host=xxxx deploy_dir=/path/tidb-data/pump-23001
  • pump端口设置及启用binlog参数
## Global variables
[all:vars]
pump_port = 23001

## binlog trigger
enable_binlog = True
#enable_binlog = False

如果不设置enable_binlog = True,在部署pump的时候会被忽略。另外需要注意,在pump能提供服务前,不能重新加载tidb的配置并重启,否则会导致业务写操作失败。

(2)编辑pump的配置

ansible # vim /path/github/tidb-ansible-2.1.8/conf/pump.yml
  • 修改binlog保存周期
global:
  # a integer value to control expiry date of the binlog data, indicates for how long (in days) the binlog data would be stored. 
  # must bigger than 0
  gc: 14

改成14天,避免全量数据导入时间过长导致增量数据丢失(binlog被清理)。

(3)登录目标机器创建目录

登录各个pump节点创建目录及更改权限

ansible # ssh pump1
pump1   # mkdir -p /path/tidb-data/pump-23001
pump1   # chown -R tidb. /path/tidb-data/pump-23001


ansible # ssh pump2
pump2   # mkdir -p /path/tidb-data/pump-23001
pump2   # chown -R tidb. /path/tidb-data/pump-23001


ansible # ssh pump3
pump3   # mkdir -p /path/tidb-data/pump-23001
pump3   # chown -R tidb. /path/tidb-data/pump-23001

(4)在ansible管理机部署pump及监控

ansible # ansible-playbook deploy.yml -l monitor-pump1,monitor-pump2,monitor-pump3,pump1,pump2,pump3 -i inventory.ini

(5)在ansible管理机启动pump及监控

ansible # ansible-playbook start.yml -l monitor-pump1,monitor-pump2,monitor-pump3,pump1,pump2,pump3 -i inventory.ini

(6)登录tidb查看pump是否部署完成

ansible # /opt/soft/mysql57/bin/mysql -u root -h old.tdb.com -P 4000 -ppassword
mysql> show pump status;
+------------+------------+--------+--------------------+---------------------+
| NodeID     | Address    | State  | Max_Commit_Ts      | Update_Time         |
+------------+------------+--------+--------------------+---------------------+
| xxxx:23001 | xxxx:23001 | online | 427138948355850245 | 2021-08-20 04:42:57 |
| xxxx:23001 | xxxx:23001 | online | 427138948395171844 | 2021-08-20 04:42:57 |
| xxxx:23001 | xxxx:23001 | online | 427138948408279045 | 2021-08-20 04:42:57 |
+------------+------------+--------+--------------------+---------------------+
3 rows in set (0.00 sec)

mysql> 

需要注意,2.1.6之前的版本不支持这个查询操作,需要通过binlogctl 进行查看pump的状态,如下示例。

ansible #  /path/binlogctl -pd-urls=http://pd_host:pd_port -cmd pumps
INFO[0000] pump: {NodeID: xxxx:23001, Addr: xxxx:23001, State: online, MaxCommitTS: 432180280017551379, UpdateTime: 2021-08-20 04:45:57 +0800 CST} 
INFO[0000] pump: {NodeID: xxxx:23001, Addr: xxxx:23001, State: online, MaxCommitTS: 432180280004444167, UpdateTime: 2022-03-30 18:45:14 +0800 CST} 
INFO[0000] pump: {NodeID: xxxx:23001, Addr: xxxx:23001, State: online, MaxCommitTS: 432180280017551372, UpdateTime: 2022-03-30 18:45:14 +0800 CST} 

(7)在ansible管理机滚动重启tidb节点

执行这个操作前,一定要确保pump组件正常运行。

ansible # ansible-playbook rolling_update.yml -t tidb -i inventory.ini

需要注意的是,这个操作可能会出现ansible启动或者关闭动作失败(一直卡着直到超时),如果碰到这种情况,可以登录到目标机器手动进行启动或者停止。参考命令如下:

  • 启动 cd /path/tidb/scripts && sudo -u tidb bash start_tidb.sh
  • 停止 cd /path/tidb/scripts && sudo -u tidb bash stop_tidb.sh

(8)登录tidb检查binlog是否已经开启

ansible # /opt/soft/mysql57/bin/mysql -u root -h old.tdb.com -P 4000 -ppassword
mysql> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | 1     |
+---------------+-------+
1 row in set (0.01 sec)
  • 需要注意,2.1.6之前的版本 log_bin 恒等于 0,就是说即便enable_binlog = True,通过show variables like ‘log_bin’;查出来的也是0,但是pump会记录binlog。
  • 建议挨个tidb都检查一遍。

(9)在ansible管理机更新监控

ansible # ansible-playbook rolling_update_monitor.yml -t prometheus -i inventory.ini

(10)创建全量备份

ansible # /path/mydumper -u user -p pass -h old.tdb.com -P 4000 -t 2 -F 32 --skip-tz-utc -o /backup_path/4000 -B db_name

备份需要注意:

  • 工具获取 https://docs.pingcap.com/zh/tidb/v2.1/backup-and-restore
  • 在业务低峰进行备份,否则可能会出现网卡打满的情况(尤其是tidb是万兆网卡,tikv是千兆网卡的架构)
  • 可能会因为gc时间过短导致备份失败(通过调整gc时间解决)
  • 可能因为tidb分配的内存过小导致备份失败(通过调整tidb内存解决)
  • 备份完成后建议检查一下建表语句的文件,是否存在非法时间格式(“0000-00-00”),如果存在在导入新集群的时候会报错,需要跟业务沟通一下变更默认值。
  • mydumper不支持限流备份,可以通过备份到磁盘性能很差的机器或者cfs这种网络存储,在一定程度上实现了限流备份。

4、部署4.0环境并导入全量数据

悲观事务模型需要关注一下,4.0虽然支持悲观事务模型,而且新建集群默认也是开启状态,但是要想一个操作用到悲观锁,还是有一定的限定条件的,即非autocommit 的事务。具体请参考这个文章的【6.2.3.2部分】 https://book.tidb.io/session1/chapter6/pessimistic-txn.html

(1)安装tiup

ansible # curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
ansible # . /root/.bash_profile
ansible # tiup --version
ansible # tiup update --self

(2)准备拓扑文件

ansible # vim topology-oltp-xxx.yaml


global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/tidb-deploy"
  data_dir: "/tidb-data"
  
monitored:
  node_exporter_port: 11000
  blackbox_exporter_port: 12000
  
pd_servers:
  - host: 10.0.1.4
  - host: 10.0.1.5
  - host: 10.0.1.6

tidb_servers:
  - host: 10.0.1.1
  - host: 10.0.1.2
  - host: 10.0.1.3

tikv_servers:
  - host: 10.0.1.7
  - host: 10.0.1.8
  - host: 10.0.1.9

cdc_servers:
  - host: 10.0.1.7
  - host: 10.0.1.8
  - host: 10.0.1.9

monitoring_servers:
  - host: 10.0.1.10

grafana_servers:
  - host: 10.0.1.10

alertmanager_servers:
  - host: 10.0.1.10

以上是官方提供的配置模板,请根据实际情况修改。

  • 建议部署ticdc(pump),避免需要回滚的时候可追溯增量数据。
  • 建议每个组件单独一台机器。

(3)检查tiup 管理机到各个节点的ssh通道是否正常

(4)部署集群

ansible # tiup cluster check tidb-oltp-xxx-v4.0.13 v4.0.13 topology-oltp-xxx.yaml
ansible # tiup cluster deploy tidb-oltp-xxx-v4.0.13 v4.0.13 topology-oltp-xxx.yaml
ansible # tiup cluster start tidb-oltp-xxx-v4.0.13
ansible # tiup cluster display tidb-oltp-xxx-v4.0.13
  • check可能会报很多异常,可以根据提示进行修复,很多异常也可以忽略。请参考 https://docs.pingcap.com/zh/tidb/v4.0/tiup-component-cluster-check#tiup-cluster-check

(5)权限维护

ansible # /opt/soft/mysql57/bin/mysql -u root -h new.tdb.com -P 15002 -p
mysql> create user if not exists root@"192.168.1.%" IDENTIFIED BY 'password';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.168.1.%' WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'pd1' WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'pd2' WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'pd3' WITH GRANT OPTION;
  • 这里用空密码就能登录。
  • 这里需要加上pd节点的授权,而且要求是root用户(还是给all权限吧,测试发现给select权限不行,没做更细致的权限测试),否则dashboard不能正常使用。
ansible # /opt/soft/mysql57/bin/mysql -u root -h new.tdb.com -P 15002 -ppassword
mysql> drop user if exists root@"%";

建议删除root@’%’这个空密码用户。

(6)导入全量数据

ansible # /path/loader -d /backup_path/4000 -h new.tdb.com -u user -p password -P 15002 -t 2 -status-addr ":9299"

恢复需要注意:

  • 工具获取 https://docs.pingcap.com/zh/tidb/v2.1/backup-and-restore
  • 建议在业务低峰进行恢复
  • 可能会因为表情符导致loader失败,如果遇到,可以试试Dumpling
  • 多个loader任务的场景,建议避开默认端口,否则可能会因为端口冲突导致失败

5、同步增量数据

这步操作在ansible管理机执行

(1)在备份机获取备份点位(本例使用ansible管理机进行备份)

从备份目录查看metadata文件

ansible # cd /backup_path/xxx
ansible # cat metadata 

Started dump at: 2021-08-29 15:34:30
SHOW MASTER STATUS:
    Log: tidb-binlog
    Pos: 425971435565482001
    GTID:

Finished dump at: 2021-08-29 15:34:33
ansible # 

(2)修改配置文件

ansible # vim /path/github/tidb-ansible-2.1.8/inventory.ini
  • 添加drainer组件的监控
[monitored_servers]
monitor-drainer1 ansible_host=xxxx deploy_dir=/path/tidb-data/drainer-24001
  • 添加drainer组件
[drainer_servers]
drainer1 ansible_host=xxxx deploy_dir=/path/tidb-data/drainer-24001 initial_commit_ts="425971435565482001"
  • drainer端口设置
## Global variables
[all:vars]
drainer_port = 24001

(3)准备drainer的配置文件

ansible # vim /path/github/tidb-ansible-2.1.8/conf/drainer1_drainer.toml 

配置文件名命名规则为【别名_drainer.toml】,否则部署时无法找到自定义配置文件。

# drainer Configuration.

# the interval time (in seconds) of detect pumps' status
detect-interval = 10

# syncer Configuration.
[syncer]

# disable sync these schema
ignore-schemas = "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql"

# number of binlog events in a transaction batch
txn-batch = 2000

# work count to execute binlogs
worker-count = 32

disable-dispatch = false

# safe mode will split update to delete and insert
safe-mode = false

# downstream storage, equal to --dest-db-type
# valid values are "mysql", "pb", "tidb", "flash", "kafka"
db-type = "tidb"

# the downstream MySQL protocol database
[syncer.to]
host = "new.tdb.com"
user = "user"
password = "xxxx"
port = 15002

txn-batch 和 worker-count的配置在配置文件默认值应该是1,建议根据实际情况改大点,如果太小可能出现增量数据一直追不上的情况。

(4)部署drainer及监控

ansible # ansible-playbook deploy_drainer.yml -i inventory.ini -l drainer1
ansible # ansible-playbook deploy.yml -i inventory.ini -l monitor-drainer1

(5)登录新集群的tidb,给drainer节点授权

ansible # /opt/soft/mysql57/bin/mysql -u root -h new.tdb.com -P 15002 -ppassword
mysql> create user if not exists user@"drainer_host" IDENTIFIED BY 'xxxx';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'user'@'drainer_host';

注意:新集群(4.0)要给drainer所在的主机授权,否则启动drainer将报错,为了演示方便,这里直接给了所有权限

(6)启动drainer及监控

启动drainer前建议先确定一下目标库是否已经存在tidb_binlog库,如果存在,且又需要从备份的点位开始增量同步,这种情况需要手动删除一下,要不然drainer会从checkpoint开始同步数据。(一般出现在导入全量失败后需要重新导入全量,然后忘记清理tidb_binlog库)

ansible # ansible-playbook start_drainer.yml -i inventory.ini -l drainer1
ansible # ansible-playbook start.yml -i inventory.ini -l monitor-drainer1

(7)登录tidb检查drainer状态

ansible # /opt/soft/mysql57/bin/mysql -u root -h old.tdb.com -P 4000 -ppassword
mysql> show drainer status;
+------------+------------+--------+--------------------+---------------------+
| NodeID     | Address    | State  | Max_Commit_Ts      | Update_Time         |
+------------+------------+--------+--------------------+---------------------+
| xxxx:24001 | xxxx:24001 | online | 431972431138127904 | 2021-08-25 16:42:57 |
+------------+------------+--------+--------------------+---------------------+
1 rows in set (0.00 sec)

mysql> 

需要注意,2.1.6之前的版本不支持这个查询操作,需要通过binlogctl 进行查看drainer的状态,如下示例。

ansible #  /path/binlogctl -pd-urls=http://pd_host:pd_port -cmd drainers
INFO[0000] drainer: {NodeID: xxxx:24001, Addr: xxxx:24001, State: online, MaxCommitTS: 432180589478543384, UpdateTime: 2021-08-25 16:45:57 +0800 CST} 

(8)更新监控

ansible # ansible-playbook rolling_update_monitor.yml -t prometheus -i inventory.ini

(9)登录grafana进行查看同步进度

注意:如果同步落后比较大,可以在alertmanager将drainer的告警先禁用

6、校验新旧集群数据一致性

(1)下载工具

ansible # git clone https://gitee.com/mo-shan/check_data_for_mysql.git
ansible # cd check_data_for_mysql

(2)修改配置

  • 编辑配置文件
ansible # cd /path/check_data_for_mysql
ansible # vim conf/check.conf


mysql_user="xxxx"
mysql_passwd="xxxx"
mysql_port1="6666"
mysql_port2="6666"
mysql_host1="192.168.1.1"
mysql_host2="192.168.1.2"
max_count=10000
threads=5
max_threads_running=30
mysql_path="/opt/soft/mysql57/bin/mysql"
log_partition="/dev/sda3"
log_par_size="10"
skip_check_table=""
skip_check_db="INFORMATION_SCHEMA,METRICS_SCHEMA,PERFORMANCE_SCHEMA,mysql,sys,tidb_binlog,test,tidb_loader,dm_meta" #不建议改

请结合实际情况根据注释提示进行相关配置

  • 修改工作路径
ansible # sed -i 's#^work_dir=.*#work_dir=\"/check_data_for_mysql_path\"#g' start.sh #将这里的check_data_for_mysql_path改成check_data_for_mysql的家目录的绝对路径

(3)测试用例

  • 每次执行校验任务的时候强制要清空log目录,所以请做好校验结果的备份
  • 执行校验任务的时候强烈建议开启screen
  • 有网卡监控需求,执行监控脚本时也强烈建议单独开启screen进行监控

第一步:先开启一个screen监控网络

ansible # screen -S check_net_4000
ansible # bash manager.sh -a start
[ 2022-01-18 11:55:34 ] [ 1000 Mb/s ] [ RX : 2    MB/S ]  [ TX : 2    MB/S ]
[ 2022-01-18 11:55:35 ] [ 1000 Mb/s ] [ RX : 2    MB/S ]  [ TX : 4    MB/S ]
[ 2022-01-18 11:55:36 ] [ 1000 Mb/s ] [ RX : 2    MB/S ]  [ TX : 2    MB/S ]
[ 2022-01-18 11:55:37 ] [ 1000 Mb/s ] [ RX : 2    MB/S ]  [ TX : 3    MB/S ]
[ 2022-01-18 11:55:38 ] [ 1000 Mb/s ] [ RX : 1    MB/S ]  [ TX : 2    MB/S ]
[ 2022-01-18 11:55:39 ] [ 1000 Mb/s ] [ RX : 1    MB/S ]  [ TX : 2    MB/S ]
[ 2022-01-18 11:55:41 ] [ 1000 Mb/s ] [ RX : 1    MB/S ]  [ TX : 2    MB/S ]
[ 2022-01-18 11:55:42 ] [ 1000 Mb/s ] [ RX : 2    MB/S ]  [ TX : 8    MB/S ]

第二步:新开启一个screen执行校验任务

ansible # screen -S check_data_4000
ansible # bash start.sh -d dba -t dbatest1 -f true 
[ 2022-01-17 20:32:19 ] [ 成功 ] [ 192.168.1.1 ] [ start.sh/start.sh ] [ f_prepare:130 ] [ 本次数据一致性检查开始 ]
[ 2022-01-17 20:32:19 ] [ 警告 ] [ 192.168.1.1 ] [ start.sh/start.sh ] [ f_main:185 ] [ 本次数据一致性检查将检查如下库 : [dba] ]
[ 2022-01-17 20:32:19 ] [ 成功 ] [ 192.168.1.1 ] [ start.sh/start.sh ] [ f_main:203 ] [ 正在检查dba库 ]

[ 2022-01-17 20:32:19 ] [ 成功 ] [ 192.168.1.1 ] [ func/f_check_diff_for_mysql.sh ] [ f_check_diff_for_mysql:249 ] [ dba.dbatest1 ] [ 表结构一致 ]

[ 2022-01-17 20:32:19 ] [ 成功 ] [ 192.168.1.1 ] [ func/f_check_diff_for_mysql.sh ] [ f_check_diff_for_mysql:491 ] [ dba.dbatest1 ] [ 1,1 ] [ 00 d 00 h 00 m 00 s ] [ 9.09%, (0:0)/1 ] [ 数据一致 ]
[ 2022-01-17 20:32:19 ] [ 成功 ] [ 192.168.1.1 ] [ func/f_check_diff_for_mysql.sh ] [ f_check_diff_for_mysql:491 ] [ dba.dbatest1 ] [ 2,11 ] [ 00 d 00 h 00 m 00 s ] [ 100.00%, (0:0)/1 ] [ 数据一致 ]
[ 2022-01-17 20:32:19 ] [ 成功 ] [ 192.168.1.1 ] [ func/f_check_diff_for_mysql.sh ] [ f_check_diff_for_mysql:504 ] [ dba.dbatest1 ] [ 检查完毕 ]

[ 2022-01-17 20:32:19 ] [ 成功 ] [ 192.168.1.1 ] [ start.sh/start.sh ] [ f_main:242 ] [ 本次数据一致性检查完成 ] [ 通过 ]

ansible # 

检查结束后会提示检查通过,否则就是检查不通过。

  • 工具实现逻辑请参考 https://mp.weixin.qq.com/s/PPGSnPL-2FgRWftDzqxAOA

7、交付新环境

dba提供新的域名和端口给业务,这里给业务提供一个只读账户即可。

ansible # /opt/soft/mysql57/bin/mysql -u root -h new.tdb.com -P 15002 -ppassword
mysql> create user if not exists read_only@"host" IDENTIFIED BY 'xxxx';
mysql> GRANT SELECT ON *.* TO 'read_only'@'host';

需要注意的是,交付新环境前先不要同步权限表(mysql.user)。

8、业务验证

请业务充分验证。

9、同步权限表

tidb2.1和4.0的权限表结构不一致,所以没法通过导出导入的方式同步权限,另外经过测试使用pt工具也是不行的,下面提供一个同步权限的脚本,2.1到4.0版本测试有效,其他版本尚未测试。

#!/bin/bash
port=4000
mysql_comm="/opt/soft/mysql57/bin/mysql -u root -h old.tdb.com -P ${port} -ppassword"

for user in $(${mysql_comm} -NBe "select concat(user,'@','\"',host,'\"',':::',password) from mysql.user;" 2>/dev/null)
do
    user_tmp="$(awk -F::: '{print $1}' <<< "${user}")"
    pass_tmp="$(awk -F::: '{print $2}' <<< "${user}")"
    create_user="create user if not exists ${user_tmp} IDENTIFIED BY PASSWORD '${pass_tmp}';"
    drop_user="drop user if exists ${user_tmp};"
    grep -q "^root@" <<< "${user_tmp}" && {
            grant_user="$(${mysql_comm} -NBe "show grants for ${user_tmp}" 2>/dev/null|sed 's/$/ WITH GRANT OPTION;/g')"
        } || {
            grant_user="$(${mysql_comm} -NBe "show grants for ${user_tmp}" 2>/dev/null|sed 's/$/;/g')"
            echo "${drop_user}"
        }
    echo "${create_user}"
    echo "${grant_user}"
done

该脚本会将旧集群的权限打出来,确认无误后可以写到新集群。

ansible # bash show_grant.sh | /opt/soft/mysql57/bin/mysql -u root -h new.tdb.com -P 15002 -ppassword
  • 权限同步以后,请业务不要做授权操作,如需授权新主机或新建用户,找dba协助。
  • 非必要也请业务不要再做ddl操作,如有需求也请dba协助。

10、切换流量

  • 业务切流量前,建议将新集群的tidb挨个重启一遍,释放掉auto_increment缓存,重启完毕后需要检查drainer任务的状态及延迟,等没延迟再联系业务进行切换。
  • 如果不重启,切到新集群后自增列主键可能会报大量【Duplicate entry ” for key ‘PRIMARY’】。

这个流程其实很简单,直接将新集群的tidb主机替换到vip原来 rs列表即可,或者新申请一个vip,将原来的域名解析到新vip。但因历史问题,原来的域名和tidb端口都不符合管理规范,所以需要业务通过新的域名/端口访问tidb。

需要注意:将域名解析到新的vip,这种仅对新进来的连接起作用。

鉴于环境的特殊性,dba提供了两种方案实现让业务通过新的域名端口访问tidb。

不管采用哪种方案,在切流量以后都不建议马上下掉旧域名。推荐的做法是删除旧域名对应的vip的rs列表,将新集群的tidb节点挂到旧域名对应的vip的rs列表(需要注意新tidb端口跟旧vip端口可能不一致),这样做是避免了业务漏切的情况,观察几天dns日志,确认没业务使用旧域名后再下掉。

(1)野蛮方案

业务直接修改连接信息,使用 new.tdb.com:15002 来连接tidb。

因可能存在多个业务使用该库,而且每个服务可能有多台业务机器,做不到所有服务同一时刻都切到新库,所以会出现下面几种情况:

1)写新库,读旧库会读不到,因为新库跟旧库没有同步链路。

2)写旧库,读新库,可能会读不到,因为旧库跟新库之间存在延迟。

避免不了双写,可能会导致下面的问题。

  • A. 更新同一行数据的两个连接执行的时间极短(小于旧库到新库的同步延迟)。两个连接是分别在旧库/新库执行,这时候该行数据的最终状态不是以谁最后执行为准。比如说,先在旧库执行了【update t set name = 1 where id = 2;】,然后在新库执行【update t set name = 2 where id = 2;】,理论上这个数据的记录最终应该是name=2,但是考虑到新库到旧库的同步有延迟,这个数据就可能会被旧库的数据覆盖变成name=1。如果反过来,先写新库,再写旧库,这种情况对数据没影响。
  • B. 业务的两个连接在新库旧库分别插入同一行数据(主键一样或者唯一键一样的数据),如果先写新库,再写旧库,这样在业务端都会提交成功,但是会导致旧库到新库的同步失败,因为旧库写入的数据同步到新库就会报主键冲突(唯一键冲突),这时候就需要dba人工干预进行修复。如果反过来,先写旧库再写新库(不考虑旧库到新库的延迟),这时候写新库的会话就会报错,这种情况对数据没影响。

针对上述的情况,需要业务充分评估。如果不能接受,可以建议业务使用下面的平滑方案,这样影响面较小。

(2)平滑方案

业务继续使用 old.tdb.com:4000 这个来连接tidb。

dba需要将新集群的tidb加到旧集群的vip的rs列表,但是为了避免同时往新旧集群写数据,所以应该先将vip的rs先下掉,然后再将新集群的tidb ip加到vip rs列表。

这里涉及两个动作:

  • 将旧集群的vip的rs列表清空(下线rs),这里建议主动释放连接(重启/关闭旧集群的tidb),要不然可能会出现下掉rs后(具体需要看vip的实现机制),连接不会释放。
  • 将新集群的tidb的ip加到旧集群vip 的rs列表。

这两个操作需要跟业务确认好,因为下掉rs再重新加入有个时间差(预计30s之内),这过程集群不可用。

完成上述操作后,旧集群的访问信息会变成如下表:

dns old.tdb.com
vip 192.168.1.100:4000 rs :
192.168.1.1:15002
192.168.1.2:15002
192.168.1.3:15002

这时候业务需要挨个更新业务代码的配置,将旧域名和端口替换成新域名和端口(需要将 old.tdb.com:4000 替换成 new.tdb.com:15002 ),这时候再修改配置重启业务影响面会比较小。

五、写在最后

本文档仅做经验分享,避坑指南,因使用场景各异,各自环境也不同,在迁移过程中还可能碰上其他问题。如有线上环境操作需求,请在测试环境充分测试。


avatar
100
  Subscribe  
提醒