在我们平台上的高负载期间，我们开始在日志中看到一些来自 MySQL 的错误。这些错误的奇怪之处在于它们在实际发生后恰好 1 小时(3600 秒)出现在日志中。
例如，前几天我们进行了负载测试，在早上 8 点 30 分左右遇到了瓶颈，事情开始超时。整整 1 小时后的上午 9 点 30 分，我们开始在日志中看到以下几行，
... Zend_Db_Adapter_Mysqli_Exception [0] Lost connection to MySQL server at 'reading initial communication packet', system error: 104 ...
我一直在努力寻找与此相关的 PHP 的 mysqli 或 libmysql 的超时设置，但我正在努力寻找一个可以解释我们问题的设置。
有什么想法吗？
我最接近的是 mysqlnd.net_read_timeout ，虽然还不到 1 年，但提到了 TCP/IP 超时，在进一步谷歌搜索后我得到了 TCP session timeout ，默认情况下似乎是 3600。然而，我很清楚我可能走错了路。
谢谢
最佳答案
你的Mysql用的是主从复制吗？
如果您的主服务器宕机又重新启动，则不会立即通知从服务器。它会一直等待同一个连接，直到达到默认为 1 小时(3600 秒)的超时。超时后，它将重新连接新连接并记录导致的错误。
关于php - "Lost connection to MySQL server"错误，但实际发生后1小时？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12037457/