MySQL主从复制问题引起的架构优化思考

共计 1901 个字符，预计需要花费 5 分钟才能阅读完成。

1. 存在问题

MySQL 主从复制架构多次出现复制停滞问题如 1032 错误和 1062 错误，其中，1032 错误是在主库成功执行后在从库 update 或 delete 时发现从库上找不到这条记录，1062 错误是在主库 insert 完成后在从库执行时出现主键冲突无法成功 insert，这些问题可通过跳过错误和前面的复制数据校验修复来解决，但是这些问题产生的直接原因都是主从库数据不一致。这种不一致除了逻辑复制本身可能出现的数据不一致，还有个原因是业务侧或开发人员违规在备库上直接进行增删改操作导致的。

在主从复制架构中，主从库通过 VIP 绑定实现指定库作为主库，提供读写，从库起 backup 的作用，当主库出现问题时，VIP 切换到从库，从库提供读写，否则从库只是 backup。正常情况下，我们不允许开发人员直接通过固定 IP 登录从库操作，但实际工作中往往又难以规避，那么如何从技术角度去避免开发人员在备库操作呢？又如何在避免的同时不影响高可用架构的正常运行和故障切换呢？

2. 架构配置优化

（1）直接解决办法

解决上述问题的直接办法是考虑进行架构配置优化，即将从库可读写的状态配置为只读状态。

MySQL 官网关于只读有下列描述：

1.Whenthe

read_only system variable is enabled, the server permits no client updatesexcept from users who have

the SUPER privilege.

只读情况下，super 权限可读写。

2.Updates performed by

slave threads, if theserver is a replication slave. In replication setups, it can be useful toenable

read_only on slave servers to ensure that slaves accept updates only from themaster server and not from clients. 不影响主从复制线程的读写。

开启只读后，除了 super 权限账户和复制线程等不受影响外，业务侧开发人员和其它人员即使登录备库也无法操作备库数据。

MySQL [db1]> show global variables like’read_only%’;

+—————+——-+

| Variable_name | Value |

+—————+——-+

| read_only    | ON  |

+—————+——-+

1 row in set (0.00 sec)

MySQL [test]> insert child values(‘1′,’12’);

ERROR 1290 (HY000): The MySQL server is running withthe

–read-only option so it cannot
 execute thisstatement

（2）配置为只读后如何进行完美故障切换？

从库只读可避免违规操作，但面临的问题是如果主库发生问题，VIP 要切换到从库上，但这时候从库只读会导致数据库对外服务不可用，因此在切换时需要实现取消从库只读同时设置主库只读的功能。

以 Keepalived+MySQL 双主（主从）架构为例，正常运行时，VIP 在 Master1 上，Master1 为可读写状态，Master2 为 readonly 状态，一旦 Master1 发生问题，VIP 要自动切换至 Master2，切换前要完成两个步骤：1. 将 Master1 置为 readonly；2. 取消 Master2 的 readonly。

3. 自动化实现思路

对于一主一从架构，故障切换需要手工进行，因此上述两步也可以手工操作；但 Keepalived+MySQL 双主（主从）架构中，已实现故障的自动监测和 VIP 自动切换，上述两个步骤也应该植入脚本中实现自动化。

我们主要需在自动监测和切换脚本中植入对数据库开启 readonly 和关闭 readonly 的函数，主要写入语句“set
 global read_only=ON”和“set globalread_only=OFF”，同时注意在设置状态之前先判断现有状态，shell 调用语句“show
 variables like ‘read_only’;”得到读写状态，确认读写状态后再设置 readonly 参数为所需状态即可，注意这些状态设置的触发定制在监测到故障并执行切换之前。

上述思路现已完成自动化转换，亲测成功，说明思路正确。

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-02/141112.htm