Bug #77195 Zombie dump threads are not disconnected

Description:
In MySQL 5.5, when a slave reconnected to a master, MySQL would
kill any other slave connections having the same server_id. That
is, whenever a slave with a given server_id connected to dump
binary logs, it would kill any other existing slave connections
using the same server_id.

In MySQL 5.6, the slave’s server_uuid is used, instead of server_id,
to identify which connections to kill. Whenever connecting to a
master, the slave sets a user-defined variable name @slave_uuid
to the value of its server_uuid. If a slave does not set slave_uuid,
other connections from this slave are not killed.

The problem is that MySQL 5.5 slaves do not set their slave_uuid
since they don’t have a server_uuid. Therefore, zombie connections
from MySQL 5.5 slaves are never killed and the master eventually
fails due to max_connections.

Furthermore, the get_slave_uuid() function is not thread-safe and
occasionally leads to crashes when a connecting slave is manipulating
its user-defined variables.

How to repeat:
Connect two MySQL 5.5 slaves with the same server_id to a MySQL 5.6
master, both remain connected while one should have been killed.

Hello Davi,

Thank you for the report.
Observed this behavior(Zombie dump threads, not crash) with master(5.6.26) and two slaves(5.5.45).

Thanks,
Umesh

test results

Attachment: 77195.txt (text/plain), 19.92 KiB.

Post by Developer:
==================

As Umesh mentioned above, We are unable to reproduce the "crash" part.
I am changing the title of this bug accordingly.

Could you please report another bug for the crash with reproducible scenario if you have. We will look into it.

Thank you, 

Regards,
Venkatesh.

Posted by developer:
 
Thanks for your feedback. This has been fixed in upcoming releases and the following was added to the 5.6.32 and 5.7.14 change logs:
A MySQL version 5.5 slave does not have a server_uuid and replication identified servers by their server_id. Starting from MySQL version 5.6, replication masters detected a zombie dump thread based only on a slave's server_uuid value, under the assumption that each slave has a unique UUID. Connecting a MySQL 5.5 slave to a MySQL 5.6 and later master meant that the master was unable to detect zombie dump threads that were created to serve slaves running versions older than MySQL 5.6. The fix ensures that a master now first checks if a slave has a server_uuid set. If it is set, zombie dump thread detection happens based on the slave's UUID. If a slave's server_uuid is not set, zombie dump thread detection happens based on server_id.