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?
Add a comment
|
2 Answers
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.
answered Dec 6, 2013 at 22:34
-
3Another 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. Commented Dec 7, 2013 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.– jynusCommented Dec 7, 2013 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. Commented Dec 7, 2013 at 18:15
-
2In case anyone else is looking, the option that Bill is referring to is
wsrep_causal_reads... set to ON withSET GLOBAL wsrep_causal_reads = 'ON';to get selects to wait until all write sets are done. Commented Apr 14, 2014 at 14:10 -
1@LukeCousins It seems
wsrep_causal_readshas been deprecated and now we should usewsrep-sync-waitto enable Galera transmit worksets synchronously. (Source : galeracluster.com/library/documentation/…). For options on how to use wsrep-sync-wait see galeracluster.com/library/documentation/…. Commented Jun 21, 2021 at 11:12
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.