Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Not a Bug
-
Affects Version/s: 2.3.9, 2.4.1
-
Fix Version/s: N/A
-
Component/s: failover
-
Labels:None
Description
I've observed, that MaxScale reports the following error when being used on a freshly installed and configured MariaDB replication cluster (MariaDB version 10.4.7 (bionic)):
.The backend cluser does not support failover/switchover due to the following reason(s): slave connection from B to A:3306 is not using gtid-replication
How to reproduce:
- Start at least 2 MariaDB instances
- Configure the slave to use the master as its master node (according to the docs)
- Join the slave to the master
- Configure the MaxScale monitor to observe those MariaDB instances
- Start MaxScale
Results
- MaxScale reports the above mentioned error upon start-up
- MaxScale detects the configured and started MariaDB instances and reports the correct status ([Master, Running] for the master node and [Slave, Running] for all slave nodes
- Replication from master to slave works fine
- When the master node is stopped no failover occurs
- Even after some operations have been done on this cluster, MaxScale does not revert its status regarding the slave nodes.
- The slave nodes' capability will be correctly identified after a restart of MaxScale (after the replication feature has been used at least once)
How to work around this issue?
- Create the MariaDB cluster
- Create a temporary table (or a database or whatever) on the master node (which will be replicated to the slave nodes)
- Delete that temporary object (or just leave it as is...)
- Start MaxScale
Hopefully there is a way for MaxScale to correclty detect whether or not GTID replication was configured. Maybe the respective variables of the slave nodes could be read and evaluated (e.g. Using_Gtid. The variable Gtid_IO_Pos won't give the correct result, because it only contains a value after at least one transaction has been done.