이 페이지에서는 Cloud SQL 읽기 복제본의 복제 지연 문제를 해결하는 방법을 설명합니다.
개요
Cloud SQL 읽기 복제본은 복제에 SQL Server Always-On 가용성 그룹을 사용합니다. 변경사항은 기본 인스턴스의 트랜잭션 로그에 기록됩니다. 기본 인스턴스는 변경 사항이 적용되는 모든 보조 복제본 인스턴스에 트랜잭션을 전달합니다. 사용되는 가용성 모드는 비동기 커밋 모드입니다.
복제 지연은 다음과 같은 몇 가지 시나리오에서 발생할 수 있습니다.
기본 인스턴스가 변경사항을 복제본에 빠르게 전송할 수 없습니다.
복제본에서 변경사항을 빠르게 수신할 수 없습니다.
복제본에서 변경사항을 빠르게 적용할 수 없습니다.
위의 처음 두 가지 이유는 network_lag
metric으로 모니터링할 수 있습니다. 세 번째 이유는 seconds_behind_master 측정항목을 통해 관찰됩니다. seconds_behind_master 측정항목이 높으면 복제본이 복제 변경사항을 빠르게 적용할 수 없습니다. 이러한 측정항목은 다음 복제 지연 모니터링 섹션에 설명되어 있습니다.
쿼리 및 스키마 최적화
이 섹션에서는 복제 성능을 개선할 수 있게 해주는 일반적인 쿼리와 스키마 최적화 몇 가지를 제안합니다.
읽기 복제본의 장기 실행 쿼리
복제본에서 장기간 실행되는 쿼리는 Cloud SQL의 복제를 차단할 수 있습니다.
온라인 트랜잭션 처리(OLTP)와 온라인 분석 처리(OLAP)용으로 별도의 복제본이 있고 장기 실행 쿼리만 OLAP 복제본에 전송할 수 있습니다.
DDL로 인한 배타적 잠금
ALTER TABLE 및 CREATE INDEX와 같은 데이터 정의 언어(DDL) 명령어를 사용하면 배타적 잠금으로 인해 복제본에서 복제 지연이 발생할 수 있습니다. 잠금 경합을 방지하려면 복제본에서 쿼리 부하가 낮은 시간에 DDL 실행을 예약하는 것이 좋습니다.
또한 CREATE INDEX, ALTER INDEX, INDEX
MAINTENANCE 같은 DDL 문은 이러한 문으로 생성될 수 있는 많은 트랜잭션 로그 레코드로 인해 복제 지연이 발생할 수 있습니다.
과부하된 복제본
읽기 복제본이 너무 많은 쿼리를 수신하면 복제가 차단될 수 있습니다.
여러 복제본 간에 읽기를 분할하여 각 복제본의 부하를 줄이는 것이 좋습니다.
쿼리 급증이 방지되도록 애플리케이션 로직이나 프록시 레이어 중 하나를 사용하는 경우 여기에서 복제본 읽기 쿼리를 제한하는 것이 좋습니다.
기본 인스턴스에서 활동이 급증하면 업데이트를 분산하는 것이 좋습니다.
모놀리식 기본 데이터베이스
지연 테이블 하나 이상이 다른 모든 테이블을 방해하지 않도록 기본 데이터베이스를 수직이나 수평으로 샤딩하는 것이 좋습니다.
복제 지연 모니터링
replica_lag 및 network_lag 측정항목을 사용하여 복제 지연을 모니터링하고 지연 원인이 기본 데이터베이스, 네트워크 또는 복제본에 있는지 확인할 수 있습니다.
[[["이해하기 쉬움","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-08-13(UTC)"],[],[],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)"]]
