How to scale the database (replicas and hot backup) in MU Online

The database is the most valuable asset of a MU Online server. GameServers can go down and come back, the proxy can be swapped, the site can be offline for minutes, but if the database corrupts or is lost, everything vanishes: accounts, characters, items, resets, guilds, history. As the population grows, the database also becomes a bottleneck — ranking queries weigh it down, the site consumes reads, GameServers compete for writes, and a spike in access can make the whole game slow. Scaling the database with read replicas and protecting the data with hot backup solves both problems at once: more capacity and more security.

This tutorial shows how to separate reads from writes using replicas, how to configure backups without bringing the server down, how to plan retention, and how to test the restore — because a backup that has never been restored is not a backup, it's hope. The commands, names, and values here are examples and vary by DBMS (SQL Server, MySQL/MariaDB, PostgreSQL) and by your emulator's version. What does not vary are the principles of consistency, replication, and recovery.

Where the database becomes a bottleneck in MU

Before scaling, understand the load. Database traffic in MU splits into two very distinct types:

• Critical writes: saving a character, moving an item, updating zen, applying a reset, recording a guild. It must go to a single authoritative point, the primary, so there's no conflict or duplicated item.
• Heavy reads: rankings, online counts, site statistics, admin panel, logs. It changes nothing and can be served by copies.

The common mistake is to throw everything at the same database and watch the ranking site freeze the game during peak hours. The scaling strategy starts by separating these two worlds: writes concentrated and consistent on the primary, reads distributed across replicas.

Prerequisites

Before starting:

• A working MU server with the database already in production. If you're still at the base, see how to create a MU Online server first.
• Knowing which DBMS you use. Many MU emulators use SQL Server; forks and modern versions may use MySQL/MariaDB. The replication and backup mechanisms differ between them.
• Additional machine(s) to host the replica and/or backup destination, ideally in a separate location from the primary.
• Administrative access to the DBMS (a user with permission to configure replication and backup).
• Storage space planned for backups. Estimate the database size and multiply by the desired retention. Example: a database of a few GB with several days of retention requires dozens of GB reserved (varies by population and frequency).
• A scheduling tool (SQL Server Agent, cron, scheduled tasks) to automate backups.

Note the recovery model you want. It defines how much progress is acceptable to lose in a disaster (the so-called RPO) and how long you tolerate being unavailable (the RTO). These two numbers guide all the decisions below.

Step 1 — Define RPO and RTO

The entire database strategy stems from two questions:

• RPO (how much can I lose?): if the database dies right now, do I accept losing 5 minutes of gameplay? 1 hour? A day? The smaller the RPO, the more frequent and sophisticated the backups.
• RTO (how long can I be down?): how long can the server stay offline while you restore? Minutes require a replica with failover; hours allow a backup restore.

An example of a reasonable target for a mid-sized server: an RPO of a few minutes (with frequent transaction logs) and an RTO of under an hour (with a hot backup ready and, ideally, a replica). Adjust to your project's size and seriousness.

Step 2 — Configure the recovery model and backup types

In SQL Server, the recovery model determines what's possible. To allow a point-in-time restore, use the FULL model, which keeps the transaction log until the log backup.

The three backup types that make up a solid strategy:

Example backup commands in SQL Server (names and paths are illustrative):

-- Full backup
BACKUP DATABASE MuOnline
TO DISK = 'D:\Backups\MuOnline_full.bak'
WITH INIT, COMPRESSION;

-- Differential backup
BACKUP DATABASE MuOnline
TO DISK = 'D:\Backups\MuOnline_diff.bak'
WITH DIFFERENTIAL, INIT, COMPRESSION;

-- Transaction log backup
BACKUP LOG MuOnline
TO DISK = 'D:\Backups\MuOnline_log.trn'
WITH INIT;

In MySQL/MariaDB, the equivalent for a hot backup is usually done with tools like the consistent dump mechanism or physical snapshots with binlog enabled for point-in-time. The concept is the same: a periodic base + a continuous log. Adapt it to your DBMS.

Step 3 — Take a hot backup without bringing the server down

The core point of a hot backup is that it runs with the database online, without kicking players out. Modern DBMSs support this natively: the backup reads a consistent image while the game keeps writing.

Hot backup best practices:

1. Write the backup to a different disk/volume from the database, so a disk failure doesn't take the data and the backup together.
2. Copy the backup off the machine right afterward (another server, remote storage). A backup on the same machine as the database protects little.
3. Enable compression to reduce space and transfer time.
4. Schedule the backups for lower-traffic hours for the full, and frequent for the log.
5. Verify the integrity of the generated file (checksum/verify) so you don't find out too late that it's corrupted.

Example of backup verification in SQL Server:

RESTORE VERIFYONLY
FROM DISK = 'D:\Backups\MuOnline_full.bak';

Never trust a backup that hasn't passed verification and, more importantly, that has never actually been restored (see Step 6).

Step 4 — Configure a read replica

The replica is a copy of the database kept in sync with the primary, used to serve reads and as a failover candidate. The idea: the site, the rankings, and reports hit the replica; the GameServers keep writing to the primary.

The technologies vary:

• SQL Server: Always On Availability Groups (readable secondary replica), Log Shipping, or transactional replication.
• MySQL/MariaDB: binlog-based primary-replica replication (asynchronous or semi-synchronous).
• PostgreSQL: streaming replication with hot standby.

The conceptual flow for setting up a read replica:

1. Restore a recent copy of the database on the replica machine.
2. Connect the replica to the primary via the DBMS's replication mechanism.
3. The replica starts continuously applying the primary's changes.
4. Point non-critical reads (site, ranking) to the replica.

A crucial detail: replication is usually asynchronous, meaning the replica may be a few seconds behind the primary. For rankings and the site, that lag is irrelevant. For game writes, never use the replica — the source of truth is always the primary, or you risk item duplication.

Step 5 — Direct the right reads to the replica

Having the replica is useless if nothing uses it. Redirect deliberately:

• Site and panel: point the site's read connection string to the replica.
• Rankings and statistics: heavy, periodic queries should run on the replica.
• Admin reports: auditing and metrics on the replica or on a dedicated replica just for that.
• Game (GameServer/DataServer): stays 100% on the primary, reads and writes, to guarantee session consistency.

A clear separation of connection strings:

This frees the primary to focus on what matters: recording players' progress without freezing.

Step 6 — Actually test the restore

This is the step almost everyone skips and the one that separates those who have a backup from those who only think they do. A backup is only valid if you have already restored it and confirmed that the game boots.

Restore test routine:

1. Take the most recent backup (full + differential + logs).
2. Restore it on a separate machine or instance, never over production.
3. Boot a test GameServer pointing to the restored database.
4. Verify: accounts exist, characters have items, resets and zen match.
5. Time the whole process — that's your real RTO.

Example of a point-in-time restore in SQL Server:

-- Restore the full with NORECOVERY to apply more backups
RESTORE DATABASE MuOnline_Teste
FROM DISK = 'D:\Backups\MuOnline_full.bak'
WITH NORECOVERY, MOVE 'MuOnline' TO 'D:\Data\MuOnline_Teste.mdf',
     MOVE 'MuOnline_log' TO 'D:\Data\MuOnline_Teste.ldf';

-- Apply logs up to a specific instant
RESTORE LOG MuOnline_Teste
FROM DISK = 'D:\Backups\MuOnline_log.trn'
WITH RECOVERY, STOPAT = '2026-07-14T22:15:00';

Run this test periodically, not just once. Backups and versions change, and an old test doesn't guarantee today's.

Step 7 — Plan failover

Failover is what you do when the primary really dies. With a ready replica, the plan is to promote it to primary and repoint the GameServers to it.

Elements of a failover plan:

• An up-to-date, verified replica, ready to become the primary.
• A documented promotion procedure (the exact commands for your DBMS).
• Repointing the connection strings of the GameServers/DataServer to the new primary.
• Communication with the players about the emergency maintenance.
• A decision on automation: automatic failover reduces the RTO but demands careful configuration (e.g. Always On with a witness) to avoid "split brain".

Even a well-rehearsed manual failover that takes a few minutes is already a huge leap in resilience compared to having no plan at all.

Step 8 — Maintenance and retention

A scaled database requires continuous maintenance, or it degrades:

• Backup retention: keep a window (e.g. several days of full + logs) and discard what's past it, controlling storage cost. Keep at least one off-site copy.
• Indexes and statistics: reorganize/rebuild indexes periodically to keep queries fast.
• Replica lag monitoring: alert if the replica falls too far behind the primary.
• Space monitoring: a transaction log that isn't backed up grows without stopping and fills the disk.
• Backup failure alerts: a backup that failed silently is a disaster waiting to happen.

Common errors and fixes

Launch checklist

• RPO and RTO defined and documented
• Appropriate recovery model (e.g. FULL in SQL Server)
• Full backup scheduled
• Differential and log backups scheduled according to the RPO
• Hot backup running without bringing the server down
• Backups written to a different disk and copied off the machine
• Integrity verification after each backup
• Read replica configured and syncing
• Site, ranking, and reports pointing to the replica
• GameServer/DataServer pointing only to the primary
• Restore tested in a separate environment and RTO timed
• Failover plan documented and rehearsed
• Retention defined with an off-site copy
• Monitoring of lag, space, and backup failures active

Conclusion

Scaling a MU Online server's database is, at the same time, a job of performance and of survival. Read replicas take the weight of rankings, sites, and reports off the primary, leaving it free to record players' progress consistently. Hot backup ensures that, whatever happens, you can return to a point in time without having brought the server down to do it. And the failover plan turns a disaster of lost days into a maintenance of minutes. Treat the commands, sizes, and frequencies in this guide as examples and adjust them to your DBMS and your Season, but never give up the principles: writes concentrated on the primary, reads distributed, a tested backup, and a rehearsed recovery. That's what separates a server that loses everything in an incident from one that survives and keeps growing.

Frequently asked questions