Question

我在下面不断登录我的主mysql服务器。我已经用谷歌搜索了它，但没有运气。

任何人都可以给我任何建议。

2016-07-21T08:17:43.765005Z 41323 [Note] Start binlog_dump to master_thread_id(41323) slave_server(4), pos(, 4)
2016-07-21T08:17:51.598518Z 41324 [Note] While initializing dump thread for slave with UUID <5dbbd9c5-2963-11e5-9b69-1458d042a2f8>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread.
2016-07-21T08:17:51.615993Z 41324 [Note] Start binlog_dump to master_thread_id(41324) slave_server(3), pos(, 4)
2016-07-21T08:18:12.578065Z 41326 [Note] While initializing dump thread for slave with UUID <60f57c3e-2963-11e5-9b69-1458d057f760>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread.
2016-07-21T08:18:12.656642Z 41326 [Note] Start binlog_dump to master_thread_id(41326) slave_server(1), pos(, 4)

Answer 1

尝试提升slave_net_timeout。在版本5.7.7之前，它设置为3600，现在设置为60.因此，如果您在网络上遇到任何问题，从属设备会认为它已经失去了与服务器的连接，但是当一个Slave尝试[重新]时，连接，它在Master上创建一个转储线程。在Master创建转储线程之前，它会检查是否已经为该Slave运行了转储线程（使用UUID值）。如果是，它认为旧的转储线程为“Zombie”转储线程并将其杀死。创建一个新的并在错误日志文件中打印此“注释”。（引自the official MySQL site）实际上：在从机上输入MySQL并

mysql> set global slave_net_timeout=3600;

重新启动MySQL服务器，它应该可以解决问题。

一旦这样就可以了，您可以在配置文件my.conf中添加此参数，以使更改成为确定。

Answer 2

这是MySQL 5.6+中的一个错误，已在下一版本中修复。 As explained here，主人试图根据他们的server_uuid识别不同的奴隶，这在5.6之前是空的

MySQL Zombie转储线程

2 个答案: