Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
2.3.9, 2.4.1
-
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.