Limitations of Galera Cluster

If and how to use Galera Cluster for MySQL has been described already by many others...

In this article we focus on the question: When is Galera Cluster NOT the right solution for you?

These thoughts also apply to Percona XtraDB Cluster (PXC) and MariaDB Galera Cluster.

• Galera Cluster currently supports only InnoDB (and TokuDB?) tables properly. You should avoid to use MyISAM or MEMORY tables. Otherwise data consistency is not guaranteed.
• It is wise to use Galera Cluster only if your software vendor supports this high-availability solution.
• Galera Cluster is a no-go if you rely on missing InnoDB features (like GIS indices).
• Synchronous replication cluster solutions are sensitive to hot-spots (like queues, messaging systems or sequences). If you have high concurrency on such hot-spots your cluster could become slow.
• Galera Cluster is primarily a high-availability solution and not a high-performance or scalability solution.
• Galera Cluster will NOT be fun if you have an unstable network.
• Galera Cluster is possibly not the right solution if you need very low latency or even real time behaviour.
• Galera Cluster will most probably NOT solve your write scaling problems.
• If you have a high rate of DDL commands (CREATE, ALTER, DROP), which cause a Global Cluster Lock during the TOI operation you should possibly first fix your application (Will be solved in Galera v4.0?). This is especially unexpected for CREATE TABLE IF NOT EXISTS and CREATE TABLE younameit_tmp instead of CREATE TEMPORARY TABLE younameit_tmp.
• Galera Cluster is NOT happy with tables without a Primary Key. Fix your schema first.
• Galera Cluster does NOT support LOCK/UNLOCK TABLES, GET_LOCK/RELEASE_LOCK commands. Fix your application first.
• Galera Cluster did NOT support distributed transactions (XA, SHOW GLOBAL STATUS LIKE 'COM_XA%';) as some enterprise Java solutions (J2EE) are doing it. This restriction is removed now in Galera Enterprise Cluster but not yet in MariaDB Galera Cluster?
• Galera Cluster and your application has to be adjusted to each other if you are using Ajax requests against your database (For example update on session timestamp stored in the Galera cluster).
• If you have poor experience in database operations you probably should not use a Galera Cluster. With cluster solutions you have to know what your are doing. Otherwise you will shoot yourself in your foot. In this case a simpler solutions serves your needs better (KISS without comma).
• If you do not have your development process under control (know what you are doing, testing and deployment) you should better avoid Galera Cluster.
• Your application should do proper error handling (deadlock errors) because such errors can rise more frequent with Galera than with a single instance MySQL installation.
• Galera Cluster did not support huge transactions (> 2 Gbyte). Large transactions are not good for transactional databases anyway and cause lag in Galera Cluster (virtual-synchronous replication). This restriction is fixed in Galera 4.0 with huge transaction support.
• If you heavily rely on Query Cache you should first fix the queries and redesign your application. There is experimental Query Cache support since Galera v3.1. The release notes mentions for 5.6.27 that wsrep_sync_wait is supported now. This seems to be an indication that Query Cache is fully supported now but it seems like Codership does not want to talk broadly about it... Once the Galera documentation clearly stated: Do not use query cache.. But this comment has gone.
• Binary Log filtering with binlog_do_db or binlog_ignore_db is not supported.