PolarDB读写分离失效排查与解决方案

1. 问题背景与现象描述

那天早上刚开工，开发团队就火急火燎地找到我，说他们的PolarDB 8.02集群出现了异常情况。监控显示所有的SELECT查询都集中在主节点（写节点）上执行，而只读节点（从节点）却完全处于闲置状态。这直接导致主节点的CPU使用率飙升到80%以上，而从节点的CPU使用率却不到5%。

这种情况在PolarDB的使用中并不常见，因为PolarDB的代理层（Proxy）通常会智能地将读请求分发到只读节点，以减轻主节点的压力。根据我的经验，这种"只读节点罢工"的现象通常由以下几种情况引起：

1. 连接地址配置错误：应用程序可能错误地连接到了主节点的独立地址，而非集群地址。集群地址是PolarDB实现读写分离的关键，它会自动将读请求路由到只读节点。

2. 显式事务使用不当：如果在SQL语句中显式使用了BEGIN;...COMMIT;事务块，而非依赖autocommit=1的自动提交模式，PolarDB会将这些查询视为事务的一部分，默认全部路由到主节点执行。

3. 混合读写事务：当一个事务中同时包含写操作（INSERT/UPDATE/DELETE）和读操作（SELECT）时，并且写操作在前，PolarDB会将该事务的所有操作都路由到主节点。

2. 初步排查与错误假设

开发团队坚称他们没有使用显式事务，也没有在事务中混合读写操作。这让我一度怀疑是否是PolarDB的代理层出现了问题。为了验证这一点，我做了以下测试：

1. 简单查询测试：执行SELECT SLEEP(10)这样的简单查询，确认能够正常路由到只读节点。这说明PolarDB的基础读写分离功能是正常的。

2. 压力测试：让同事用Python编写了一个并发测试脚本，模拟生产环境的查询压力。奇怪的是，测试中主节点的负载明显上升，而从节点依然没有接收到任何查询请求。

这个结果让我更加困