[MXS-2309] MaxScale mariadbmon not consistent in treatment of external server when managing 2 M/S nodes Created: 2019-01-31  Updated: 2020-10-19  Resolved: 2020-10-19

Status: Closed
Project: MariaDB MaxScale
Component/s: mariadbmon
Affects Version/s: 2.2.18
Fix Version/s: 2.3.3

Type: Bug Priority: Major
Reporter: Richard Lane Assignee: Esa Korhonen
Resolution: Fixed Votes: 0
Labels: failover_issues, maxscale
Environment:

centos7 cloud container

Attachments: Text File maxscale.log     File mxs.issue    

 Description   

Setup dual datacenter Maxscale w/ Master-Slave node using mariadbmon with auto-failover. System is deployed correctly as can be seen from first maxadmin in mxs.issue file. Each data center is Master/Slave and the masters are replicating to each other (as external servers).

However, when I take down the master (mariadb-0) in dcA, maxscale indicates that it is failing over to mariadb-1 node and it applies promotion.sql and redirects new master (mariadb-1) to new external master. Then it looses Master status in the local datacenter.

Attached is mxs.issue file which shows maxadmin list servers in each datacenter before and after dcA-mariadb-0 is taken down.

Also attached is maxscale.log showing mariadb-1 promoted to master.

 Comments   
Comment by Esa Korhonen [ 2019-02-01 ]

This seems to be an issue in the master detection algorithm of the monitor. The failover is indeed ran correctly, just the state of the surviving backend is set incorrectly. This is likely not an issue in 2.3.

If the cluster where the master fails contains three or more servers, the detection works. If an external master is not used, the two-server configuration works due to the "detect_standalone_master"-setting.

Comment by Richard Lane [ 2019-02-13 ]

This can be closed. The issue does not occur in maxscale-2.3.3 and we will be releasing that.

Comment by markus makela [ 2020-10-19 ]

Closing as fixed in 2.3.3 based on the latest comment.

Generated at Thu Feb 08 04:13:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.