복제 지연

이 페이지에서는 Cloud SQL 읽기 복제본의 복제 지연 문제를 해결하는 방법을 설명합니다.

개요

Cloud SQL 읽기 복제본에서는 PostgreSQL 스트리밍 복제를 사용합니다. 변경사항은 기본 인스턴스의 미리 쓰기 로그(WAL)에 기록됩니다. WAL 발신자는 WAL을 WAL 수신자로 전송하며 이 경우 복제본에 적용합니다.

복제 지연은 다음과 같은 몇 가지 시나리오에서 발생할 수 있습니다.

  • 기본 인스턴스가 변경사항을 복제본에 빠르게 전송할 수 없습니다.
  • 복제본에서 변경사항을 빠르게 수신할 수 없습니다.
  • 복제본에서 변경사항을 빠르게 적용할 수 없습니다.
위의 처음 두 가지 이유는 network_lag 측정항목으로 모니터링될 수 있습니다. 세 번째는 replica_lag 측정항목을 통해 관찰됩니다. replica_lag가 높으면 복제본에서 복제 변경사항을 빠르게 적용할 수 없습니다. 총 지연은 추가 세부정보를 나타내는 라벨이 있는 replica_byte_lag 측정항목을 통해 관찰될 수 있습니다. 이러한 측정항목은 다음 복제 지연 모니터링 섹션에 설명되어 있습니다.

쿼리 및 스키마 최적화

이 섹션에서는 복제 성능을 개선할 수 있게 해주는 일반적인 쿼리와 스키마 최적화 몇 가지를 제안합니다.

읽기 복제본의 장기 실행 쿼리

복제본에서 장기간 실행되는 쿼리는 Cloud SQL의 복제를 차단할 수 있습니다. 온라인 트랜잭션 처리(OLTP)와 온라인 분석 처리(OLAP)용으로 별도의 복제본이 있고 장기 실행 쿼리만 OLAP 복제본에 전송할 수 있습니다.

복제본의 max_standby_archive_delaymax_standby_streaming_delay 플래그를 조정하는 것이 좋습니다.

의심스러운 VACUUM이 원인이며 쿼리 취소를 허용할 수 없는 경우 복제본에 hot_standby_feedback 플래그를 설정하는 것이 좋습니다.

자세한 내용은 PostgreSQL 상시 대기 문서를 참조하세요.

DDL로 인한 배타적 잠금

ALTER TABLECREATE INDEX와 같은 데이터 정의 언어(DDL) 명령어를 사용하면 배타적 잠금으로 인해 복제본에서 복제 지연이 발생할 수 있습니다. 잠금 경합을 방지하려면 복제본에서 쿼리 부하가 낮은 시간에 DDL 실행을 예약하는 것이 좋습니다.

자세한 내용은 PostgreSQL 상시 대기 문서를 참조하세요.

과부하된 복제본

읽기 복제본이 너무 많은 쿼리를 수신하면 복제가 차단될 수 있습니다. 여러 복제본 간에 읽기를 분할하여 각 복제본의 부하를 줄이는 것이 좋습니다.

쿼리 급증이 방지되도록 애플리케이션 로직이나 프록시 레이어 중 하나를 사용하는 경우 여기에서 복제본 읽기 쿼리를 제한하는 것이 좋습니다.

기본 인스턴스에서 활동이 급증하면 업데이트를 분산하는 것이 좋습니다.

모놀리식 기본 데이터베이스

지연 테이블 하나 이상이 다른 모든 테이블을 방해하지 않도록 기본 데이터베이스를 수직이나 수평으로 샤딩하는 것이 좋습니다.

복제 지연 모니터링

replica_lagnetwork_lag 측정항목을 사용하여 복제 지연을 모니터링하고 지연 원인이 기본 데이터베이스, 네트워크 또는 복제본에 있는지 확인할 수 있습니다.

측정항목설명
복제 지연
(cloudsql.googleapis.com/database/replication/replica_lag)

복제본 상태가 기본 인스턴스 상태보다 지연되는 시간(초)입니다. 이는 현재 시간과 현재 복제본에 적용 중인 트랜잭션을 커밋하는 기본 데이터베이스의 원래 타임스탬프 간의 차이입니다. 특히 복제본에서 쓰기를 수신했더라도 아직 데이터베이스에 적용되지 않았으면 쓰기가 지연된 것으로 간주될 수 있습니다.

이 측정항목은 복제본에서 now() - pg_last_xact_replay_timestamp()를 통해 계산됩니다. 이는 근사치입니다. 복제가 중단되면 복제본은 기본 데이터베이스가 얼마나 앞서 있는지 알 수 없으며 이 측정항목은 총 지연을 나타내지 않습니다.

지연 바이트
(cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)

복제본 상태가 기본 데이터베이스 상태보다 지연되는 바이트 양입니다. replica_byte_lag는 시계열 4개를 내보내고 replica_lag_type 라벨은 다음 중 하나를 나타낼 수 있습니다.

  • sent_location: 생성되었지만 아직 복제본에 전송되지 않은 WAL 바이트 수를 나타냅니다.
  • write_location: 쓰기에서 전송된 지연을 빼면 전송되었지만 아직 복제본에 기록되지 않은 네트워크의 WAL 바이트가 표시됩니다.
  • flush_location: 플러시에서 쓰기 지연을 빼면 복제본에 기록되었지만 아직 복제본에서 플러시되지 않은 WAL 바이트가 표시됩니다.
  • replay_location: 총 지연 시간을 표시합니다(바이트 단위). 재생에서 플러시 지연을 뺀 값이 재생 지연을 나타냅니다.
네트워크 지연
(cloudsql.googleapis.com/database/replication/network_lag)

기본 데이터베이스의 커밋에서 복제본의 WAL 수신자에 도달하는 데 걸리는 시간(초)입니다.

network_lag가 0이거나 무시할 수 있지만 replica_lag가 높으면 WAL 수신자가 복제 변경사항을 충분히 빠르게 적용할 수 없음을 나타냅니다.

복제 확인

복제본이 작동하는지 확인하려면 복제본에 다음 문을 실행합니다.

select status, last_msg_receipt_time from pg_stat_wal_receiver;

복제가 발생하면 streaming 상태와 최근 last_msg_Receipt_time이 표시됩니다.

postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
  status   |     last_msg_receipt_time
-----------+-------------------------------
 streaming | 2020-01-21 20:19:51.461535+00
(1 row)

복제가 수행되지 않으면 빈 결과가 반환됩니다.

postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
 status | last_msg_receipt_time
--------+-----------------------
(0 rows)