You are here

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 does NOT support distributed transactions (XA, SHOW GLOBAL STATUS LIKE 'COM_XA%';) as some enterprise Java solutions (J2EE) are doing it.
  • 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 has problems with huge transactions (> 2 Gbyte). Huge transactions are not good anyway for transactional databases and cause lag in Galera (virtual-synchronous). This restriction will probably be fixed in Galera 4.0.
  • 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. But the Galera documentation clearly states: Do not use query cache..