MySQL and MariaDB replication
One database server is a single point of failure and a single point of backup pain. Replication gives you a live copy — for reads, for backups, and for the day the primary dies.
Replication streams changes from a primary database to one or more replicas. It is the simplest way to get a second copy that is always current — and it solves three different problems at once.
What a replica buys you
- Backups taken off the replica never slow the primary — see backups
- Read-heavy applications can send queries to replicas
- If the primary dies, a replica is minutes from being promoted, not hours of restore
Asynchronous by default
Standard replication is asynchronous: the replica is a little behind the primary. For most uses that lag is milliseconds and harmless, but you must design for it — a read sent to a replica immediately after a write may not see that write yet. Know where that matters in your application.
Back up from the replica
The classic win: run your dump or snapshot against the replica so the primary never feels it. Just confirm the replica is actually caught up before you trust the backup — a backup from a lagging, broken replica is worse than none.
Galera for true high availability
If you need every node to accept writes and stay in sync, MariaDB’s Galera cluster does synchronous, multi-primary replication across three nodes. It is more to run and it changes how writes behave, but it is genuine high availability rather than a warm spare. See high availability, honestly.
Monitor the lag
Replication fails quietly: a replica stops applying changes and drifts, and nobody notices until failover day. Alert on replica lag and on the replication threads actually running — see monitoring your own server.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base