关于MySQL 8.0的writeset改进效果，放张图就可以了

这是学习笔记的第 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版本，是否有预案，预案如何设计？