Topologies
- Single: one MariaDB server with binary logs on, so point-in-time recovery works.
- Galera: three or more members, an odd number recommended. Galera is quorum-based: a minority partition stops serving instead of diverging.
- A lightweight Galera arbitrator as a witness, and ProxySQL, are planned for v1.1.
MariaDB 12.3 LTS is the default and 11.8 LTS is supported, with Galera 4.
A preferred writer, not a promise of one
Writing to several Galera members at once causes certification conflicts, so the writer endpoint
(port 3307) sends writes to one member and moves them to another when it fails, with a design target of at most 10
seconds. It is a best-effort preferred writer, not a guarantee: HAProxy instances share the choice, and writes do
not move back automatically. Multi-writer routing is available when your application handles conflicts.
The readers endpoint (3308) spreads reads across members, but those reads are not guaranteed to see
the latest write; use the writer, or wsrep_sync_wait, when you need to read your own writes. The proxy
passes real client addresses through, and secure transport is required.
Durable by default
The default strict durability flushes the log at every commit and syncs the binary log, so an acknowledged write survives a failover. New clusters require primary keys, which Galera needs to replicate safely, and state transfers between members always use TLS.
Bootstrap and recovery
Starting a new Galera cluster from one member is the classic way to lose data, so the bootstrap flag never appears in a command line: it is a single-use token tied to the cluster’s current generation. After a full outage the cluster recovers by itself only if every member’s position is known and the winner is unambiguous; otherwise it waits for a person. Forcing a minority to become primary is a critical plan.