The Ultimate Guide to High Availability with MariaDB
This is a read-only copy of the MariaDB Knowledgebase generated on 2024-11-15. For the latest, interactive version please visit https://mariadb.com/kb/.

Request details about MariaDB Cluster behaviour in certain situations

We are evaluating different database cluster solutions. We would like to get information on some of situations.

Assumption: We have 2 sites with cluster each running 3 nodes as master-master. Synchronous replication is configured between clusters. So all the nodes in both clusters remains in sync.

There are multiple applications running on both sites and uses their site cluster continuously. Meaning that continuous read/write is perform.

1. When one node reboots in one of the cluster, what would be the order of operations, data sync -> replication or replication -> data sync ?

2. When network connectivity of one of the node of the cluster is lost, when network connectivity is restored, will data sync happen correctly ?

3. As replication is configured in both clusters and they replicate to each other, is there any chance of getting stuck in indefinite replication ? I mean cluster1 replicates to cluster2 and cluster2 replicates to cluster1.

4. In case link between cluster goes down for days, when link is restored, will the data sync happened correctly ?

5. In case one of the node goes into split-brain, will it be recovered correctly ?

-noghan

Answer Answered by Nirbhay Choubey in this comment.

  1. Post-reboot: The node only joins the cluster after its in sync with the other nodes in the cluster.
  2. Yes
  3. No
  4. With 3 nodes in both the sites if the link between the sites goes down, there will be a split-brain. To avoid this, one should have odd number of nodes in the cluster or try assigning uneven weights to different nodes.
  5. The cluster goes into split-brain.
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.