如果要升级到MySQL 8.0，可以分几个阶段走

最近在推一些业务迈入MySQL 8.0,对很多同学来说，好像差别不大，对于我们来说却是一个质的变化，光看版本就能够感受出来，5.7-> 8.0，所幸我们3年前就迈入了5.7版本，多多少少也把5.7的特性都经历差不多了。

尤其是目前还处于MySQL 5.6版本的同学来说，尤其需要抓紧了。

升级到MySQL 8.0，有很多种操作方法，但是跨版本复制算是其中的一种较为平滑的方式，但是我想在这个基础上补充一些过程，首先，这个跨版本复制是有一些阶段的，其次，这个升级到过程不光是迭代的，还需要考虑完整的回退，如果出现异常情况，能够尽可能快速的回退。

鉴于此，我整理了如下的迭代升级计划，把整个升级的过程拉长，让整个过程可以和业务同学尽可能充分参与，切换过程尽可能平滑。

阶段一：

新增8.0节点，对业务不可见，有以下的基础工作：

• 验证跨版本的基础兼容性
• 修正相关参数模板
• 关注数据延迟情况
• 测试窗口函数，Hash JOIN,
• 验证版本的主要差异
• 基于GTID模式，测试完毕后可以重置GTID
• 测试DDL改进，JSON支持
• 测试clone插件和基础功能
• 完成之后可以重构从库节点 4307

阶段二：

修改端口，使得8.0版本的实例成为对业务可见的节点，有以下的任务：

• 验证查询兼容性，比如SQL_MODE等参数
• 可以先开放一部分的查询需求给业务侧
• 业务侧可以将一部分的查询需求切到从库上面测试

阶段三：

快速切换，将服务切换到8.0版本，有以下的任务：

• 实现降级版本的从库，即8.0版本的主库，5.7版本的从库
• 将5.7版本的从库链接到原5.7主库上面，使得异常情况下，可以直接降级到5.7（需要修改端口），这个过程有一些需要特别主要的点。

阶段四：

8.0版本开启writeset

阶段五（待定）

到了这个阶段，就可以灵活选择了。

异步复制模式升级为基于MGR的模式