I'm currently looking into setting up a database cluster (MySQL Galera or Percona) but I have only 2 machines.

However, according to many sources I've read (This article from the Mariadb KB), the minimal node size in the cluster should be 3, to avoid split brain conditions.

In order to avoid a split-brain condition, the minimum recommended number of nodes in a cluster is 3. Blocking state transfer is yet another reason to require a minimum of 3 nodes in order to enjoy service availability in case one of the members fails and needs to be restarted. While two of the members will be engaged in state transfer, the remaining member(s) will be able to keep on serving client requests.

So I'm wondering if I can run maybe 3 (or more) docker containers, each running a database server, on both machines. If one of the machine fails, there are still 3 nodes in the cluster, so no split brain problems.

It feels like cheating, but I cannot think of a reason not to do it.

Does this setup make sense ?

1 Answer 1


Galera (for MySQL, Percona XtraDB Cluster or MariaDB Cluster, they are essentially the same but from different vendors and base mysql version) can work perfectly with 2 machines, and it is a very common setup for substituting standard MySQL replication.

Requiring 3 nodes is not a requirement of Galera, but of any cluster that cares about data consistency over availability. In other words, it is needed in order to provide availability and data integrity in the case of only one node suffering from network partition (causing a "split brain" on the cluster). We need an odd number of nodes and 1 node is not a cluster :-). You probably knew that, but I wanted to clarify this for any people reading this answer.

Given that the only reason to have 3 nodes is for availability in case of a node failure/network failure, the recommended way to setup a 2 node cluster with network split protection is to setup a Galera Arbitrator which is essentially an emulation of a MySQL node, but without storing any local data. You can install that anywhere, although you must be careful because if still may influence the performance of the cluster if it has network latency problems.

Running several instances on the same physical node is useless (docker is not needed, by the way, you can do that by just changing the local configuration), as if you absolutely can only run things on 2 machines, you better disable the automatic shutdown on one of the nodes and manage the failover manually. The 3 limitation is just for data consistency, there is nothing physical or on the protocol requiring a certain number of nodes.

You can read more information about it on the official documentation.

  • That's a great answer, jynus, gracias! I didn't know about the Arbitrator and I think I can use it. However I didn't understand the part about automatic shutdown and manual failover. Could you clarify that bit, please ? Aug 20, 2014 at 9:54
  • @patatepartie You could technically add wsrep_provider_options="pc.ignore_sb = yes" (ignore split brain) so that a node does not shutdown in the event of the other node crashing. But if the nodes lose connectivity between them, and your clients can still write to both nodes, you will suffer from data inconsistency (it is your responsibility that that does not happen). Please note that in any case, a 2 node cluster will not stop if one node shutdowns gracefully (service stop). Hope that helps.
    – jynus
    Aug 20, 2014 at 10:00
  • I understand. The default behavior when the nodes lose connectivity with each other is to stop accepting commands. If I "ignore sb" and the problem happens, I need a mechanism on my clients to only communicate with one of the servers otherwise I will have data inconsistencies. Thanks a lot, I can see my options now. Aug 20, 2014 at 10:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.