Database Clustering: High availability and redundancy
Learn about database clustering for high availability. Understand cluster types, when to use them, and implementation on UnderHost VPS servers.
UnderHost NOC
Network Operations
On this page
Database clustering connects multiple database servers together so they act as one. If one server fails, another automatically takes over. Your application continues running without downtime.
What is database clustering?
A cluster is multiple database servers configured to share the same data. Requests are distributed across servers, and if one fails, others continue serving data. Common goals:
- High Availability (HA): Database stays online even if one server fails
- Load Balancing: Spread query load across multiple servers
- Redundancy: Multiple copies of data protect against total data loss
Why use clustering?
| Without Cluster | With Cluster |
|---|---|
| One server fails = database offline = website down | Server fails = cluster automatically failover = site stays up |
| Heavy queries slow down other users | Queries distributed = faster for everyone |
| Hardware failure = potential data loss | Data replicated = multiple copies protect against loss |
| Backups are your only protection | Backups + redundant servers = stronger protection |
Clustering types
Master-Slave (most common):
- One master server handles writes
- Slave servers read-only copies for queries
- Simple, easy to set up
- If master fails, someone must manually promote slave
Master-Master (mutual replication):
- Two servers both accept reads and writes
- Changes replicate bidirectionally
- More complex; conflict resolution needed
Galera Cluster (synchronous):
- All servers synchronized in real-time
- Any server can be primary
- Automatic failover
- Most complex; best for large deployments
Requirements and costs
| Resource | Requirement |
|---|---|
| Minimum servers | 2 (master + slave); 3+ for automatic failover |
| Network | Low-latency, reliable connection between servers (same datacenter preferred) |
| Storage | At least 2x your database size (on each node) |
| Configuration | Complex; requires expertise or managed service |
| Cost | Multiple VPS servers = multiplied monthly costs |
| Maintenance | Requires monitoring, failover testing, replication monitoring |
Clustering at UnderHost
Shared Hosting: Not available. Contact support if you need database redundancy.
Cloud VPS: You can set up clustering yourself using multiple VPS servers:
# On master server
# Enable binary logging in /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
log_bin = mysql-bin
server-id = 1
# On slave server
server-id = 2
# Then replicate on slave
CHANGE MASTER TO
MASTER_HOST = 'master-ip',
MASTER_USER = 'replication',
MASTER_PASSWORD = 'password';
START SLAVE;Dedicated Servers: Full support for clustering. Can use multiple dedicated servers or UnderHost's managed clustering solutions.
When do you need clustering?
You probably DON'T need clustering if:
- Your website is small-medium traffic (less than 10,000 visits/day)
- Database downtime is rare (modern servers are stable)
- You have regular backups (restore from backup when issues occur)
- You can tolerate 30 minutes of downtime
You MIGHT need clustering if:
- Your application is heavily database-dependent (ecommerce with many SKUs, SaaS)
- Any downtime costs significant money
- You have thousands of concurrent database connections
- You're growing and need better redundancy
Clustering is essential if:
- You have compliance requirements (HIPAA, financial systems requiring HA)
- You're running critical business infrastructure
- You need 99.99% uptime SLA
Clustering adds complexity, cost, and operational overhead. Backups + solid hosting (UnderHost VPS) covers most use cases. Only implement clustering if downtime creates real business impact.
Related: Database optimization | MySQL replication | VPS disaster recovery
Need hosting for database-backed apps?
Run WordPress, CMS, PHP apps, and MySQL/MariaDB workloads on UnderHost hosting, VPS, or managed servers.
