Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Not a Bug
-
22.08.18, 23.02.15, 23.08.11, 24.02.7, 25.01.4, 25.10.0
-
None
-
MXS-SPRINT-244, MXS-SPRINT-245, MXS-SPRINT-246, MXS-SPRINT-247, MXS-SPRINT-248
Description
Original issue:
If cooperative monitoring is used with two MaxScales and three MariaDB servers, after a restart of one MaxScale sometimes the wrong server is selected as the master.
Comments:
I don't see how two MaxScales could persist with different master servers. There is a possible issue with the monitor journal, in that if the persisted journal states are loaded and taken into use before a monitor tick. Usually this is not an issue, as the old master would have read_only on when the downed MaxScale comes back. If, however, the old master and MaxScale come back at the exact same moment, then for a split second, the restored MaxScale can have the wrong master. The solution to this is to ignore server roles read from the monitor journal until the monitor confirms the roles by performing a real monitor tick. However, it is unknown if this is what happened in the support case.
Attachments
Issue Links
- blocks
-
MXS-5064 Configure server correctly after crash
-
- Needs Feedback
-
- causes
-
MDEV-34878 Semisync recovery mode
-
- Needs Feedback
-
-
MXS-6034 Document case MXS-5955
-
- Open
-
- relates to
-
MDEV-38202 add init_rpl_role in output of "show variables"
-
- Open
-
-
MXS-6032 Add robust semisync replication setup tutorial to MaxScale documentation
-
- Closed
-