MySQL升级到8.0版本的一些经验( 三 )


 

MySQL升级到8.0版本的一些经验

文章插图
图片
 
因为上一步明确了数据库版本升级的范围是标准版和中间件集群和其他分支技术栈,则需要制定相应的升级策略 。 
 
2、标准版升级策略 
对于标准版主从来说,如果是MySQL 5.5,5.6版本,需要先过渡到MySQL 5.7,完成兼容性测试之后,观察一段时间之后 , 再次升级到MySQL 8.0;如果是MySQL 5.7版本 , 则可以直接升级到MySQL 8.0 。
 
MySQL升级到8.0版本的一些经验

文章插图
图片
 
3、中间件集群升级策略 
对于中间件集群来说,整体的思路还是做拓扑下沉,即通过级联的方式,把从库提升为主库 。
 
MySQL升级到8.0版本的一些经验

文章插图
图片
 
4、其他分支技术栈升级策略 
对于其他的分支技术栈来说,这些技术栈早期也确实解决了一些业务厄待解决的问题,随着MySQL 8.0的性能提升和集群技术的迭代,需要做一些整合 。
 
  • TokuDB迁移至TiDB
  • Infobright迁移至MySQL 8.0
  • 对于一些历史遗留业务,还需要研发协助完成数据旁路双写
 
所以整体来上来看,数据库版本升级不是单一升级到8.0,在策略上需要考虑完整 。
 
 
(三)定制化升级列表 
如果有成百上千个实例要落地升级计划,显然是一件庞大的工程,某个业务有几十个实例,断断续续地沟通,研发同学也受不了,而且整体的进度也不好控制,所以我们是从两个维度来做梳理和整合的 。 
 
  • 先按照数据库版本把所有业务的信息都梳理出来,比如MySQL 5.6,MySQL 5.7的,可以整理成不同的tab页,按照业务负责人进行汇总;
  • 然后按照不同的业务大类或者业务负责人,把上面这个数据中的信息提取出来,这样就形成了业务视角的数据库升级计划,基本就可以开始和研发同学沟通了;
  • 当然沟通也不能全靠嘴,还需要一些标准化的文档,比如我们整理了不同版本升级需要注意的事项,把整个过程需要研发协助的事情都列清楚,避免重复的解释和无效沟通;
  • 最后是回退方案,这应该是整个方案里面研发同学最关心的部分了,毕竟先把最坏的结果考虑到,一旦发现问题也能及时处理 。
 
如下是我们计划和研发同学进行的沟通的双方协作的流程 。
 
MySQL升级到8.0版本的一些经验

文章插图
图片
 
 
(四)研发驱动兼容性/功能测试 
1、数据库驱动兼容性测试 
数据库驱动测试是升级的一个关键环节 , 而且涉及到很多开发语言,所以兼容性测试是重中之重 。
 
为了避免走弯路 , 我们先期和一些研发同学一起梳理测试,整理了如下的驱动兼容性列表,这样后续的一些研发同学接入时,就可以参考了 。
 
MySQL升级到8.0版本的一些经验

文章插图
图片
 
而对于C++、.NET、Python/ target=_blank class=infotextkey>Python、php、Go、NodeJS等开发语言,兼容性变动相对较?。?芙崛缦拢?
 
MySQL升级到8.0版本的一些经验

文章插图
图片
 
除了驱动型兼容测试 , 对于MySQL的不同分支版本,也需要进一步测试SQL兼容性和其他注意事项 。
 
2、MySQL 5.5,5.6升级到MySQL 8.0的兼容性测试: 
1)针对group by语法、日期格式字段等有特定要求 
如对于group by聚合操作 , select列必须在group by中出现 , 若不在group by子句中,认为不合法 。示例:
 
mysql> select name,age from test group by name,age;+------+------+| name | age |+------+------+| aa | 18 |+------+------+1 row in set (0.00 sec)mysql> select name,age from test group by name;ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contAIns nonaggregated column 'test.test.age' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by


推荐阅读