MariaDB Galera Cluster Requirements: InnoDB, Primary Keys, Transaction Limits and the Monthly Cost

Galera is the easiest way to get a MariaDB that keeps accepting writes through a node failure, and the easiest way to be surprised by a constraint you did not know about. MariaDB's Galera documentation, checked on 1 November 2026, lists them. This guide reads the known limitations, the memory facts and the node arithmetic, and prices three configurations of the MySQL/MariaDB/Percona cluster package on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic), in Galera mode.

What MariaDB says Galera requires

The known-limitations page is short and specific. Replication works only with the InnoDB storage engine; MyISAM has experimental support behind a flag. All tables should have a primary key (multi-column keys are fine), and DELETE on a table without one is unsupported. A transaction is replicated as one memory-resident write set, limited by wsrep_max_ws_rows and wsrep_max_ws_size to 128K rows and 2 GB by default, with the advice not to use transactions of any essential size; the page's example is that inserting 100K rows can need an extra 200 to 300 MB on the server. And a rule for sizing: the cluster cannot be faster than its slowest node.

On memory the getting-started page is reassuring: during normal operation a Galera node consumes no more memory than a regular MariaDB server, which means the usual InnoDB buffer pool arithmetic applies, plus headroom for write sets in flight.

Why three nodes, and what ProxySQL is for

Galera decides which partition of a split cluster may keep writing by majority, so a two-node cluster that loses its link has no majority and stops; three nodes is the smallest cluster that keeps a quorum through the loss of one, and odd counts above that follow the same logic. The package places a ProxySQL pair in front of the nodes: the application connects to one hostname, ProxySQL routes to healthy nodes and stops routing to a failed one within seconds, and the application sees at most a retried query. The topology post compares Galera with primary-secondary and primary-primary for applications that do not need synchronous writes.

The three configurations on PaaS and their cost

Cloudlets are 128 MiB RAM plus 400 MHz CPU, billed at $0.003372 per cloudlet-hour, $2.46 per cloudlet-month, no licence fee.

The Starter row's two nodes are the package's primary-secondary layout, which suits development; a production Galera starts at the Standard row's three nodes. All three are ceilings before volume discounts, disk per gigabyte on top; the PaaS pricing calculator prices five nodes or larger ones.

Preparing an application for Galera

Run three checks before the first migration. Every table on InnoDB: SELECT table_name FROM information_schema.tables WHERE engine <> 'InnoDB'. Every table with a primary key: the same view, joined against table_constraints. And the largest transactions the application performs: a nightly batch that updates a million rows in one statement has to be chunked, because Galera serialises the write set and the 128K-row default will refuse it. Then set innodb_buffer_pool_size as on any server, around 60 to 70% of the node's RAM, and leave the rest for write sets and connections.

When the cluster breaks

A single node failure is routine: ProxySQL stops routing to it, the platform restarts or migrates the container, and the node rejoins with an incremental or full state transfer. The bad case is losing quorum, after a network event that partitions the nodes, and that is what the Database Cluster Recovery add-on exists for: it diagnoses which node has the most advanced state and bootstraps the cluster from it from the dashboard, which the recovery post walks through. Schedule the Database Backup/Restore add-on regardless, because a consistent dump is the only protection against the change you did not mean to replicate.

Frequently Asked Questions

What are Galera's requirements for tables?

InnoDB only, and a primary key on every table (multi-column keys are fine); DELETE is unsupported on tables without one, per MariaDB's known limitations page checked on 1 November 2026. Check both with information_schema before migrating.

How many nodes does a Galera cluster need?

Three, so that the cluster keeps a majority through the loss of one node; a two-node cluster stops on a split. The Standard configuration on MassiveGRID PaaS installs three 2 GiB nodes with a ProxySQL pair from about $137.76 a month.

Does Galera need more memory than MariaDB?

Not in normal operation, per MariaDB's documentation, but large transactions are held as memory-resident write sets: inserting 100K rows can need an extra 200 to 300 MB, and the defaults cap a write set at 128K rows and 2 GB. Chunk batch jobs and size the buffer pool as on any server.