Bug #93649 | STOP SLAVE SQL_THREAD deadlocks if done while holding LOCK INSTANCE FOR BACKUP | ||
---|---|---|---|
Submitted: | 18 Dec 2018 3:23 | Modified: | 12 Apr 2019 10:11 |
Reporter: | Sergei Glushchenko | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
Version: | 8.0.13 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[18 Dec 2018 3:23]
Sergei Glushchenko
[21 Feb 2019 0:41]
MySQL Verification Team
Hi, Thanks for report and test case. Took bit more then "few" times but I verified the bug. Kind regards Bogdan
[12 Apr 2019 10:11]
Margaret Fisher
Posted by developer: Changelog entry added for MySQL 8.0.17: If a LOCK INSTANCE FOR BACKUP statement was used to acquire an instance-level backup lock, then a STOP SLAVE statement was issued, a deadlock could be created with the SQL thread waiting on the backup lock and the STOP SLAVE statement waiting on the SQL thread to complete its current action. To prevent this situation, the STOP SLAVE process now tries to acquire the backup lock before proceeding, and returns an error if the lock cannot be acquired.
[24 Apr 2019 11:14]
Margaret Fisher
Posted by developer: Changelog entry reinstated.
[16 Sep 2022 7:22]
tezhongbing tezhongbing
Hello, after this bug was fixed, we encountered another problem Our MySQL cluster is such a master database, two slave databases, and semi synchronization is enabled. One of the slave databases is executing clone, which is the donor. At this time, the master database failure triggers the automatic switch logic. However, when the slave database of clone executes stop slave, it fails, and the high availability switch program exits abnormally. That is to say, the high availability switchover cannot be successfully performed during the clone, while the clone may take a long time, which is unacceptable. It is recommended not to fix this bug or fix it gracefully.