What are the drawbacks of using Galera Cluster instead of regular Master/Slave Replication? Galera's 0 slave lag time, Synchronous replication and no Single point of failure seem very appealing then why isn't Galera cluster as common?

up vote 15 down vote accepted

Because like any other optimization, it doesn't fit every workload.

Galera can get overwhelmed by a high rate of transactions, or when transactions update many rows. It can also make your applications experience delays on COMMIT as the cluster is synced up.

Galera doesn't update other nodes synchronously, either. It just transmits worksets synchronously. In this way, it's a bit like standard replication in semi-synchronous mode. Therefore there's still a small chance of reading stale data from another cluster node. There's an option you can set to force SELECT to wait until the queue of worksets has updated the database, but this means you have delays on SELECT. And even a chance of getting a deadlock on SELECT, which seems counter-intuitive.

Galera is brilliant, but not a one-size-fits-all technology. There are still good reasons to use asynchronous replication.

  • Thanks Bill, btw I have been reading your Percona presentations for a while. – Sam D Dec 6 '13 at 22:36
  • 3
    Another drawback is having a donor node off itself and be used to copy (via xtrabackup, rsync,mysqldump) to any node introduced to the cluster, leaving the remaining nodes in the cluster to do the heavy lifting until the new node is in sync. It's not such a drawback for small or medium sized DBs. – RolandoMySQLDBA Dec 7 '13 at 2:44
  • 1
    @RolandoMySQLDBA SST methods like xtrabackup precisely avoid locking the donor. Although it is true that in any case, the donor will have degraded performance if the database is large. – jynus Dec 7 '13 at 11:54
  • 3
    @jynus, the issue is not locking on the donor node, but that the receiving node is offline and unavailable for any queries while the SST is in progress. Therefore if you're using the cluster for query load balancing, the queries that would have gone to the receiving node have to be sent to other node(s) until the SST is done. – Bill Karwin Dec 7 '13 at 18:15
  • 2
    In case anyone else is looking, the option that Bill is referring to is wsrep_causal_reads... set to ON with SET GLOBAL wsrep_causal_reads = 'ON'; to get selects to wait until all write sets are done. – Luke Cousins Apr 14 '14 at 14:10

Some drawbacks of Galera include:

  • Storage engine support: limited to InnoDB/XtraDB (plus experimental support for MyISAM)
  • OS support: only Linux/Unix-like Oses

There are also some limitations which should be noted, but can perhaps be worked around:

  • By default (Total Order Isolation) DDL operations block the entire cluster until they complete
  • Every table must have an explicit primary key, either single or multi-column
  • Locking: some types of explicit locking are unsupported.

For more info, see details at Codership (and here about blocking DDL), MariaDB, and Percona.

EDIT: Note also that some argue that tightly coupled database clusters, such as Galera, should not have geo-distributed nodes because of the problems stemming from the inherent unreliability of the network layer. Instead, asynchronous solutions must be used in these cases. See: How Not to do MySQL High Availability: Geographic Node Distribution with Galera-Based Replication Misuse. Nevertheless, the Galera blog states that (2015):

The case for building geo-distributed database clusters is strong. The Galera approach to replication and the specific features in the product make it practical to build Galera clusters that span multiple data centers and multiple users have such clusters already in production.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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