一个月后，我们为何又从MySQL双主切换成了主改写？

本文共计1922个文字，预计阅读时间需要8分钟。

这是第157篇原创文章，官网：www.passjava.cn，你好，我是悟空。

一、遇到的坑一个月前，我们在测试环境部署了一套MySQL高可用架构，采用的是MySQL双主+Keepalived的模式。

这是悟空的第 157 篇原创文章

官网：www.passjava.cn

你好，我是悟空。

一、遇到的坑

一个月前，我们在测试环境部署了一套 MySQL 高可用架构，也就是 MySQL 双主 + Keepalived 的模式。详情看这篇：

实战 MySQL 高可用架构

在这一个月遇到了很多坑：

• 因为两个 MySQL 节点都可以写入，极其容易造成主键重复，进而导致主从同步失败。
• 同步失败后，Slave_SQL_Thread 线程就停了，除非解决了同步的错误，才能继续进行同步。
• 同步失败的错误，不会只有一条记录有问题，往往是一大片的同步问题。
• 两个节点互相缺少对方的数据。
• 主从的同步延迟，切换到新主库后，数据不是最新。
• 当出现不一致时，无法确定以哪个库为准。

造成上面问题的主要原因就是因为两个节点都支持写入 + 双主可以随时切换。

解决这种问题的方案有 改进自增主键的步长（影响未评估），使用 GTID 方案（未验证）。即使这样，双主同步的风险还是有，而且不同步后，如何处理是个大难题。

那么回到我们最初的想法：为什么会选择双主？

最开始的目的就是为了高可用。双主就是说有一台 MySQL 节点挂了，另外一台能够顶上，对于用户来说是无感的，给运维人员一定的缓冲时间来排查 MySQL 故障。