概要描述
kundb 2.1.6 版本为稳定 LTS 版本，建议现场均升级至该 kundb 版本；本文介绍以 kundb 数据迁移的方式实现 kundb 的升级；
本文档适用于升级到KunDB 2.1.6
txsql 的迁移，参见 txsql 迁移至 kundb
详细说明
- 新装 kundb-2.1.6
- 检查工作
- 停止依赖 kundb 的服务
- 导出用户以及权限
- 导出数据
- 停止旧 kundb，启动新 kundb
- 导入用户以及权限
- 导入数据
新装 kundb-2.1.6 （跳过）
安装 新的 kundb 时，一定要检查旧的 kundb 大小写敏感的参数,值为 0 则是大小写敏感;
show variables like "%lower_case_table_names%";
此时安装 kundb 时，需要增加自定义参数:
kundb.lower_case_table_names=false
注意：kundb.lower_case_table_names ，部署后无法修改；
不同版本间该参数默认值可能不一致，需要额外注意。
检查工作（非常重要）
1、注意原数据库是否存在myisam表
如果客户业务库存在myisam表，需修改成innodb。
--检查是否存在myisam表，后台登录kundb命令行执行
select table_schema,table_name,engine from information_schema.tables where engine ="myisam" ;
2、检查原数据库binlog同步模式，保证binlog_format=row。
--检查binlog格式是否为ROW，后台登录kundb命令行执行
show variables like 'binlog_format';
3、检查orchestrator流水正常
务必确认主从数据同步正常，参考 KunDB集群巡检 检查
4、检查主节点的数据量大小
# 默认路径/mnt/disk*/kundb*/vt_00000000*/目录下
du -sh data该数据可以与迁移时数据导入做对比，总大小会存在一些误差但可以通过该文件大小预估迁移时长。
5、检查是否存在分区表，如有分区表检查是否所有分区表都存在主键/唯一索引。
--检查是否存在分区表
select table_schema,table_name from information_schema.tables where create_options like "%partitioned%" ;
--检查是否分区表存在主键/唯一索引
select a.TABLE_SCHEMA,a.TABLE_NAME from information_schema.statistics a,information_schema.tables b where b.create_options like "%partitioned%" and a.NON_UNIQUE=0 and b.TABLE_NAME = a.TABLE_NAME and b.TABLE_SCHEMA=a.TABLE_SCHEMA;
如果上述第二个 sql 里包含了第一个sql所有的库和表，则代表其中所有分区表都存在主键/唯一索引，无需改造，否则需要具体情况具体分析。
停止依赖 kundb 的服务
旧的 kundb ，查看依赖关系，可以看到依赖 kundb 的服务；
然后停止对应的服务即可，比如这里的 inceptor1 和 foundation1；
导出用户以及权限
说明一：” -hslave9 -P15307 -uvt_app -ptranswarp “ 为kundb gate的连接方式(应用一般都是通过gate访问kundb)
mysql -N -e "select distinct user from mysql.user" -hslave9 -P15307 -uvt_app -ptranswarp| grep -Evx "clone_user|vt_app|orc_client_user|root|vt_repl|mysql.infoschema|mysql.session|mysql.sys|vt_allprivs|vt_appdebug|vt_dba|vt_filtered|kundb_dba|vt_meta_user|kun_monitor"|xargs -I {} mysql -N -hslave9 -P15307 -uvt_app -ptranswarp -e 'show create user 导出数据 （pod内完成操作，操作完成后需要将数据文件移动到pod外）
nohup mysql -N -e "show databases;" --socket=/vdir/mnt/disk1/kundb9/vt_0000000001/mysql.sock 2>/dev/null| grep -Evx "information_schema|mysql|_vt|performance_schema|sys"|xargs mysqldump --socket=/vdir/mnt/disk1/kundb9/vt_0000000001/mysql.sock --single-transaction --master-data=2 --set-gtid-purged=off --skip-add-drop-table --hex-blob --triggers --routines --databases > kundb1.sql &说明四：:此处可能出现的问题说明，如不存在请忽略
grants.sql内可能存在部分权限无法执行，如 AUDIT_ABORT_EXEMPT, FIREWALL_EXEMPT, FIREWALL_EXEMPT, PASSWORDLESS_USER_ADMIN, SENSITIVE_VARIABLES_OBSERVER 等权限诺存在，则需手动剔除掉方能执行
说明五：如果 head 查看导出数据文件 kundb1.sql 发现一些类似warning的报错，需要手动删掉，如：
WARNING: --master-data is deprecated and will be removed in a future version. Use --source-data instead.使用sed命令删除，下面’1d’代表删除第一行
sed -i '1d' kundb1.sql说明六：导出完毕后检查tail kundb1.sql 查看是否有正常导出结束标志如下：
-- Dump completed on 2023-02-21 03:35:16其他变化，kundb2.1.6及以后版本备份数据方式发生变化（底层root用户已经加密，无法直接连接底层）
nohup mysql -N -e "show databases;" -h192.168.128.23 -P15806 -uvt_app -p'M3BA1Po%as1Kse8Jt!aC' 2>/dev/null| grep -Evx "information_schema|mysql|_vt|performance_schema|sys"|xargs mysqldump -h192.168.128.23 -P15806 -uvt_app -p'M3BA1Po%as1Kse8Jt!aC' --single-transaction --source-data=2 --set-gtid-purged=off --skip-add-drop-table --hex-blob --triggers --routines --databases > kundb1.sql &参数说明:
-h192.168.128.23，主节点的IP，可通过执行
select * from performance_schema.replication_group_members; 获取 primary 节点
-p’M3BA1Po%as1Kse8Jt!aC’，底层 vt_app 固定用户密码（禁止修改底层密码）
-P15806，底层mysqld的端口，可通过在192.168.128.23的pod内执行 ps -ef|grep mysqld 获取
导入用户数据和权限到新 kundb
连接新kundb的kungate端口号，进行如下操作，其中 slave9:25307为新kundb的kungate连接地址：
nohup mysql -hslave9 -P25307 -uvt_app -p'transwarp' -e 'source createuser.sql' &
nohup mysql -hslave9 -P25307 -uvt_app -p'transwarp' -e 'source grants.sql' &导入旧版本kundb数据到新版kundb （注意需先执行完第4步操作 source用户数据和权限）
连接新kundb的kungate端口号，进行如下操作，其中slave9:25307为新kundb的kungate连接地址：
nohup mysql -hslave9 -P25307 -uvt_app -p'transwarp' -e 'source kundb1.sql' &等待数据全部导入后，tds等组件变更依赖后，配置服务重新启动，观察是否正常，诺无异常，本次升级到此结束