[MXS-2010] MaxScale Failover Not Working as Expected Created: 2018-08-13 Updated: 2020-08-25 Resolved: 2018-08-30 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | mariadbmon |
| Affects Version/s: | 2.2.13 |
| Fix Version/s: | 2.3.0 |
| Type: | Bug | Priority: | Major |
| Reporter: | Chris Calender (Inactive) | Assignee: | Esa Korhonen |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Sprint: | MXS-SPRINT-64, MXS-SPRINT-65 |
| Description |
|
We are testing with maxscale 2.2.13 with failover scenarios we noticed that one scenario is failing. Tested this for enough times and the same thing is observed. scenario. node1 ==> Master success node1 ==> down , rejoined as slave Success =================================== when node1 and node2 is brough down at a time node3 is promoted as Master Successfully Success ==================================== node1 ==> Running out put node1 ==> Slave Running Failure In the above scenario we started both nodes at a time node2 followed by node1
==================================== While doing individual failover nodes this is promoting perfectly. But when doing both nodes at a time this is failing on same error. Uploaded failover maxctrl output for your reference. |
| Comments |
| Comment by Chris Calender (Inactive) [ 2018-08-14 ] |
|
Also, it has now been tested multiple times with read_only=1 in my.cnf, with still the same results. The previous master is not joining as slave it's promoting as master. I will upload the latest logs for your reference. |
| Comment by Esa Korhonen [ 2018-08-30 ] |
|
This is difficult to fix for 2.2, as the monitoring logic does not remember the previous master. In 2.3 the logic is different and these kinds of issues should not be a problem, or at least they are easier to fix. |