我目前在两个主节点之间双向进行 MySQL 复制，一个在本地数据中心，另一个在 Amazon EC2。
一切似乎都在复制方面正常运行，本身没有问题，除了偶尔导致冲突的查询，但这些问题很少见。最近我设置了 mysql-proxy 来尝试对两台服务器进行负载平衡，在本地机器接收到 40 个或更多连接后，负载平衡才真正开始，此时后续的数据库连接被转移到 EC2 机器上。
我们最近注意到的一点是，mysql 代理会通知我们有 41 个连接，然后开始平衡。但是，当我连接到本地计算机并执行操作时，SHOW PROCESSLIST;它可能只提供 30 个连接。
任何人都知道为什么这可能吗？
除此之外，作为发出SHOW PROCESSLIST;命令的结果，我注意到在两台机器上运行的大量查询表明它们已经运行超过 5000 秒。我很确定这些是“僵尸”查询，但是有人知道为什么首先要创建它们吗？
仅供参考我们在最新版本的 ubuntu 和 debian 上运行 mysql 版本 5.1.54。
任何想法都会非常有帮助。
[附录]
事实证明我们没有使用 mysql_pconnect，实际上使用的是 mysqli 库。我仍然无法找出发生这种情况的原因，一旦我发现就会报告。
我反对在双主机设置中同时给两个主机写信。有太多可能出错的地方，而且修复它们可能很麻烦——AUTO_INCREMENT、其他重复键等。
数百个“睡眠”连接实际上对服务器没有影响，因此限制为 40 个没有用。10 个或更多活动连接（非睡眠）可能是一个问题。在那种情况下，我会查看查询。通常优化查询是最好的答案。
还要注意，在一个主机上完成的每一次写入（插入、更新等）都必须在所有其他主机和从机上完成。所以，你不能真正地“传播”写作。
如果您有只读取 (SELECT) 的进程，那么它们应该转到 Slaves 和/或备份 Master，而不是实时的、可写的 Master。这会有所帮助。
注意“关键写入”问题。示例：用户发表博客评论，然后查看他的评论，但它不见了。如果写到一台机器，但读到另一台机器，并且复制“落后”，就会发生这种情况。
（我的评论适用于所有版本和所有 API，而不仅仅是 5.1 和 PHP 的 mysqli。）
我远离 mysql_pconnect（和其他连接池机制）。连接启动/拆卸在 MySQL 中非常快。池化连接可能与@variables、事务模式、sql_modes 等有关。