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.3

And:

db1 = Galera node 1
db2 = Galera node 2
db3 = Galera node 3

Your 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 quorum

Step 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 link

and:

ip -o link | grep 00:22

You should find the HostHatch private interface. HostHatch says the private interface MAC begins with 00:22. (HostHatch Docs)

Then:

ip -br addr

Initially you’ll probably see something like:

eth0    UP    <public IP>
enp2s0   DOWN

We’ll assign:

db1 → 192.168.10.1/24
db2 → 192.168.10.2/24
db3 → 192.168.10.3/24

Do 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.network

Put:

[Match]
Name=enp2s0

[Network]
Address=192.168.10.1/24

Then:

sudo networkctl reload
sudo networkctl reconfigure enp2s0

Check:

ip addr show enp2s0
networkctl status enp2s0

You should see:

192.168.10.1/24

Repeat on db2 and db3, changing the address.

Step 3 — Test the private network

From db1:

ping 192.168.10.2

and:

ping 192.168.10.3

From db2:

ping 192.168.10.1

and:

ping 192.168.10.3

And from db3:

ping 192.168.10.1

and:

ping 192.168.10.2

Don’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.com

On db2:

sudo hostnamectl set-hostname db2.example.com

On db3:

sudo hostnamectl set-hostname db3.example.com

Then 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/hosts

Add:

192.168.10.1    db1.example.com db1
192.168.10.2    db2.example.com db2
192.168.10.3    db3.example.com db3

Then:

ping db1
ping db2
ping db3

Step 5 — Update Debian

Do this on all three:

sudo apt update
sudo apt full-upgrade -y
sudo reboot

Reconnect 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   SST

We’ll restrict those to:

192.168.10.0/24

rather 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.1

On db2, the node-specific values become:

wsrep_node_name = db2
wsrep_node_address = 192.168.10.2

And db3:

wsrep_node_name = db3
wsrep_node_address = 192.168.10.3

The 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_cluster

for 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_cluster

Then:

sudo mariadb

Check:

SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';

Initially:

wsrep_cluster_size
1

And:

SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';

should show:

Synced

Don’t proceed until db1 is healthy.

Step 10 — Join db2

Once db1 is healthy, go to db2:

sudo systemctl start mariadb

Then check:

sudo mariadb

and:

SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';

You should now see:

Check db1 again:

SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';

It should also show:

Step 11 — Join db3

On db3:

sudo systemctl start mariadb

Then check:

SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';

You should get:

And:

SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';

should show:

Synced

At that point:

        ┌───────────┐
        │   db1     │
        │  Synced   │
        └─────┬─────┘
              │
       ┌──────┴──────┐
       │             │
 ┌─────▼─────┐ ┌─────▼─────┐
 │    db2    │ │    db3    │
 │  Synced   │ │  Synced   │
 └───────────┘ └───────────┘

     wsrep_cluster_size = 3

You 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
        │        │        │
        └────────┼────────┘
              GALERA

Let’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:22

Paste the output here. I’ll tell you exactly what to configure for the HostHatch private interface before we touch MariaDB.

Upods.net

Your Technology Source

Galera Server Setup on HostHatch

Target setup

Step 1 — Create the three VPSs

Step 2 — Configure the private network

Step 3 — Test the private network

Step 4 — Configure hostnames

Step 5 — Update Debian

Step 6 — Install MariaDB/Galera

Step 7 — Firewall

Step 8 — Galera configuration

Step 9 — Bootstrap db1

Step 10 — Join db2

Step 11 — Join db3

But don’t stop there

One thing I recommend changing from our earlier plan

Leave a Reply Cancel reply