mirror of
https://github.com/MariaDB/server.git
synced 2025-01-16 20:12:31 +01:00
62e39c39ff
The assertion happens when: (i) the master and slave are configured to use the semisync plugin; (ii) the DBA disables semisync on the master; (iii) and he also unsets the option to wait for slaves ACK even if the semisync slave count reaches 0 during the waiting period. This combination of factors makes the server run into an assertion as soon as the last semisync slave disconnects and its dump thread exits. The root of the problem is the fact that when the dump thread disconnects and calls the observer hook transmit_stop, which ends up calling ReplSemiSyncMaster::remove_slave, there is no check whether the master has already disabled semisync or not. If it has, the then a second call to the switch_off member function must be avoided. The quick fix is to avoid calling switch_off if the DBA has disabled the semisync plugin interactively on the master. Also, the switch_off member function should only be called if the plugin has not been switched off already. This is basically the pattern throughout the rest of the semisync plugin and no other calls seem vulnerable to similar crashes/assertions. (This a backport of the patch to 5.5, which is also vulnerable.) |
||
|---|---|---|
| .. | ||
| audit_null | ||
| auth | ||
| daemon_example | ||
| fulltext | ||
| semisync | ||