关于tidb:技术分享-tidb-21升级到40操作文档

作者：shadow | 来源：互联网 | 2023-05-19 18:35

线上tidb集群都是2.1.[5,7,8,17]，因版本太低，面临诸多问题，比方治理难度大，热点问题，执行打算生效，性能瓶颈，其余已知未知且无奈解决的问题，当初须要降级至4.0.13版本。在调研后发现，如果原地降级将须要屡次降级【2.1-->3.0-->4.0】，放心原地降级遇到不可逆的故障，更放心的是解决不掉而影响业务，所

作者：莫善

某互联网公司高级 DBA。

本文起源：原创投稿

*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

一、前言

线上tidb集群都是2.1.[5,7,8,17]，因版本太低，面临诸多问题，比方治理难度大，热点问题，执行打算生效，性能瓶颈，其余已知/未知且无奈解决的问题，当初须要降级至4.0.13版本。在调研后发现，如果原地降级将须要屡次降级【2.1&＃8211;> 3.0 &＃8211;> 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 &＃8216;log_bin&＃8217;;查出来的也是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/t&＃8230;

在业务低峰进行备份，否则可能会呈现网卡打满的状况（尤其是tidb是万兆网卡，tikv是千兆网卡的架构）

可能会因为gc工夫过短导致备份失败（通过调整gc工夫解决）

可能因为tidb调配的内存过小导致备份失败（通过调整tidb内存解决）

备份实现后倡议检查一下建表语句的文件，是否存在非法工夫格局(&＃8220;0000-00-00&＃8221;)，如果存在在导入新集群的时候会报错，须要跟业务沟通一下变更默认值。

mydumper不反对限流备份，能够通过备份到磁盘性能很差的机器或者cfs这种网络存储，在肯定水平上实现了限流备份。

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

乐观事务模型须要关注一下，4.0尽管反对乐观事务模型，而且新建集群默认也是开启状态，然而要想一个操作用到乐观锁，还是有肯定的限定条件的，即非autocommit 的事务。具体请参考这个文章的【6.2.3.2局部】 https://book.tidb.io/session1&＃8230;

（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/t&＃8230;

（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@&＃8217;%&＃8217;这个空明码用户。

（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/t&＃8230;

倡议在业务低峰进行复原

可能会因为表情符导致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/PP&＃8230;

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 &＃8221; for key &＃8216;PRIMARY&＃8217;】。

这个流程其实很简略，间接将新集群的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 ），这时候再批改配置重启业务影响面会比拟小。

五、写在最初

本文档仅做教训分享，避坑指南，因应用场景各异，各自环境也不同，在迁徙过程中还可能碰上其余问题。如有线上环境操作需要，请在测试环境充沛测试。

关于tidb:技术分享-tidb-21升级到40操作文档

一、前言

二、环境介绍

1、旧集群环境介绍

2、旧集群访问信息

3、新集群环境介绍

4、新集群访问信息

三、流程介绍

四、降级操作

1、打印旧集群拜访列表

2、确认是否有重连机制

3、开启binlog并全量备份

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

5、同步增量数据

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

7、交付新环境

8、业务验证

9、同步权限表

10、切换流量

五、写在最初

如何使用Java获取服务器硬件信息和磁盘负载率

LVS 实现负载均衡的原理

kubeadm构建k8s之Prometheusoperated监控(0.18.1)

go实现重新给metric打标签上传到prometheus_案例分析｜云原生监控Prometheus对样本rate计算，出现标签重复？...

clone的fork与pthread_create创建线程有何不同

RouterOS 5.16软路由安装图解教程

解决github访问慢的问题的方法集锦

如何进行Web.Config自定义配置节的配置转换

Ubuntu系统清理残余配置文件和无用内容的方法

腾达n630 v2怎么设？

centos查看系统版本,linux安装centos

http头_http头部注入

03Spring使用注解方式注入

关于数据库:PingCAP-CTO-黄东旭-基础软件好用指南必须跨越这两道鸿沟

关于go-zero:gozero-dockercompose-搭建课件服务六完善jwt鉴权和返回结构