Set up the Galera cluster using HostHatch’s private networking rather than WireGuard for the Galera replication traffic. HostHatch provides an isolated private VLAN/VXLAN between VMs in the same location, with no bandwidth charge, and Debian 13 is supported for the private interface configuration. (HostHatch Docs)
I’ll walk you through it one step at a time. Don’t do all three at once yet—we’ll configure node 1 first, verify it, then node 2 and node 3.
Target setup
Let’s assume:
db1.example.com 192.168.10.1
db2.example.com 192.168.10.2
db3.example.com 192.168.10.3And:
db1 = Galera node 1
db2 = Galera node 2
db3 = Galera node 3Your actual private IPs can be different; those are just examples.
The eventual cluster will be:
Private Network
│
┌────────────┼────────────┐
│ │ │
db1 db2 db3
192.168.10.1 192.168.10.2 192.168.10.3
│ │ │
└────────────┼────────────┘
│
Galera
│
3-node quorumStep 1 — Create the three VPSs
I’d start with your inexpensive plan:
Each:
- 2 AMD EPYC Milan cores
- 4 GB RAM
- 20 GB NVMe
- Debian 13
- Los Angeles
You can upgrade them later.
In the HostHatch control panel, enable Private Networking for the VPSs. HostHatch requires at least two active VMs in the same location. When enabled, each VM gets an additional private interface. (HostHatch Docs)
For Debian 13, HostHatch’s documented private interface configuration is via ifupdown. The private interface is normally eth1, but we’ll verify rather than assume. (HostHatch Docs)
Step 2 — Configure the private network
SSH into db1.
Run:
ip -br linkand:
ip -o link | grep 00:22You should find the HostHatch private interface. HostHatch says the private interface MAC begins with 00:22. (HostHatch Docs)
Then:
ip -br addrInitially you’ll probably see something like:
eth0 UP <public IP>
enp2s0 DOWNWe’ll assign:
db1 → 192.168.10.1/24
db2 → 192.168.10.2/24
db3 → 192.168.10.3/24Do not configure a gateway on this interface. HostHatch specifically warns that the private interface cannot reach external networks and should not have a default gateway. (HostHatch Docs)
On db1:
sudo nano /etc/systemd/network/10-private.networkPut:
[Match]
Name=enp2s0
[Network]
Address=192.168.10.1/24Then:
sudo networkctl reload
sudo networkctl reconfigure enp2s0Check:
ip addr show enp2s0
networkctl status enp2s0You should see:
192.168.10.1/24Repeat on db2 and db3, changing the address.
Step 3 — Test the private network
From db1:
ping 192.168.10.2and:
ping 192.168.10.3From db2:
ping 192.168.10.1and:
ping 192.168.10.3And from db3:
ping 192.168.10.1and:
ping 192.168.10.2Don’t proceed until all six tests work.
The private network is particularly nice here because HostHatch says traffic on it is unlimited and isn’t counted against the VM’s normal bandwidth allowance. (HostHatch Docs)
Step 4 — Configure hostnames
On db1:
sudo hostnamectl set-hostname db1.example.comOn db2:
sudo hostnamectl set-hostname db2.example.comOn db3:
sudo hostnamectl set-hostname db3.example.comThen make sure every node can resolve all three names.
For a small private cluster, /etc/hosts is perfectly reasonable.
On all three servers:
sudo nano /etc/hostsAdd:
192.168.10.1 db1.example.com db1
192.168.10.2 db2.example.com db2
192.168.10.3 db3.example.com db3Then:
ping db1
ping db2
ping db3Step 5 — Update Debian
Do this on all three:
sudo apt update
sudo apt full-upgrade -y
sudo rebootReconnect after the reboot.
Step 6 — Install MariaDB/Galera
Here’s where I want to be careful about versions.
Since you’re using Debian 13, I recommend using a current MariaDB release that explicitly supports Debian 13 rather than blindly following an old Galera tutorial. MariaDB currently publishes Debian 13 packages including Galera 4; current MariaDB releases include Debian 13 builds. (MariaDB)
We should choose the exact MariaDB version before installing it, because all three Galera nodes need to be compatible.
I would currently lean toward a supported MariaDB 11.x release rather than an old tutorial’s MariaDB version.
Step 7 — Firewall
Before we start Galera, we need to allow the Galera traffic only over the private network.
Galera uses several ports/protocols, including:
3306 MariaDB
4567 Galera replication
4568 Galera IST
4444 SSTWe’ll restrict those to:
192.168.10.0/24rather than exposing them to the Internet.
This is important.
Your public interface should not be accepting Galera replication traffic from arbitrary Internet hosts.
Step 8 — Galera configuration
The important settings will eventually look approximately like:
[mysqld]
bind-address = 0.0.0.0
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = my-galera-cluster
wsrep_cluster_address = gcomm://db1,db2,db3
wsrep_node_name = db1
wsrep_node_address = 192.168.10.1On db2, the node-specific values become:
wsrep_node_name = db2
wsrep_node_address = 192.168.10.2And db3:
wsrep_node_name = db3
wsrep_node_address = 192.168.10.3The exact provider path and package configuration depend on the MariaDB version we install, so don’t paste this configuration yet. We’ll use the configuration appropriate to the installed package.
MariaDB’s current Galera documentation uses the same fundamental architecture: wsrep_on, a Galera provider, a gcomm:// cluster address, and ROW binlogging. (MariaDB)
Step 9 — Bootstrap db1
This is the one step where we have to be particularly careful.
The first node is bootstrapped to create the initial Galera primary component.
MariaDB provides:
galera_new_clusterfor this purpose. MariaDB’s own HA documentation demonstrates bootstrapping the first node this way, then starting the remaining nodes normally. (MariaDB)
On db1 only:
sudo galera_new_clusterThen:
sudo mariadbCheck:
SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';Initially:
wsrep_cluster_size
1And:
SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';should show:
SyncedDon’t proceed until db1 is healthy.
Step 10 — Join db2
Once db1 is healthy, go to db2:
sudo systemctl start mariadbThen check:
sudo mariadband:
SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';You should now see:
2Check db1 again:
SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';It should also show:
2Step 11 — Join db3
On db3:
sudo systemctl start mariadbThen check:
SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';You should get:
3And:
SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';should show:
SyncedAt that point:
┌───────────┐
│ db1 │
│ Synced │
└─────┬─────┘
│
┌──────┴──────┐
│ │
┌─────▼─────┐ ┌─────▼─────┐
│ db2 │ │ db3 │
│ Synced │ │ Synced │
└───────────┘ └───────────┘
wsrep_cluster_size = 3You now have your three-node Galera cluster.
But don’t stop there
Once the basic cluster works, there are several things I’d configure before putting WordPress/Nextcloud/LAMP production databases on it:
- Firewall
- MariaDB security
- Galera SST authentication
- Proper SST method
- Database users
- ProxySQL
- Monitoring
- B2 backups
- Galera recovery procedures
- Testing node failure
- Testing complete cluster failure
- Testing restoration from backup
And particularly important for your 4-GB nodes: we’ll tune MariaDB’s memory usage conservatively rather than assuming a large server.
One thing I recommend changing from our earlier plan
Because HostHatch provides private networking in the same location, I’d use that for Galera replication and reserve WireGuard for your broader infrastructure network. HostHatch’s private network is isolated at the VLAN/VXLAN level and doesn’t count against your VM’s normal bandwidth allowance. (HostHatch Docs)
So your eventual network becomes:
INTERNET
│
Public interface
│
┌──────┴──────┐
│ │
Web 1 Web 2
│ │
└──────┬──────┘
│
ProxySQL
│
HostHatch PRIVATE NETWORK
│
┌────────┼────────┐
│ │ │
db1 db2 db3
│ │ │
└────────┼────────┘
GALERALet’s do this interactively rather than giving you 50 commands at once. If you’ve already created the three VPSs, start with db1 and run:
hostnamectl
ip -br addr
ip -br link
ip -o link | grep 00:22Paste the output here. I’ll tell you exactly what to configure for the HostHatch private interface before we touch MariaDB.