大家好，我是悟空。一、遇到的坑一个月前，我们在测试环境部署了一套MySQL高可用架构，就是MySQL双主+Keepalived模式。详见这篇文章：实战MySQL高可用架构这个月遇到了很多坑：因为MySQL的两个节点都可以写入，极易造成主键重复，进而导致主从同步失败。同步失败后，Slave_SQL_Thread线程停止，只有解决同步错误才能继续同步。同步失败的错误不仅会出现一条记录的问题，往往会出现大量的同步问题。两个节点缺少彼此的数据。主从同步延迟，切换到新的主库后，数据不是最新的。当出现不一致时，无法确定哪个库占上风。出现以上问题的主要原因是两个节点都支持写入+双主随时切换。该问题的解决方案包括改进自增主键的步长（影响未评估），以及使用GTID方案（未验证）。即便如此，还是存在双主同步的风险，失步后如何处理是个大问题。那么回到我们最初的想法：为什么选择双主？最初的目的是为了高可用性。双主即一个MySQL节点宕机，另一个可以在上面，对用户无动于衷，给运维人员一定的缓冲时间来排查MySQL故障。另外，旧的主节点恢复后，可以在不改变配置的情况下立即成为从节点。经过一个月的MySQL双主模式试运行，我们最终决定切换到MySQL主从模式。双主模式是指两个节点分别是主节点和从节点，所以如果我们现在切换到一主一从模式，可以认为是降级。接下来说说双主变主从的思路和步骤。2、双主模式示意图如下：两个主节点安装KeepAlived高可用组件，对外提供一个VIP。只有一个节点接管VIP，所有客户端访问请求到这个VIP，另一个节点待命。主从模式和双主的区别如下，从节点是只读的。一主一从是主从模式的一种，具有以下特点：一主一从，主节点提供对客户端的访问，从节点仅通过客户端的binlog进行数据同步主节点。从节点是只读的。从节点可以作为只读节点，提供报表查询等耗时读操作。主节点宕机后，从节点成为主节点，也是一种高可用的方案。与双主高可用方案相比，区别如下：主从切换需要使用脚本设置从库可读可写。主从切换后，需要设置从库不同步旧的主库。主从切换后，旧的主库恢复后，需要手动设置为只读，并开启同步新主库的功能。从这点来看，主从模式在异常情况下需要更多的手动操作。异常情况下，主从切换一般是这样处理的：通过脚本监控主节点是否宕机，如果主库宕机，从库会自动切换到新的主库，旧的主库后数据库恢复后，将作为新主库的数据从库同步，新主库上的Keepalived接管VIP。目前切换到主从模式有两种方式：简单方式：手动切换模式，主节点出现故障后，需要手动切换主从模式。复杂方式：高可用方式，主节点故障后，主从自动切换，读写分离自动切换。本文只涉及简单方法，复杂方法的原理和配置步骤将在下一篇文章中讲解。3.简单的变主从方式简单方式的主从切换过程如下：与双主模式下的主从切换不同的是从节点是只读的，并且Keepalived未启动。主从切换和启动Keepalived需要手动操作。修改配置的步骤如下：①为了防止从节点上的Keepalived自动接管VIP，停止从节点上的Keepalived。如果主节点出现故障，需要人工干预进行主从切换。从节点切换为主节点后，重启从节点Keepalived。systemctlstatuskeepalived②保持主节点的Keepalived，保证MySQL连接信息不需要改变。③主节点node1关闭了MySQL的同步线程。STOPSLAVE④从节点node2将MySQL设置为只读模式。#修改my.cnf文件read_only=1⑤去掉主节点node1同步node2MySQL的权限。⑥将节点node1的启动项中的自启动keepalived服务去掉。#修改启动项配置sudovim/etc/rc.local#去掉下面的脚本systemctlstartkeepalived4.综上所述，双主高可用确实有很多坑，没有硬核真的很难搞定MySQL知识。在这一个月的实践中，笔者深刻体会到了双主同步的难度，最终选择了一主一从的模式。另外，因为初始配置是双主模式，所以需要修改一些配置，改为主从模式。由于项目时间紧，采用目前非高可用主从模式。对于高可用主从模式，因为涉及的原理和步骤比较多，我会在下一篇文章中进行讲解。请给我一些时间去探索和实践。
