author：sufei
一、现象
在生产环境遇到如下现象：
即矛盾的结果：
- 主库的MySQL processlist明明可以看到dump线程，说明有从库在进行dump逻辑；
- show slave hosts为空，即无法从主库查到从库状态；
二、原因分析
根据现象，合理地猜测，存在用户执行了dump_gtid逻辑，也就是复制binlog逻辑，但是该线程不在slave_list列表中。我们知道当一个从库连接到主库执行GTID复制命令时，主要执行以下步骤：
1、执行COM_REGISTER_SLAVE命令，即调用register_slave完成从库注册（也就是插入slave_list列表）；
2、执行COM_BINLOG_DUMP_GTID命令，即调用com_binlog_dump_gtid循环发送binlog给从库；
目前现象是，存在dump_gtid命令地执行，但注册列表中没有相关从库信息，存在两种可能：
- 从库没有执行register指令，直接执行dump执行；这个情况可以排除，一般只有在自己模拟从库的程序中才会如此忽略，官方从库逻辑都是先进行register，再进行dump；
- 从库进行了register，但是在某些情况被unregister了，但是dump线程没有被kill。查看unregister情况有如下几种：
1、从库register注册过程中通过server_id查找（即在register_slave函数中），把相同地server_id的旧实例unregister移除；这种情况是避免相同从库在主库存在两个复制线程；
mysql_mutex_lock(&LOCK_slave_list);
unregister_slave(thd, false, false/*need_lock_slave_list=false*/);
res= my_hash_insert(&slave_list, (uchar*) si);
mysql_mutex_unlock(&LOCK_slave_list);
// unregister_slave函数具体如下，其通过server_id进行从库是否相同判断
void unregister_slave(THD* thd, bool only_mine, bool need_lock_slave_list)
{
if (thd->server_id && my_hash_inited(&slave_list))
{
if (need_lock_slave_list)
mysql_mutex_lock(&LOCK_slave_list);
else
mysql_mutex_assert_owner(&LOCK_slave_list);
SLAVE_INFO* old_si;
if ((old_si = (SLAVE_INFO*)my_hash_search(&slave_list,
(uchar*)&thd->server_id, 4)) &&
(!only_mine || old_si->thd == thd))
my_hash_delete(&slave_list, (uchar*)old_si);
if (need_lock_slave_list)
mysql_mutex_unlock(&LOCK_slave_list);
}
}
2、dump_gtid退出发送binlog循环时（即在com_binlog_dump_gtid函数中），这种情况属于复制线程正常推出情况；
mysql_binlog_send(thd, name, (my_off_t) pos, &slave_gtid_executed, flags);
unregister_slave(thd, true, true/*need_lock_slave_list=true*/);
3、THD线程销毁时（即在THD的析构函数中），如果该线程是dump线程，则需要进行unregister，这种情况属于异常推出；
if (rli_slave)
rli_slave->cleanup_after_session();
/*
As slaves can be added in one mysql command like COM_REGISTER_SLAVE
but then need to be removed on error scenarios, we call this method
here.
*/
unregister_slave(this, true, true);
从分析可以看出：后两种情况，最终THD结构都会被销毁，而只有第一种情况，旧slave虽然被unregister，但是其dump线程还存在。哪何时销毁呢？为什么出现了没有销毁的情况呢？
问题1：对于旧slave，何时销毁？
我们可以看到，当新slave在进行dump指令时，会调用kill_zombie_dump_threads(thd);即kill旧的slave线程。
kill_zombie_dump_threads(thd); // kill旧的slave线程
query_logger.general_log_print(thd, thd->get_command(),
"Log: '%s' Pos: %llu GTIDs: '%s'",
name, pos, gtid_string);
my_free(gtid_string);
mysql_binlog_send(thd, name, (my_off_t) pos, &slave_gtid_executed, flags); // 开始发送binlog
unregister_slave(thd, true, true/*need_lock_slave_list=true*/);
问题2：现在的情况，明明调用了kill_zombie_dump_threads，为什么没有销毁呢？
查看kill_zombie_dump_threads函数，如下：
void kill_zombie_dump_threads(THD *thd)
{
String slave_uuid;
get_slave_uuid(thd, &slave_uuid);
if (slave_uuid.length() == 0 && thd->server_id == 0)
return;
Find_zombie_dump_thread find_zombie_dump_thread(slave_uuid);
THD *tmp= Global_THD_manager::get_instance()->
find_thd(&find_zombie_dump_thread);
if (tmp)
{
……
tmp->duplicate_slave_id= true;
tmp->awake(THD::KILL_QUERY);
mysql_mutex_unlock(&tmp->LOCK_thd_data);
}
}
不然看出：在kill dump线程的时候，是通过uuid进行旧slave查找的，这就存在问题了，也就是生产出现的情况，当两个从库server_id相同，所以造成了register覆盖，但是uuid不同，造成旧的slave无法被kill。
三、结论
当两个从库server_id相同，uuid不同时，会造成旧从库无法被删除。修复建议：1、修改源码，使得在两次判断相同从库的逻辑一致；2、生产上，避免server_id相同，uuid不同的实例，同样反之依然，即uuid相同，server_id不同，会造成从库无缘无故被杀。
官方有相关bug报告已久，但并未修复，不知道为何？https://bugs.mysql.com/bug.php?id=69771
