The manager
The web interface, in a container that cannot touch the machine. It serves pages on 8443 and talks to the other managers on 8444 about who is a member, which accounts exist and what the settings are.
How it works
Three ideas explain nearly everything: what synchronous replication actually means, what runs on each machine, and how the cluster decides who is right when machines cannot see each other.
Synchronous replication
In ordinary MySQL replication there is a primary that takes writes and replicas that copy them afterwards. The copying happens after the write is confirmed, so a replica is always a little behind, and how far behind is a number somebody has to watch.
Galera does not work that way. A write to any node is sent to every other node and has to be accepted by all of them before the transaction commits. When the commit returns, the data is on every machine. There is no lag to watch because there is no lag.
The cost is that a write is only as fast as the slowest node can accept it, and every node does every write. That is the whole trade, and the performance page has measurements of what it costs.
What runs on each machine
The host agent
The only part that runs as root and the only part that can change the machine. It does a fixed list of things and checks the arguments of each. That list is the real security boundary, not the container.
MySQL or MariaDB, with Galera
MariaDB is compiled from source on the machine so every node is genuinely identical. MySQL means Percona XtraDB Cluster, from packages. Either way it is sized to the hardware it is on, rather than left at defaults that assume nothing.
Two separate conversations run between machines, and telling them apart explains most of what you see later. Galera replicates the data. The managers talk about everything else. Either can be working while the other is not.
Adding a machine
You take a single use ticket from the web page, run one command on the new machine, and it joins. The signing secret, the interface accounts, the database account and the node list all come across on that conversation. Nothing is typed twice, and no account is created by hand on any machine after the first.
What happens when a machine goes away
Galera decides by counting. The side holding more than half the members keeps taking writes; the side without stops. That is what stops two halves of a split cluster both accepting writes and quietly growing into two databases that can never be put back together.
| Machines | Survives losing | Why |
|---|---|---|
| 2 | nothing | Either failure leaves one node holding half, and half is not a majority. Both sides stop. |
| 3 | one | Two remain, which is a majority, and they carry on with nobody doing anything. |
| 4 | one | Two out of four is not a majority. No better than three. |
| 5 | two | Three remain, which is a majority. |
So the useful sizes are three and five. If you only have two database machines, an arbitrator on any third machine votes without holding data and gives you the resilience of three.
When the machines are not on one network
Galera expects its members to reach each other directly. If they are in different data centers, behind NAT, or on networks that cannot see each other, the interface builds a private encrypted network across them with WireGuard, and the cluster uses that instead. Only one machine needs a port open; every other one dials out, which works from behind NAT with nothing forwarded to it.