- A MariaDB Galera Cluster is a type of database setup that keeps your data synchronized across multiple servers (nodes) in real-time. Its main purpose is to provide high availability and prevent data loss.
- Think of it like a team of scribes writing the same book simultaneously. When one scribe adds a sentence, they all instantly add the exact same sentence to their copy, ensuring every book is always identical.
In contrast with the classic set up of Main -> Replica(s) with only one node being writable, a Galera Cluster is a synchronous multi-master database solution – to break it down:
- Multi-Master: Unlike traditional setups where you have one main database and several read-only copies, a Galera cluster allows you to read and write to any node in the cluster. This distributes the workload and eliminates a single bottleneck, providing high availability for both read and write operations.
- Synchronous Replication: When you run a transaction (like
INSERT,UPDATE, orDELETE) on one node, it doesn’t complete until it has been successfully replicated and confirmed by all other nodes in the cluster. This guarantees that all nodes have the exact same data at the exact same time, preventing data inconsistencies.
Advantages of having a Galera cluster
- Redundancy: Each Proxmox node holds a full, independent copy of the database. If one entire Proxmox server crashes, goes down for maintenance, or loses power, your database service continues to operate – there is no single point of failure.
- Automatic Failover: Applications connected to the database can simply redirect their queries to the remaining online nodes. Since all nodes are masters and have identical data, the transition is seamless with no downtime for the application and no data loss.
- Easy Maintenance: You can perform maintenance on one Proxmox host (like kernel updates or hardware upgrades) by shutting down its MariaDB VM. The rest of the cluster continues to run without issue. Once the maintenance is done and the node rejoins, Galera automatically synchronizes it with any changes that occurred while it was offline.
The role of an Arbitrator
- Imagine that you have two proxmox nodes each with two galera nodes and one Proxmox node goes down. That means that 50% of nodes is down and there is no majority.
- This would result in the Galera cluster failing to operate as it requires a majority. An Arbitrator is a device that holds no data but is a separate device that can help determine which part of the cluster is healthy and help preventing a split-brain scenario.
- We will use an Arbitrator later in our set up using a simple Raspberry Pi.
Benefits for Home or Hybrid Setups
- At Home: If you have two or more physical machines running Proxmox, you can create an enterprise-grade, fault-tolerant database for critical home services like Home Assistant, Nextcloud, your websites, monitoring systems like UptimeKuma or Zabbix and other development projects. If one server fails, your smart home or personal cloud stays online.
- Hybrid Mode: This is where it gets interesting. You can run some Galera nodes on your existing Proxmox node at home and other Galera cluster nodes in a cloud server (like a cheap VPS or dedicated server) or it could be someone else’s home who has a decent connection (or two). The Galera Cluster can span both locations over a VPN (like a WireGuard Site-to-Site VPN). This gives you geographic redundancy. If your home loses internet or power, the cloud node takes over, ensuring your database is always accessible. This is a cost-effective way to achieve disaster recovery without owning multiple physical locations.
In this guide, we will focus on the home set up but can cover a multi-site set up in the near future.
Pre-requisites
- Basic Linux knowledge
- Load Balancer – this guide will cover in detail how to set up HAProxy on OPNSense from scratch.
- You have one or more Proxmox nodes (or another type 1 hypervisor such as VMWare, Harvester, etc.).
- You have one or more OPNSense units (can be virtualized but then it is best deployed with CARP on two or more Proxmox nodes).
- LXC containers (could be a Proxmox template) of your favorite Linux disto. This guide covers Debian 13 (Trixie). Preferably, give the container a name that indicates it will be used as a template, such as ‘galera-template’. We can then have a cluster ‘A’ with number 1-4, for example, such as ‘galera-A1, galera-A2, etc.’.
- Optional: A Raspberry Pi used as the fifth member of a quorum (no data stored). Its importance will be explained later in this guide.
- Here is the full diagram for our set up:
