我在MySQL中遇到FEDERATED表的一个问题。我有一个服务器（MySQL版本5.0.51a），用于存储客户端数据，实际上没有更多。逻辑数据库存储在另一个服务器（版本5.1.56）中，有时它应该处理来自第一个服务器的数据。所以第二台服务器有一个FEDERATED表，它连接到第一台服务器。
实际上，它没有任何问题，但最近我遇到了这个解决方案的奇怪错误。无法正确执行第二台服务器上的某种查询。
例如SELECT * FROM table - 不起作用。它正好挂了3分钟然后给出：
错误代码：1159读取通信数据包超时
好的，我检查了第一台服务器上的表，确定没问题。然后我尝试了另一个查询到FEDERATED表，他们工作......
例如，SELECT * FROM table WHERE id=x之类的查询会返回结果。可能它可能有结果大小的问题，所以我尝试使用虚拟WHERE - 像SELECT * FROM table WHERE id > 0这样的子句进行查询 - 它也有效......
最后我找到了一个“解决方案”，它只帮助了两天 - 在第一台服务器上我制作了一份表副本，在第二台服务器上我重新声明了一个新的FEDERATED表，其中包含新的连接字符串这个副本。并且它可以工作，但是在两天之后新复制的表格出现同样的问题。
我已经与两家服务器供应商进行了交谈，他们认为没有问题，一切似乎都有效，其他托管服务提供商也是问题的主要原因。
我已经检查了MySQL中的所有变量，并且没有3分钟的超时参数等等。那么我怎么能处理这样的问题呢？它似乎是网络或数据库方面的自动化东西，但我不知道，如何检测问题的原因。
你有什么想法吗？
答案 0 :(得分：0)
您可以尝试检查两台服务器上网络接口的MTU大小设置。
答案 1 :(得分：0)
当wait_timeout杀死空闲线程时，会记录此警告。
通常，避免线程被wait_timeout杀死的方法是在不再需要连接时在脚本中调用mysql_close（）。遗憾的是，这对通过联合表进行的查询不起作用，因为查询和连接不在同一服务器上。
例如，当在联合表的服务器A上执行查询（指向服务器B上的数据）时，它会在服务器B上创建连接。然后，当您在服务器A上运行mysql_close（）时，它显然无法关闭在服务器B上创建的连接。
最终在＆＃34; wait_timeout ＆＃34;中指定的秒数后，连接被mysql杀死。已通过（默认为8小时）。这会在你的mysqlerror.log＆＃34; 读取通信包的超时＆＃34;
中生成警告