[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],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/docs/postgres/replication/replication-lag \"View this page for the PostgreSQL database engine\") \\| SQL Server\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 [SQL Server Always-On Availability Groups](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-linux-ver15) for replication. Changes are written to the transaction log in the primary instance. The primary instance forwards transactions to any secondary replica instances, where the changes are applied. The availability mode used is [Asynchronous-commit mode](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups?view=sql-server-ver16#SupportedAvModes).\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\nmetric`. The third reason is observed via the `seconds_behind_master` metric. A high `seconds_behind_master` metric means that the replica can't apply replication changes fast enough. 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\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.\nAdditionally, DDL statements such as `CREATE INDEX`, `ALTER INDEX`, and `INDEX\nMAINTENANCE` can cause replication lag due to the large number of transaction log records that these statements can generate.\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, check the value of the `cloudsql.googleapis.com/database/replication/state` metric on the primary instance. If the state is `Running`, then replication is healthy.\n\n\u003cbr /\u003e\n\nWhat's next:\n------------\n\n- [Promote replicas for regional migration or disaster recovery](/sql/docs/sqlserver/replication/cross-region-replicas)"]]
