Database redundancy for MU Online servers
Implement database redundancy on your MU Online server using replication, automatic failover, and multi-layered backups to avoid lost progress and prolonged downtime.
A MU Online server that depends on a single database with no redundancy is one disk failure away from losing all player progress. Database redundancy is the practice of keeping synchronized copies and contingency mechanisms so that a hardware, network, or service failure doesn't mean lost data or ho
A MU Online server that depends on a single database with no redundancy is one disk failure away from losing all player progress. Database redundancy is the practice of keeping synchronized copies and contingency mechanisms so that a hardware, network, or service failure doesn't mean lost data or hours of downtime. This tutorial covers the concepts, setting up MySQL master-slave replication, failover strategies, and how this fits into the daily operation of a private server.
Why redundancy is different from backup
A backup is a snapshot of the database at one point in time, useful for recovery after corruption or human error, but it requires manual restoration and implies losing data generated after the last snapshot. Redundancy keeps one or more live copies updated in near real time, letting you keep operating (or quickly resume operating) even if the main server goes down. The two mechanisms are complementary, not substitutes.
Most common redundancy architectures
| Architecture | How it works | Complexity | Best for |
|---|---|---|---|
| Master-Slave (asynchronous replication) | One server writes, one or more replicate in read mode | Medium | Most private MU servers |
| Master-Master | Two servers accept writes, replicate to each other | High | Large servers needing high availability |
| Cluster (Galera/InnoDB Cluster) | Multiple synchronized nodes, automatic failover | High | Large-scale servers, dedicated infra teams |
| Frequent incremental backup | Snapshots every few hours, no live replica | Low | Small servers, no budget for a second machine |
Prerequisites for setting up redundancy
- Two MySQL/MariaDB instances, ideally on different physical servers or VPS.
- Root access to both database servers.
- Reliable network connectivity between master and slave (VPN or the provider's private network, avoiding exposing port 3306 publicly).
- Enough disk space on the slave to hold the master's full data volume.
Setting up master-slave replication
On the master server, enable binlog in the configuration file (my.cnf or my.ini):
[mysqld]
server-id = 1
log_bin = mysql-bin
binlog_do_db = mu_onlineCreate a dedicated replication user:
CREATE USER 'replica_user'@'%' IDENTIFIED BY 'SenhaForteAqui123';
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'%';
FLUSH PRIVILEGES;On the slave server, configure a different server-id and point it to the master:
[mysqld]
server-id = 2CHANGE MASTER TO
MASTER_HOST='ip_do_master',
MASTER_USER='replica_user',
MASTER_PASSWORD='SenhaForteAqui123',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS= 0;
START SLAVE;Checking replication status
After starting it, confirm the replica is syncing correctly:
SHOW SLAVE STATUS\GThe key fields to watch are Slave_IO_Running and Slave_SQL_Running (both should be Yes) and Seconds_Behind_Master (ideally close to 0). A high value in that last field indicates replica lag, which can be caused by excessive write load on the master or weaker hardware on the slave.
Failover: what to do when the master goes down
Redundancy only has practical value if failover is fast. There are two paths:
- Manual failover: an administrator detects the outage, promotes the slave (
STOP SLAVE; RESET MASTER;) and repoints the GameServer's connection string to the new address. Simple, but depends on someone noticing and acting quickly. - Automated failover: tools like ProxySQL, Orchestrator, or MHA monitor the master and automatically promote the slave, redirecting connections without manual intervention. More complex to set up, but cuts downtime from minutes to seconds.
Comparing manual and automated failover
| Criterion | Manual | Automated (ProxySQL/Orchestrator) |
|---|---|---|
| Response time | Minutes to hours (depends on who detects it) | Seconds to a few minutes |
| Setup complexity | Low | High, requires additional tooling |
| Risk of human error | High under pressure | Low, standardized process |
| Maintenance cost | Low | Medium, requires monitoring the tool itself |
| Best for | Small/medium servers | Servers with a large active player base |
Redundancy doesn't eliminate the need for monitoring
A silently outdated slave is worse than having no redundancy at all, because it creates a false sense of security. Set up alerts (email, Discord webhook) for when Seconds_Behind_Master exceeds a threshold (for example, 30 seconds) or when Slave_IO_Running/Slave_SQL_Running stop, so the infra team knows immediately that redundancy is compromised.
Combining redundancy with layered backups
Redundancy covers hardware failure; backup covers human error and logical corruption. A robust strategy combines both:
| Layer | Frequency | Protects against |
|---|---|---|
| Real-time slave replica | Continuous | Master hardware/network failure |
| Logical backup (mysqldump) | Every 4-6 hours | Human error, isolated corruption |
| Physical backup (disk snapshot) | Daily | Catastrophic failure, fast recovery |
| Off-site backup (outside the datacenter) | Daily/weekly | Datacenter disaster, ransomware |
Testing the redundancy plan periodically
Redundancy that's never tested is theoretical redundancy. Schedule quarterly simulations of master downtime (in a staging environment, if possible) to validate that the slave takes over correctly, that the GameServer reconnects without data corruption, and that the team knows how to run the failover procedure without consulting documentation from scratch.
Common errors and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Slave_IO_Running = No | Network issue or wrong replication credential | Review connectivity and the replication user |
| Seconds_Behind_Master growing | Slave has weaker hardware or master under heavy load | Upgrade slave resources or optimize master queries |
| Data diverging between master and slave | Accidental direct write on the slave | Configure the slave as read-only (read_only = 1) |
| Manual failover took too long | No documented process and no alerts | Document the step-by-step and set up automatic alerts |
| Replica won't start after server restart | Binlog position not persisted correctly | Use GTID instead of log position for more resilience |
| Long downtime even with redundancy | No automated failover | Evaluate ProxySQL/Orchestrator to reduce response time |
Database redundancy checklist
- Slave replica configured and syncing (
Slave_IO/SQL_Running = Yes). - Replication user with a strong password and minimal required permissions.
- Slave configured as read-only to prevent divergence.
- Alerts configured for replication lag or failure.
- Failover process (manual or automated) documented.
- Logical and physical backups configured as complementary layers.
- Failover simulation tested in a controlled environment.
With redundancy up and running, the natural next step is to review the overall server architecture to ensure other components (GameServer, ConnectServer, web panel) also have a contingency plan — check the MU Online server setup tutorial to review the foundation of the complete infrastructure.
Frequently asked questions
Does database redundancy replace the need for backups?
No. Redundancy protects against hardware failure and momentary unavailability, but not against human error, logical data corruption, or an accidental DELETE that instantly replicates to every node. Backups remain essential even with active redundancy.
Do I need two separate physical servers to have redundancy?
Ideally yes, or at least two VPS in different providers/regions. Having a replica on the same physical machine protects against data corruption, but not against hardware failure, power loss, or a network issue affecting the whole machine.
What's the difference between synchronous and asynchronous replication in MySQL?
In asynchronous replication (the most common for MU), the master confirms the transaction without waiting for the replica to apply it, which is faster but can cause a small lag on the replica. Synchronous replication waits for the replica's confirmation before committing, safer but with higher latency — rarely used in MU because of the performance cost.
What happens to the GameServer during a failover?
It depends on how the failover is implemented. With a database proxy (like ProxySQL) or an automated failover script, the switch can be nearly transparent, with just a few seconds of reconnection. Without automation, the GameServer freezes until an administrator manually points the new connection string to the promoted slave.
Does master-slave replication impact the main server's performance?
The impact is minimal in most cases, since asynchronous replication doesn't block the master waiting for the replica. The main cost is I/O and network overhead for transmitting the binlog, generally negligible compared to a MU GameServer's normal load.