Monitor replication lag by checking both how far data has progressed and whether replication workers are healthy. A time-based lag value alone cannot tell you whether a replica is waiting to receive changes, writing or flushing them, or applying them. Identify the database engine, replication mode, topology, and version first; then use that engine’s status views and error logs to locate the stalled stage before changing configuration.
What replication lag tells you—and what it does not
Replication moves database changes through distinct stages. Depending on the engine and replication mode, those stages may include sending changes, receiving them, writing them, flushing them to storage, and replaying or applying them. A replica can be behind because progress has stopped at one stage, because it cannot apply changes as quickly as they arrive, or because an intentional delay is configured.
Do not treat every lag metric as a prediction of catch-up time. For PostgreSQL physical streaming replication, the documented write_lag, flush_lag, and replay_lag values describe timing associated with recent WAL progress and notifications. They are not estimates of how long the standby will take to catch up. On an idle standby that has caught up, these fields can eventually become NULL. Decide explicitly whether a dashboard should display missing data, zero, or a last-known value in that situation.
Set alert thresholds according to the application’s tolerance for stale reads and its recovery objectives, then validate them under representative write load. There is no universal lag threshold established for all databases and workloads.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors#1 Best Overall
Start with the replication mode and topology
Before interpreting a number or status field, establish which replica and replication path it describes. Physical and logical replication do not expose interchangeable status views. A delayed replica may be behind by design, and a primary’s view may not show every downstream replica in a cascading topology.
- Engine and version: Status table names, fields, and command terminology can vary by version.
- Replication mode: Determine whether the system uses physical streaming, logical subscriptions, multithreaded apply, or a configured delay.
- Topology: Check whether the view reports directly connected replicas only or includes downstream nodes.
- Workload: Interpret lag alongside write activity. On a quiet primary, a time-only reading may not clearly show whether a replica is making progress.
Monitor PostgreSQL physical streaming replication
Check the primary’s WAL sender view
On the primary, inspect pg_stat_replication. It reports one row per WAL sender and covers directly connected standbys; it does not show downstream standbys in a cascading setup. Compare the WAL positions to see how far progress has reached:
Rank #2
| Field | What it indicates |
|---|---|
sent_lsn |
The WAL position sent by the primary. |
write_lsn |
The position written by the standby. |
flush_lsn |
The position flushed by the standby. |
replay_lsn |
The position replayed by the standby. |
write_lag, flush_lag, replay_lag |
Intervals associated with recent WAL progress and notifications, not predicted catch-up duration. |
Look for whether the position gaps are growing, stable, or closing while writes are occurring. The stage where progress first falls behind helps narrow where to investigate: sending and receipt, write, flush, or replay. This is a diagnostic interpretation of the reported positions, not an automatic diagnosis supplied by PostgreSQL.
Check receiver progress on the standby
On the standby, inspect pg_stat_wal_receiver for receiver progress. PostgreSQL’s documented default for wal_receiver_status_interval is 10 seconds, but a deployment can use a different setting; confirm the actual value and the documentation for the installed version. The reported apply position may also trail the true position slightly.
Interpret time fields with care
For asynchronous physical replication, replay_lag can approximate the delay before recent transactions become visible to standby queries. It still does not say how long a larger backlog will take to clear. When the standby is idle and caught up, lag time fields can become NULL after reflecting the last measured WAL location. Make the dashboard and alert behavior for that missing value deliberate, and correlate it with WAL-position movement and write activity.
Monitor PostgreSQL logical subscriptions
On the subscriber, inspect pg_stat_subscription. Its rows represent subscription workers. An enabled subscription normally has an apply worker; zero rows can indicate that a subscription is disabled or that its worker has crashed. More than one row is not automatically a fault: table synchronization and parallel transaction apply can add workers.
Rank #4
Use worker presence together with subscription state and synchronization activity. If the expected worker is missing or progress has stopped, inspect the relevant server logs and the subscription’s configuration and state. Physical-replication LSN checks are not a substitute for logical-subscription monitoring, and there is no single logical-lag query or repair action established here for every subscription.
Monitor MySQL replica appliers
For MySQL, use the Performance Schema replication tables supported by the installed version. The applier-status view can show whether applier threads are active or idle, whether a configured delayed replica is waiting out its intentional delay, and how many transaction retries have occurred. Worker and coordinator status provide thread-level details; worker error number, message, and timestamp can identify recent apply failures.
Best Value
- Used Book in Good Condition
On a multithreaded replica, inspect both coordinator and worker status. The coordinator schedules transactions while workers apply them, so looking at only one side can miss useful evidence. A worker’s most recent error is also represented in the replica’s error log. Consult the MySQL reference manual for the deployed version because table names, fields, and status-command terminology differ across versions.
Use status and errors to choose the next step
- Establish channel and applier health. Check whether the replication channel and applier threads are active, idle, or stopped.
- Inspect coordinator and worker details. Look for reported errors and repeated transaction retries.
- Separate intentional delay from backlog. Confirm whether the replica has a configured delay and whether its waiting state is expected.
- Read the error log and assess context. Use the exact error and surrounding log entries, along with workload and resource context, to identify the implicated condition.
- Make a targeted change. Change only the setting or condition supported by the evidence; do not restart workers or alter parallelism as a blind first response.
- Verify progress. Confirm that the receiver or applier is active and transaction progress resumes, then compare the lag trend with the application’s acceptable range.
Do not skip a transaction simply because it is blocking progress. The error and data-consistency implications must be understood first; skipping is not a general-purpose repair.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use Amazon RDS ReplicaLag in its service context
AWS describes the Amazon RDS ReplicaLag metric as the amount of time a read replica DB instance lags behind its source DB instance. Its applicability and behavior depend on the engine and configuration. Check the current RDS documentation for the specific engine and replica setup before building an alarm, including how the metric behaves during idle periods or failures. The metric description does not establish a universal alarm threshold.
Diagnose the symptom before changing settings
| Observed symptom | What to inspect next |
|---|---|
| Progress positions are not advancing | Check receiver or applier health, worker errors, and relevant server logs. |
| The gap is growing while writes continue | Use the engine’s stage-specific positions or worker state to determine where progress is falling behind. |
Lag time is NULL or appears stale |
Check whether the primary is idle, whether the replica is caught up, and how the metric reports missing or last-known values. |
| Workers report retries or an apply error | Read the exact error and corresponding log context before changing configuration or attempting recovery. |
| A replica is behind but has a configured delay | Distinguish the intended waiting period from an additional, unintentional backlog. |
| A primary’s status view omits an expected downstream node | Check the topology; PostgreSQL’s pg_stat_replication reports directly connected standbys only. |
Confirm that a fix worked
After addressing the condition implicated by the status and error evidence, confirm that the relevant receiver or applier is active and that reported positions or applied transactions are advancing. Watch the trend under actual write activity rather than relying on a single time-lag sample. Judge recovery against the application’s tolerance for stale reads and its recovery objectives; a falling lag value is useful only when it reflects progress in the replica path that matters to the application.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The checks above cover PostgreSQL physical and logical replication, MySQL applier diagnostics, and the Amazon RDS ReplicaLag metric. They should not be read as universal commands or remedies for other database engines, whose monitoring views and repair procedures require their own version-specific documentation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
