ProxySQL读写分离配置中的事务持久性问题解析

问题背景

在使用ProxySQL 2.3.2版本配置MySQL读写分离时，开发人员遇到了一个典型问题：尽管已经设置了详细的查询路由规则，但INSERT/UPDATE等写操作仍然被错误地路由到了从库(slave)节点，而不是预期的主库(master)节点。

初始配置分析

用户最初的配置包含了以下几个关键部分：

1. 服务器组配置：

   • 主库配置在hostgroup 10
   • 从库配置在hostgroup 30

2. 用户配置：

   • 用户test1默认路由到hostgroup 10(主库)

3. 查询规则配置：

   • 规则1：捕获所有查询但不应用(apply=0)
   • 规则2-4：分别处理DELETE、UPDATE、INSERT操作，路由到hostgroup 10(主库)
   • 规则41：默认将所有其他查询路由到hostgroup 30(从库)

问题本质

表面上看，这个配置应该能正确实现读写分离，但实际运行时写操作却被路由到了从库。这主要是因为ProxySQL在处理事务时有一个重要特性：事务持久性(transaction persistence)。

事务持久性机制

ProxySQL默认会保持事务内所有查询在同一主机组上执行，这是为了避免分布式事务带来的复杂性和潜在问题。具体表现为：

1. 当一个事务开始时，ProxySQL会"记住"第一个查询被路由到哪个主机组
2. 后续所有在该事务中的查询，无论是什么类型，都会被路由到同一个主机组
3. 只有当事务提交或回滚后，新的查询才会重新评估路由规则

解决方案

用户最终通过设置transaction_persistent=0解决了这个问题。这个参数的作用是：

• 当设置为0时：禁用事务持久性，每个查询都会独立评估路由规则
• 当设置为1时(默认值)：启用事务持久性，事务内所有查询保持在同一主机组

修改后的用户配置：

{
    username = "test1",
    password = "test1",
    default_hostgroup = 10,
    active = 1,
    default_schema = "test_schema",
    transaction_persistent = 0
}

生产环境建议

虽然禁用事务持久性可以解决这个问题，但在生产环境中需要谨慎考虑：

1. 一致性风险：事务中的读写操作可能分散在不同节点，导致数据可见性问题
2. 性能影响：跨节点事务通常比单节点事务性能更低
3. 替代方案：可以考虑使用注释(/hostgroup=/)在应用层明确指定路由

最佳实践

1. 对于简单的读写分离场景，保持transaction_persistent=1，并确保事务总是从写操作开始
2. 对于需要复杂路由的场景，可以考虑：
   • 使用SQL注释强制路由
   • 将长事务拆分为多个短事务
   • 在应用层控制查询路由逻辑

通过理解ProxySQL的事务处理机制，可以更有效地设计和调试读写分离配置，确保数据库访问既高效又可靠。