이 페이지에서는 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 측정항목을 사용하여 복제 지연을 모니터링하고 지연 원인이 기본 데이터베이스, 네트워크 또는 복제본에 있는지 확인할 수 있습니다.
| 측정항목 | 설명 |
|---|---|
| 복제 지연 ( cloudsql.googleapis.com/database/replication/seconds_behind_master) |
복제본 상태가 기본 인스턴스 상태보다 지연되는 시간(초)입니다. 이는 보조 데이터베이스에서 마지막으로 다시 실행된 로그 레코드의 타임스탬프와 기본 데이터베이스에서 마지막으로 전송된 로그 레코드의 타임스탬프 간의 차이입니다. |
| 네트워크 지연 ( cloudsql.googleapis.com) |
복제본에서 마지막으로 수신된 로그 항목의 타임스탬프와 기본에서 마지막으로 전송된 로그 항목의 차이입니다. |
복제 확인
복제가 작동하는지 확인하려면 기본 인스턴스에서cloudsql.googleapis.com/database/replication/state 측정항목의 값을 확인합니다. 상태가 Running이면 복제가 정상적으로 진행되고 있는 것입니다.