Running the cluster

Builds the server for you

Two servers to build, and the same button builds either. MariaDB and Galera are compiled on each machine rather than installed from packages: that costs twenty minutes and buys the property a cluster needs most, which is that every node is genuinely identical rather than whatever version a distribution shipped that week. MySQL means Percona XtraDB Cluster, which installs from packages in a couple of minutes, because Oracle's MySQL has no Galera in it to cluster. Either way the buffer pool, the redo log and the write cache are sized from the machine, because the defaults are 128 MB whether the box has 2 GB or 256 GB and nothing says so.

Add a machine with one command

Press one button for a single use ticket, run one command on the new machine, and it joins. The signing secret, the interface accounts, the database account and the node list all travel on that conversation. The ticket lasts an hour, works once, and is stored only as a hash, so the dialog is the one time it can be read.

Decides safely when alone

A node that has lost the others cannot tell whether they are dead or whether it is the one that got cut off. Those look identical from where it is standing. So the checks refuse to guess: silence is never treated as evidence, and a node only starts taking writes alone when every check agrees the others are genuinely gone.

Remove a node cleanly

Removing a node takes it off the roster, rewrites the Galera address list on every remaining machine, and takes it off the tunnel. It is refused if it would leave a cluster that cannot survive another failure, and the refusal explains the arithmetic rather than just saying no.

Seeing what is happening

Every node, honestly

State, version and apply queue for every machine. Serving and running are shown as the different questions they are: a node out of quorum answers every connection, returns results to SELECT statements, and refuses every write, which looks like health to anything that only checks the port.

Whether they are in step

Position, apply queue, send queue, flow control and certification conflicts. Worked out per interval rather than since the server started, so a node that was busy last Tuesday does not read as a node that is struggling now.

Charts you can read

Processor, memory, load, disk and the query rates, per node, on one page. Hover to read the numbers at a moment; drag across a chart to select a span and every other chart narrows to the same window, so a spike in one can be lined up against everything else that was happening.

A log nothing can edit

Who did what, from where, and whether it worked. Written to and never edited: there is nothing in the interface that can change or remove an entry, because a record somebody can tidy up from the interface it is recording is not evidence of anything. Every statement run from the SQL page is in it, in full.

The data

Databases and tables

What schemas exist, how many tables they hold, and how big they are on disk. The size shown is what InnoDB has allocated rather than what the rows add up to, because that is the number that matches the disk and the one that matters when deciding whether there is room for a backup.

Accounts and grants

MySQL logins, with the host half always shown. MySQL identifies an account by its name and its host together, so app@10.0.0.% and app@% are two different accounts with separate passwords and separate grants. That catches people out constantly, which is why both halves are never hidden.

Run a statement

One statement at a time, against the cluster. Reads and writes need different permissions and which one it is gets decided before anything runs, so a viewer can do neither. A semicolon will not start a second statement: the connection is opened without multi-statement support, which is the difference between a broken query and an injection.

Backups that are real copies

Three identical nodes protect against a machine dying and against nothing else. A dropped table or an UPDATE without a WHERE reaches every node in milliseconds. Backups run while the server keeps serving, and are refused when there is not room, because a backup that fills the disk takes the database down with it.

Getting in, and getting there

A private network between nodes

A WireGuard network between the machines, for when they are in different places or behind NAT. One node is reachable and everything else dials out, so only one machine needs a port open. Machines that are not cluster members, an application server or a backup host, can be put on it too.

Sign in properly

Local accounts must have an authenticator, because they are the way back in when single sign on is broken. Or use your identity provider, where roles come from the groups it sends, so somebody joining or leaving a group changes what they can do here without anybody editing an account.

Settings that reach every node

Settings reach every manager the way accounts do, so the allow list cannot be right on the machine you are looking at and wrong on the other two. Sizing is the deliberate exception, because the buffer pool depends on the hardware of the machine it is on.

Closes what a fresh install leaves open

A fresh MariaDB comes up with two accounts that have no name and no password, and with rights on the test database held by PUBLIC, the role every account holds and cannot give up. mysql_secure_installation clears all of it and is interactive, so no scripted install ever runs it. This one does, at build time.

All of it, free

MIT licensed. No paid tier, no signup, nothing held back.

Get started Read the source

Product

Start here

More

Features