Bug #38220 dump thread continues uselessly after slave IO has disconnected

• Submitted: 18 Jul 2008 9:05
• Modified: 22 Aug 2008 17:05
• Reporter: Andrei Elkin
• Status: Not a Bug
• Category: MySQL Server: Replication
• Severity: S3 (Non-critical)
• Version: 5.1, 6.0
• OS: Any
• Assigned to: Andrei Elkin
• CPU Architecture: Any

[18 Jul 2008 9:05] Andrei Elkin

Description:
Upon disconnecting the dump thread exists listening for new events in binlog and even tries to send them to nowhere. It only stops when the slave sends  COM_BINLOG_DUMP request.

How to repeat:
Look at analysis of Bug #34647.

Suggested fix:
deploy a check of the socket of a connection with the slave's io thread and leave by the dump if io closed its end.

[22 Aug 2008 17:05] Andrei Elkin

After investigating the issue it was proven that the dump thread does *leave* indeed when the slave io thread has disconnected.
This may happen in some small delay until net_flush() returns non-zero so that the dump thread can continue "uselessly".
But the fact is net_flush detects the slave io will have left eventually.

As a consequence of this result, a test (like Bug #34647) should not rely on that an old dump instance disappears instantly upon the io thread has left e.g via STOP SLAVE.
One has to expect the delay.