ProxySQL中Admin接口并发查询stats表导致的死锁问题分析

问题背景

ProxySQL作为高性能的MySQL中间件，其Admin接口提供了丰富的监控统计功能。在v2.5.2至v2.5.5版本中，存在一个潜在的Admin接口死锁问题，当多个Admin连接并发查询某些统计表时，可能导致整个Admin接口不可用。

死锁发生机制

该问题的核心在于SQLite数据库连接的事务处理与ProxySQL内部锁机制的交互问题。具体表现为：

1. 事务开启阶段：当一个Admin会话执行需要刷新统计信息的查询（如查询stats_proxysql_servers_checksums表）时，会启动一个SQLite事务，同时持有Admin全局互斥锁。

2. 并发查询阶段：此时若有另一个Admin会话尝试查询某些特定的统计表（如stats_mysql_gtid_executed），它会在等待获取全局互斥锁后被放行。

3. 锁竞争阶段：第一个会话释放全局互斥锁后，第二个会话获得执行权。但由于第一个会话的SQLite事务尚未提交，当第二个会话尝试执行清理操作时，会遇到SQLITE_LOCKED错误。

4. 死锁形成：系统进入重试循环等待锁释放，而第一个会话又在等待第二个会话释放的全局互斥锁，从而形成典型的死锁场景。

技术细节分析

问题的关键在于ProxySQL内部对SQLite连接的管理方式。ProxySQL使用两个独立的SQLite连接：

• admindb：用于常规Admin操作
• statsdb：专门处理统计信息

当Admin用户查询统计表时，系统会使用statsdb连接。但在某些特定路径下（如查询stats_mysql_gtid_executed表），执行流程会到达vacuum_stats函数，该函数默认使用admindb连接尝试清理统计表。此时如果statsdb连接上有未提交的事务，就会导致SQLite报告锁冲突。

影响范围

该问题主要影响以下场景：

• 使用Admin账户并发查询统计信息
• 查询涉及需要刷新统计信息的表（如stats_proxysql_servers_checksums）
• 同时有其他Admin会话查询特定统计表（如stats_mysql_gtid_executed）

一旦触发，将导致Admin接口完全不可用，所有Admin连接都会被阻塞。

解决方案与最佳实践

该问题已在后续版本中修复，修复方案主要涉及：

1. 优化事务处理逻辑，确保及时提交
2. 改进锁获取顺序，避免循环等待
3. 增强错误处理机制，防止无限重试

对于使用受影响版本的用户，建议：

1. 升级到已修复的版本
2. 避免在Admin接口上并发执行统计查询
3. 对于自动化监控工具，适当增加查询间隔
4. 考虑使用专门的监控账户而非Admin账户查询统计信息

总结

ProxySQL的这个死锁问题展示了数据库中间件中锁管理和事务处理的复杂性。开发者在设计类似系统时，需要特别注意：

• 不同数据库连接间的事务隔离
• 锁获取的顺序一致性
• 错误处理的重试机制
• 并发场景下的资源竞争

通过分析这类问题，我们可以更好地理解数据库中间件的内部工作原理，并在实际使用中避免类似问题的发生。