[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-08。"],[],[],null,["# Replication lag\n\n\u003cbr /\u003e\n\n[MySQL](/sql/docs/mysql/replication/replication-lag \"View this page for the MySQL database engine\") \\| PostgreSQL \\| [SQL Server](/sql/docs/sqlserver/replication/replication-lag \"View this page for the SQL Server database engine\")\n\n\u003cbr /\u003e\n\nThis page describes how to troubleshoot and fix replication lag for Cloud SQL\nread replicas.\n\nOverview\n--------\n\nCloud SQL read replicas use [PostgreSQL streaming replication](https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION). Changes are written to Write-Ahead Log (WAL) in the primary instance. The WAL sender sends the WAL to the WAL receiver in the replica, where they are applied.\n\nReplication lag can happen in a few scenarios, such as:\n\n- The primary instance can't send the changes fast enough to the replica.\n- The replica can't receive the changes quickly enough.\n- The replica can't apply the changes quickly enough.\n\nThe first two reasons above can be monitored with the `network_lag` metric. The third is observed via the `replica_lag` metric. High `replica_lag` means that the replica can't apply replication changes fast enough. The total lag can be observed via `replica_byte_lag` metric, which has labels to indicate further details. These metrics are described in the [Monitor replication lag](#metrics) section below.\n\nOptimize queries and schema\n---------------------------\n\nThis section suggests some common query and schema optimizations you can make to\nimprove replication performance.\n\n### Long-running queries in the read replica\n\nLong-running queries in the replica might block replication for Cloud SQL.\nYou might want to have separate replicas for online transaction processing\n(OLTP) and online analytical processing (OLAP) purposes and only send\nlong-running queries to the OLAP replica.\n\nConsider adjusting the `max_standby_archive_delay` and\n`max_standby_streaming_delay` flags for your replica.\n\nIf you suspect VACUUM is the culprit, and query cancellation is not acceptable,\nconsider setting the `hot_standby_feedback` flag in the replica.\n\nReview [PostgreSQL documentation](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT) for more information.\n\n### Exclusive locks due to DDL\n\nData definition language (DDL) commands, such as `ALTER TABLE` and\n`CREATE INDEX`, can cause replication lag in the replica due to\nexclusive locks. To avoid lock contention, consider scheduling DDL execution\nduring times when the query load is lower on the replicas.\nReview [PostgreSQL documentation](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT) for more information.\n\n### Overloaded replica\n\nIf a read replica is receiving too many queries, replication could be blocked.\nConsider splitting the reads among multiple replicas to reduce the load on each\none.\n\nTo avoid query spikes, consider throttling replica read queries in your\napplication logic or in a proxy layer if you use one.\n\nIf there are spikes of activity on the primary instance, consider spreading out\nupdates.\n\n### Monolithic primary database\n\nConsider sharding the primary database vertically (or horizontally) to prevent\none or more lagging tables from holding back all the other tables.\n\nMonitor replication lag\n-----------------------\n\nYou can use the `replica_lag` and `network_lag` metrics to monitor replication\nlag and identify whether the cause of the lag is in the primary database,\nthe network, or the replica.\n\nVerify replication\n------------------\n\nTo verify that replication is working, run the following statement against the replica:\n\n\u003cbr /\u003e\n\n select status, last_msg_receipt_time from pg_stat_wal_receiver;\n\nIf replication is happening, you see the status `streaming` and a recent\nlast_msg_receipt_time: \n\n postgres=\u003e select status, last_msg_receipt_time from pg_stat_wal_receiver;\n status | last_msg_receipt_time\n -----------+-------------------------------\n streaming | 2020-01-21 20:19:51.461535+00\n (1 row)\n\nIf replication is not happening, an empty result is returned: \n\n postgres=\u003e select status, last_msg_receipt_time from pg_stat_wal_receiver;\n status | last_msg_receipt_time\n --------+-----------------------\n (0 rows)\n\nWhat's next:\n------------\n\n- [Promote replicas for regional migration or disaster recovery](/sql/docs/postgres/replication/cross-region-replicas)"]]