Overview

WolfStack can build and operate a MariaDB Galera cluster for you — synchronous multi-master replication, from an empty host to a running cluster, without writing a wsrep configuration by hand.

It handles the three things that actually take time: provisioning a fresh cluster, adopting one you already run, and recovering one that has gone down without losing data to a careless bootstrap.

Provision a new cluster

Choose how many nodes you want and WolfStack does the whole sequence, streaming progress live as it goes:

  1. Create N LXC containers to host the nodes.
  2. Install MariaDB and Galera inside each one — package families are handled for Debian/Ubuntu, RHEL family, Alpine and Arch.
  3. Write the wsrep configuration for every node.
  4. Bootstrap the first node, then join the rest to it in order.

Progress is streamed to the browser as it happens, so a long install is not a spinner you have to trust.

Adopt an existing cluster

Already running Galera? Register the containers and WolfStack manages them from then on — no rebuild, no migration. You get the same live status view as a provisioned cluster.

Live wsrep status & split-brain detection

The status view reads real wsrep state from every node and actively looks for the failure that hurts most: split brain. Two signals give it away, and WolfStack checks both:

  • Distinct cluster UUIDs — nodes that believe they belong to different clusters.
  • Disagreeing Primary component sizes — nodes that disagree about how many members the cluster has.

Status is read over MySQL TCP rather than by shelling into each container, which is why it keeps working when the cluster spans hosts.

Recovery that refuses to lose your data

This is the part worth reading carefully, because it is where Galera clusters are usually destroyed.

When a whole cluster is down, someone has to bootstrap a node — and whichever node you bootstrap becomes the truth. Bootstrap the wrong one and every transaction the more-advanced nodes had is silently gone. That is the classic Galera data-loss incident, and it is almost always a human under pressure picking the wrong container.

WolfStack’s recovery is evidence-based. It reads each node’s grastate sequence number to find the most advanced survivor, and it will refuse to act at all unless:

  • every node is confirmed down, and
  • at least one node reports a known position.

It never bootstraps a node whose position is stale or unknown. If it cannot prove which node is furthest ahead, it stops and tells you rather than guessing on your behalf.

Per-node stop / start / restart are available for ordinary lifecycle work.

Ownership & cross-host behaviour

A Galera cluster is owned by one host — its configuration and its containers live there. The UI carries a host selector and routes every call to the owning node through the cluster node proxy, so you can drive it from any node’s dashboard.

Because status is read over MySQL TCP, monitoring works across hosts. Provisioning across hosts is a documented non-goal, not an unfinished feature — a cluster is provisioned on one host by design. For multi-host database topologies, see WolfScale, which is built for exactly that.

Related

  • MySQL / MariaDB browser — browse schemas and run queries against any database WolfStack can reach.
  • WolfScale — database replication and load balancing as a dedicated product.
  • Containers — the LXC layer Galera nodes are built on.
  • Backups — scheduled backups for the containers holding your data.

Frequently Asked Questions

Can WolfStack manage a Galera cluster I already built?

Yes. Adopt registers containers you already run, and you get the same live wsrep status, split-brain detection and recovery tooling as a cluster WolfStack provisioned itself.

What happens if my Galera cluster splits brain?

The status view detects it by comparing cluster UUIDs and Primary component sizes across nodes, and surfaces it rather than letting the cluster quietly diverge.

Will WolfStack bootstrap the wrong node and lose my writes?

It is specifically designed not to. Recovery picks the most advanced survivor by grastate sequence number, and refuses to run at all unless every node is confirmed down and at least one reports a known position.

Which Linux distributions are supported for the database nodes?

Debian/Ubuntu, the RHEL family, Alpine and Arch package families are all handled during provisioning.

Esc