Bug #75525 | MTS STOP SLAVE takes way too long (when worker threads are slow) | ||
---|---|---|---|
Submitted: | 16 Jan 2015 8:59 | Modified: | 1 Jul 2015 15:11 |
Reporter: | Andrii Nikitin | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S2 (Serious) |
Version: | 5.6.22 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[16 Jan 2015 8:59]
Andrii Nikitin
[16 Jan 2015 9:01]
Andrii Nikitin
Please note: with slower workers (increase sleep() parameter), the STOP SLAVE would hang even more.
[24 Feb 2015 17:00]
Andrei Elkin
There's no check for non-gap history by Workers. Only emptiness of assignment queue that matters currently. Some marking in the Worker private queue could be considered so reaching a marked event would trigger Worker's exit. Selection of the marked event in each worker private queue aims at leaving the execution history without gaps.
[1 Jul 2015 15:03]
David Moss
The following was noted in the 5.7.8 and 5.6.26 changelog: When using a multi-threaded slave, each worker thread has its own queue of transactions to process. In previous MySQL versions, STOP SLAVE waited for all workers to process their entire queue. This logic has been changed so that STOP SLAVE first finds the newest transaction that was committed by any worker thread. Then, it waits for all workers to complete transactions older than that. Newer transactions are not processed. The new logic allows STOP SLAVE to complete faster in case some worker queues contain multiple transactions.