ProxySQL中主从切换导致错误写入副本节点的故障分析

事件背景

在使用ProxySQL 2.6.3版本管理MySQL主从复制环境时，出现了一个严重问题：ProxySQL错误地将只读副本节点识别为写入节点，导致副本节点上执行了写入操作，进而引发复制错误。这种问题在数据库高可用环境中尤为危险，可能导致数据不一致。

环境配置

该环境配置了一个典型的MySQL异步复制拓扑：

• 1个主节点（writer）
• 2个副本节点（reader）
• 3个ProxySQL实例（每个数据库节点部署一个）

ProxySQL的mysql_replication_hostgroups表配置如下：

writer_hostgroup | reader_hostgroup | check_type | comment
------------------+------------------+------------+---------
10               | 20               | read_only  |        

问题现象

通过分析日志发现以下关键事件序列：

1. ProxySQL最初将IP为xxx.xxx.xx.185的节点配置在writer hostgroup(10)中
2. 随后执行了LOAD MYSQL SERVERS TO RUNTIME命令
3. 在运行时配置中，错误地将xxx.xxx.xx.186节点放在了reader hostgroup(20)中
4. 2秒后，ProxySQL检测到配置错误并自动修正：
   • 发现xxx.xxx.xx.186节点的read_only=0但不在writer组
   • 发现xxx.xxx.xx.185节点的read_only=1但不在reader组
5. 在这短暂的错误配置期间，应用可能向副本节点执行了写入操作

根本原因分析

1. 配置管理不当：在手动执行主从切换后，没有正确更新ProxySQL的服务器配置，导致ProxySQL运行时使用了过期的配置信息。

2. 权限控制缺陷：应用账户拥有SUPER权限，使得即使read_only=1的情况下也能执行写入操作，这违反了最小权限原则。

3. 配置传播延迟：ProxySQL需要几秒钟时间来自动检测和修正错误的配置，这个时间窗口可能导致问题发生。

解决方案与最佳实践

1. 正确的配置管理：

   • 在主从切换后，应立即更新ProxySQL配置
   • 建议使用自动化工具管理配置变更，减少人为错误

2. 权限最小化：

   • 移除应用账户的SUPER权限
   • 确保read_only=1时副本节点真正不可写

3. ProxySQL配置优化：

   • 初始配置时将所有节点放在reader组，让ProxySQL自动发现writer
   • 使用SAVE MYSQL SERVERS TO DISK保存正确的配置

4. 监控与告警：

   • 监控ProxySQL的日志中是否有配置修正事件
   • 设置告警当检测到副本节点有写入操作时

技术深度解析

ProxySQL的读写分离机制基于read_only变量和hostgroup配置。当检测到以下情况时会自动调整：

1. 节点read_only=0但不在writer组 → 移动到writer组
2. 节点read_only=1但不在reader组 → 移动到reader组

这种机制在配置正确时非常可靠，但如果初始配置错误，需要短暂的自我修正时间。在生产环境中，应该通过以下方式增强可靠性：

• 使用ProxySQL的集群功能保持配置一致
• 实现配置变更的预检查和回滚机制
• 定期验证配置与实际拓扑的一致性

总结

ProxySQL作为高性能的MySQL中间件，其读写分离功能强大但需要正确配置。本次故障揭示了在数据库拓扑变更时的配置管理重要性。通过实施严格的配置管理流程、权限控制和监控机制，可以避免类似问题的发生，确保数据库环境的高可用性和数据一致性。