这是学习笔记的第 2228篇文章
读完需要
速读仅需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版本，是否有预案，预案如何设计？
相关链接：
QQ群号：763628645
QQ群二维码如下， 添加请注明：姓名+地区+职位，否则不予通过
订阅我的微信公众号“杨建荣的学习笔记”，第一时间免费收到文章更新。别忘了加星标，以免错过新推送提示。
7
近期热文
你可能也会对以下话题感兴趣。点击链接就可以查看。
8
转载热文
你可能也会对以下话题感兴趣，文章来源于转载，点击链接就可以查看。
