这是学习笔记的第 2228篇文章
读完需要
5
分钟
速读仅需3分钟
最近在改进一套环境的延迟问题，做了业务层的优化之后，问题得到了基本的解决，但是离我预想中的结果还是有距离，毕竟高峰期的延迟还是有20多秒，有些尴尬。
于是乎，在最近的一次高可用改造中，我们借着这个机会对这套数据库进行了升级，原本是MySQL 5.7.16版本，通过复制的模式配置了MySQL 8.0.19的Slave.
在快速切换方案落地中，整个Consul域名的切换都是2秒左右即可完成切换。
最初的环境状态是如下的拓扑关系。
经过高可用切换之后，是如下的拓扑关系。
切换验证之后，不由分说在主库开启了writeset特性。
从第二天的数据来看，对于延迟的改进效果是很明显的，如下是近6天的数据延迟情况，我仅统计了数据处理中的延迟数据，最右边的是基于MySQL 8.0的writeset的模式，Slave的延迟情况。
实际的数据都是1~4秒之内的延迟，而在前几天基于MySQL 5.7的模式基本延迟是在2~24秒之间。
当然抓取一天的数据进行分析，确实有些过急了，于是我又抓取了几天的数据。
所以两张图印证起来，结果就很明显了。
此外，有几件事情需要继续完善，无论你是对新版本观望还是在试用过程中：
1）writeset的实现原理，在binlog层如何进行分析
2）5.7版本到8.0版本升级方案如何设计，怎么验证业务层的兼容性
3）如果需要回退到MySQL 5.7版本，是否有预案，预案如何设计？
如果要升级到MySQL 8.0，可以分几个阶段走
MySQL延迟，深入逻辑解决只是时间问题
MySQL延迟问题，无脑升级到8.0不是解决之道
去IOE or Not?
拉里·佩奇（Larry Page）的伟大归来
《吊打面试官》系列-Redis基础
唯一ID生成算法剖析，看看这篇就够了
关于大数据运维能力的一些思考
DBA菜鸟的进化简史：不忘初心，记工作中踩过的三个坑
美女主持直播,被突发意外打断!湾区网友却高喊: 我懂!超甜