A read replica needs a freshness contract
A read replica can serve read workloads while changes are replicated from a primary. An application must decide which operations can tolerate delayed visibility. A dashboard showing a slightly older aggregate differs from a checkout confirming a newly written order; routing both blindly to the same replica can turn a capacity design into a correctness problem.
Google documents several causes and measurements for replication lag. Treat lag as a pipeline to investigate, including source write activity, transmission and application on the replica. A healthy network connection alone does not prove the replica has applied the changes needed by a particular user request.
Prepare read routing deliberately
- Identify business operations that need fresh primary data and those that can tolerate a documented delay. Keep this decision in application design rather than an undocumented connection-string convention.
- Size and monitor replica capacity for its replication work and read workload together. Record the owners of query changes, database configuration and routing.
- Rehearse write bursts, reporting queries and replica interruptions in isolation. Keep a safe fallback plan that considers the primary's capacity instead of automatically moving every read there.
For beginners, a replica is not a backup replacement. It can reflect unwanted changes as well as valid ones. Recovery history and replicated read capacity are different operational responsibilities.
Illustrative incident: a reporting query competes with replication
A new report increases work on the read replica during a busy write period. Users start seeing older status data from that replica. This is an illustrative scenario. Scaling application web workers can increase read pressure without helping the replica apply changes faster.
Compare business symptoms with database evidence
Record the primary write event and when the relevant result becomes visible through the replica. Review replica resource use, query activity and replication metrics over the same period. Distinguish delayed visibility from an application reading the wrong database or caching an older response.
| Observation | Evidence | Investigation |
|---|---|---|
| Lag grows with a write burst | Primary write pattern and replica progress | Replication capacity |
| Lag grows during a report | Query duration and replica resource use | Competing read work |
| Metrics recover but UI stays stale | Query endpoint and cache behavior | Application delivery |
| Primary reads become overloaded after fallback | Routing change and primary load | Recovery-plan capacity |
Avoid promoting or rebuilding a replica as an unexplained first step. Those actions can change the topology and recovery choices without addressing the workload that caused the symptom. Preserve the timeline and query identifiers needed for review.
Correct the demonstrated bottleneck and test freshness
For the illustrative report, review its query shape, timing and resource demand. Rehearse a targeted query or workload correction, then assess whether replica capacity still matches expected demand. Keep the routing decision separate from a schema or major database version change.
Verify the affected business operation with a controlled write followed by the intended read path. Observe both catch-up behavior and continued operation during a representative burst. If the application falls back to primary reads, test the bounded fallback under load and confirm it does not create a second incident.
Freshness objectives and operating SOP
Measure data freshness for the relevant operation, along with replication and request performance. An illustrative internal SLO might allow a reporting view a documented delay while requiring order confirmation to use an appropriate fresh path. These are business choices, not a provider SLA or a universal replica consistency promise.
The SOP should retain primary and replica identities, freshness requirement, query evidence, routing owner and reversal trigger. Escalate persistent lag before using stale results for critical decisions. Review read routing when new features are introduced, because a previously acceptable replica path may not meet a new workflow's freshness needs.
Clouvenix can scope related engineering support around a documented environment and agreed acceptance criteria.
Technical reference
Google Cloud: MySQL replication lag. Reviewed 19 October 2026; confirm resource-specific prerequisites and behavior for the deployed configuration.