Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
6.4.1, 6.4.12, 22.08.10, 23.02.6, 23.08.3
-
None
-
MXS-SPRINT-195
Description
In a two node setup, if the slave server breaks due to some SQL thread problem (e.g. error 1032 ER_KEY_NOT_FOUND) and then the master goes down, MaxScale will emergency promote the slave so that the cluster stays usable. This is unwanted behavior and often users would prefer that MaxScale simply waits (perhaps for a long time) for the master to come back.
The logic should be changed so that even a broken slave (SQL or IO thread stopped, but not both) prevents new master selection. Only if both are stopped (usually requires "STOP SLAVE"), new master can be selected as this means the dba is modifying the cluster.
A more resilient setup can be assumed to have multiple slaves so that at least one can be properly promoted by failover.
Original description:
Is there a way to configure maxscale to not promote a slave to master if the slave is still applying relay logs (behind master)?
Related Jira issue: MDEV-32370
Attachments
Issue Links
- relates to
-
MXS-4841 Mariadbmon selects diverged server as master
- Closed
-
MDEV-32370 Replica should have a way to say it is behind master
- Closed
- mentioned in
-
Page Loading...