Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.5, 10.6, 10.11, 11.4, 11.8
-
None
Description
When a replica stops an established semi-sync connection (e.g. from running STOP REPLICA/STOP SLAVE), it is supposed to kill the corresponding binlog dump thread on the primary server. This is done by the replica creating a new connection to its primary which issues a KILL command targeting the established connection. However, when connections are configured to use SSL, this new connection created by the replica to kill the dump thread doesn't have any logic to configure SSL options, and thereby the connection can't be made, and the dump thread will never be killed.
This may cause:
1. Unexpected long-running transactions which commit while the replica disconnects to pause until the configured rpl_semi_sync_master_timeout is exceeded
2. User confusion or scripts to break, as the behavior is not consistent.
Note that this issue spawned from a test failure during a merge to 11.4, where MDEV-31857 enabled --ssl-verify-server-cert by default.
Attachments
Issue Links
- relates to
-
MDEV-31857 enable --ssl-verify-server-cert by default
-
- Closed
-
- links to
Pushed into 10.11 as 1d5557d9c0b.
Merge conflict observed in 11.4 with resolution in commit d4e808cc533 and branch bb-11.4-MDEV-36663-mergefix.
Release Notes:
Replication connections configured with semi-sync and SSL could not be gracefully stopped, i.e. the connection could stay alive after the replica IO thread was stopped. This could potentially lead to occasional, unexpected long-running user transactions on the primary or confusing/inconsistent behavior for user scripts. This is now fixed so these connections will be killed when the replica's IO thread is stopped.