MySQL Replication, High Availability, Backup and Recovery in Production

How I design MySQL primary-replica systems around failover, replica lag, read consistency, binary logs, backups and tested recovery.

Why this matters in production

Replication improves availability and read distribution, but it can also expose stale reads and operational ambiguity when failover and recovery procedures are not practiced.

The database is not a passive persistence layer. It is a concurrency system, a cache hierarchy, a durability mechanism and often the most stateful dependency in the architecture. I therefore review database design together with API behavior, background jobs, failure recovery, deployment and observability.

A design that performs well on a development dataset can fail very differently under production cardinality. More rows or documents change selectivity, working-set size, lock duration, cache hit rate, replication lag and maintenance cost. My objective is predictable behavior rather than one impressive benchmark.

The decision model I use

1. Define the consistency of replica reads

Reporting and browsing may tolerate lag; immediate confirmation screens often should not.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

2. Monitor replication delay and errors

Lag is a capacity signal and a correctness consideration.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

3. Make failover ownership explicit

Automated or manual promotion needs fencing so the old primary cannot continue accepting writes.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

4. Preserve binary logs for recovery needs

Point-in-time recovery depends on having both a usable base backup and the required log history.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

5. Separate backup from replica topology

A replica can reproduce accidental deletes quickly. It is not an independent recovery copy.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

6. Practice full restore

Measure how long it takes to restore data, apply logs and reconnect the application.

In an architecture review I convert this into a measurable question: what workload assumption makes this choice correct, what signal would tell us that assumption is no longer true, and what is the operational response? That prevents a database feature from becoming a permanent design decision simply because it worked on the first release.

Reference implementation

-- Useful operational checks vary by topology/version.
SHOW REPLICA STATUS\G

-- After restore of a base backup, binary-log positions
-- or GTID state are used to recover to the target point.
SELECT @@gtid_mode, @@server_uuid;

The example is deliberately focused on the decision rather than framework boilerplate. In production I also capture the query or command frequency, expected cardinality, latency target and failure behavior so the database choice can be tested against an explicit workload.

Data modeling and ownership

I want every table, collection or document family to have a clear application owner. Shared read access may be appropriate, but shared write ownership creates coupling quickly. When multiple services write the same data directly, schema changes become coordinated releases and business invariants become difficult to locate.

I also distinguish transactional data from analytical or historical data. A primary operational database should not carry unlimited reporting pressure just because the information is available there. Read replicas, projections, warehouses, archival stores or asynchronous exports can protect the transactional path.

Performance methodology

I do not begin tuning with configuration switches. I start with a representative slow operation and evidence: execution plan, rows/keys examined, buffer/cache behavior, lock waits, I/O, CPU, connection saturation and the distribution of latency.

The first optimization is frequently reducing work: read fewer rows, project fewer columns/fields, index the actual predicate, remove a query loop, batch work, or change the data model so the hot path does not reconstruct a large object graph.

After a change, I measure the write cost as well. Indexes, materialized projections, denormalized fields and additional replicas all improve some reads by moving work elsewhere.

Concurrency and transaction boundaries

A transaction should protect one coherent consistency decision and then finish. I avoid remote network calls while database locks or snapshots are held. When a workflow crosses services, I prefer local transactions plus explicit messaging/outbox/saga patterns instead of attempting to stretch a database transaction across remote dependencies.

Concurrency failures are normal production behavior. Deadlocks, serialization failures, duplicate messages and failover retries need bounded retry policies and idempotent business behavior. Retrying blindly can duplicate a payment, booking, order or notification even if the database itself remains consistent.

High availability is application behavior

A replica, standby or cluster only provides infrastructure capability. The application still needs timeouts, reconnect behavior, read-consistency rules and a tested response to role changes.

I document which requests can tolerate stale data, which writes require stronger acknowledgement and what happens during a failover window. This is especially important for confirmation pages, inventory, payments and other workflows where users expect read-after-write behavior.

Backup and recovery

Replication is not a backup. A bad migration, accidental delete or corrupted logical state can replicate successfully.

For each production database I want a recovery-point objective and recovery-time objective. Backups are encrypted, retained independently and tested by restoring into another environment. The test is not complete when files are restored; it is complete when the application can connect and critical integrity checks pass.

Point-in-time recovery also needs enough log history—binary log, WAL or equivalent—to reach the target moment. Retention therefore needs to match the recovery policy.

Observability I expect

At database level I monitor query latency, throughput, active connections, connection-pool wait, replication lag, lock waits, storage growth and slow-query evidence. Engine-specific signals such as vacuum/bloat, buffer-pool behavior or document/index size are then layered on top.

At application level, database spans and metrics should identify the logical operation without emitting sensitive SQL parameters or document payloads. The goal is to connect a slow user request to a specific database operation and its saturation signal.

Failure modes I design against

• Routing read-after-write flows to any replica. I treat this as a production risk because it can increase latency, widen the failure domain or make recovery behavior ambiguous.
• Promoting a replica while the old primary is still writable. I treat this as a production risk because it can increase latency, widen the failure domain or make recovery behavior ambiguous.
• Keeping backups without verifying they can be restored. I treat this as a production risk because it can increase latency, widen the failure domain or make recovery behavior ambiguous.
• Discovering during an incident that log retention is shorter than the recovery window. I treat this as a production risk because it can increase latency, widen the failure domain or make recovery behavior ambiguous.

These failure modes are useful review prompts because they turn a generic “database best practice” discussion into a concrete production scenario. If the team cannot explain how the system behaves under one of these conditions, that behavior is still an architectural unknown.

Deployment and migration strategy

Schema and index changes are production deployments. I prefer backward-compatible migrations that allow old and new application versions to overlap. Large index builds, backfills, partition changes or validation work are scheduled and monitored rather than hidden inside application startup.

When a change can create heavy I/O or locks, I test it against production-like volume and define a stop condition. A migration plan should include how to pause, roll forward or recover if runtime behavior differs from the estimate.

Production checklist

• Define the consistency of replica reads: the workload assumption and operational owner are documented.
• Monitor replication delay and errors: the workload assumption and operational owner are documented.
• Make failover ownership explicit: the workload assumption and operational owner are documented.
• Preserve binary logs for recovery needs: the workload assumption and operational owner are documented.
• Separate backup from replica topology: the workload assumption and operational owner are documented.
• Practice full restore: the workload assumption and operational owner are documented.
• Query/operation p95 and p99 are observable.
• Connection pools have explicit maximums and wait metrics.
• Backup restore has been tested recently.
• Replica/standby lag has an alert threshold.
• Schema/index migrations have a rollback or roll-forward plan.
• Sensitive values are excluded from logs and telemetry.

Related guides

• Start with the MySQL production architecture pillar
• MySQL Production Architecture: InnoDB, Transactions, Replication and Scaling
• MySQL Schema Design and Partitioning: Production Trade-offs

Closing perspective

For MySQL, my rule is to choose structures from the workload outward: access pattern, consistency, concurrency, failure behavior, recovery and only then the specific database feature. That approach produces systems that remain understandable when data volume, traffic and team size grow.