我的主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)
尝试提升slave_net_timeout。在版本5.7.7之前，它被设置为3600，现在为60。因此，如果你在网络上遇到任何问题，从机会认为它已经失去了与服务器的连接，但当从机试图[重新]连接时，它会在主机上创建一个转储线程。在Master创建转储线程之前，它会检查是否已经有一个转储线程在为该Slave运行（使用UUID值）。如果是，它会将旧的转储线程视为"僵尸"转储线程并杀死它。创建一个新的转储线程并在错误日志文件中打印此"注意"。（引用自MySQL官方网站）实际上：在从机和上输入MySQL
mysql> set global slave_net_timeout=3600;
重新启动MySQL服务器，它应该可以解决问题。
确定后，您可以在配置文件my.conf中添加此参数，以使更改具有确定性。
这是MySQL 5.6+中的一个错误，在下一版本中修复。正如这里所解释的，主服务器试图根据其server_uuid来识别不同的从服务器，该服务器在5.6版之前是空的