Performance

Which one is faster

MariaDB, on this workload, by a wide margin. Tuned first, best first, then the same two servers as their installers leave them. Tuned means the settings made to match, so that the two are doing the same amount of work.

On level settings MariaDB does 65 percent more work, and it does it using less of the machine: 61 percent of the processors against 75, and almost no disk at all. That is the number to plan around if throughput is what you are choosing on.

Queries, inserts and drops

Broken out, because they cost different amounts. An insert appends. An update has to find the row first and then send the old and new values to every node. A drop is DDL, which the cluster runs one statement at a time in agreed order.

MariaDB is about four times faster at DDL. That gap holds across every run, and it matters more than it looks: DDL stops the cluster while it happens, so a migration that creates and drops a few hundred tables is a few hundred short pauses on one server and a quarter as many on the other.

The last row is a range on purpose. Dropping a populated table took 3.3 ms on an idle cluster and 30.7 ms on one still settling after a long run, and both readings are real. Quoting either end alone would be picking a favorite.

Reads alone

Take the writes away and the picture changes completely. MariaDB served 56,079 reads a second at 96 connections, more than twice the whole mixed figure.

That is because a read never leaves the machine it arrives on. It is not sent to the other nodes, nothing has to agree to it, and no write set is certified. So reads scale with the hardware instead of with the cluster, and this is the one test where the machine actually ran out: the processors hit 99.8 percent while the disk stayed at zero.

Worth knowing when sizing. If your load is mostly reads, buy processors. If it is mostly writes, more processors will not help, because the limit is agreement between nodes.

The default that stops MariaDB early

MariaDB is left at max_connections = 151, which is the stock default. Ask for more than that and the extra connections are refused. It does not cost throughput, because 96 connections is already past the bend, but it is a wall and it arrives without warning. The MySQL installer sets 2,000 and MariaDB's does not.

Raise it before you need it:

sudo mariadb -e "SET GLOBAL max_connections = 2000"

That lasts until the server restarts. To keep it, put max_connections = 2000 under [mysqld] in a file in /etc/mysql/mysqlcluster.conf.d/.

Two things measured earlier

These come from testing in August on a different arrangement of machines, with an older version of the workload. They are kept because the questions they answer still matter, and they are separated out because the numbers cannot be lined up against the tables above. Read them as ratios, not as totals.

Distance costs about a third of the write throughput, because every commit waits for the far node. It buys surviving the loss of a whole site. Whether that is worth it is a question about your business rather than about the database.

With a 20 GB table against a 9.3 GB buffer pool, a mixed workload ran at about half the speed of one that fits, and reads alone lost about 30 percent. On NVMe, running a little over the buffer pool costs throughput steadily rather than falling off a cliff. Aim to fit the working set in memory; a little over still works.

How this was measured

Every read and every update lands on a real row. Galera steps the id column by the cluster size, so ids are not dense, and picking a random id finds nothing more often than it finds something. Updates that match no row are nearly free, which makes a cluster look faster than it is. The test seeks to the next real row instead.

One workload, small rows, primary key access, everything in memory. It says nothing about joins, table scans, or a database larger than the memory you give it.