이 페이지의 일부 또는 모든 정보는 S3NS의 Cloud de Confiance에 적용되지 않을 수 있습니다. 자세한 내용은 Google Cloud와의 차이점을 참조하세요.

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

복제 지연

MySQL | PostgreSQL | SQL Server

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

개요

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

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

기본 인스턴스가 변경사항을 복제본에 빠르게 전송할 수 없습니다.
복제본에서 변경사항을 빠르게 수신할 수 없습니다.
복제본에서 변경사항을 빠르게 적용할 수 없습니다.

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

복제본이 적절하게 프로비저닝되었는지 확인

기본 인스턴스보다 작은 복제본 인스턴스 (예: vCPU와 메모리가 적음)는 복제 지연이 발생할 수 있습니다. 더 작은 복제본은 더 큰 기본 인스턴스와 비교하여 기본 구성 플래그가 다를 수도 있습니다. 복제본 인스턴스가 복제 부하를 처리할 충분한 리소스를 갖도록 기본 인스턴스만큼 크거나 더 큰 것이 좋습니다.

복제본의 CPU 사용률이 높으면 복제 지연이 발생할 수도 있습니다. 복제본의 CPU 사용률이 높은 경우 (예: 90% 초과) 복제본의 CPU 용량을 늘리는 것이 좋습니다.

SHOW ALL 명령어를 사용하여 복제본 및 기본 인스턴스 구성을 확인하고 차이점을 비교할 수 있습니다.

쿼리 및 스키마 최적화

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

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

복제본에서 장기간 실행되는 쿼리는 Cloud SQL의 복제를 차단할 수 있습니다. 이는 복제본의 쿼리에서 읽고 있는 행에 복제가 변경사항 (예: VACUUM 작업)을 적용하려고 할 때 발생할 수 있습니다.

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

장기 실행 트랜잭션으로 인해 발생하는 복제 지연 또는 차단을 해결하려면 다음을 권장합니다.

대기 모드 지연 플래그 조정 max_standby_archive_delay 및 max_standby_streaming_delay 플래그는 복제와 충돌하는 대기 모드 쿼리를 취소하기 전에 복제본이 대기하는 시간을 제어합니다. 적절한 값은 보통 30~60초입니다. pg_stat_database_conflicts 뷰에서 쿼리 충돌에 관한 통계를 확인할 수 있습니다.
hot_standby_feedback 플래그를 사용 설정합니다. 복제본에서 hot_standby_feedback 플래그를 on로 설정하면 기본 인스턴스에서 진공 작업을 지연하는 데 도움이 될 수 있습니다. 하지만 이렇게 하면 기본 테이블이 비대해질 수 있으므로 절충안이 필요합니다.

자세한 내용은 PostgreSQL 문서를 참고하세요.

네트워크 지연 시간 높음

네트워크 지연이 높으면 WAL 레코드가 기본 인스턴스에서 전송되거나 복제본에서 수신되는 속도가 충분히 빠르지 않음을 나타냅니다. 이 문제는 다음과 같은 이유로 발생할 수 있습니다.

리전 간 복제 서로 다른 리전 간에 복제하면 네트워크 지연 시간이 길어질 수 있습니다.
기본 CPU 사용률이 높음 기본의 CPU가 90%를 초과하면 WAL 발신자 프로세스에 충분한 CPU 시간이 할당되지 않을 수 있습니다. 기본의 부하를 줄이거나 CPU를 늘리는 것이 좋습니다.
높은 복제본 CPU 사용률 복제본의 CPU가 90%를 초과하면 WAL 수신자 프로세스에 충분한 CPU 시간이 할당되지 않을 수 있습니다. 복제본의 부하를 줄이거나 CPU를 늘리는 것이 좋습니다.
네트워크 대역폭 문제 또는 디스크 I/O 병목 현상 더 가까운 리전이나 더 높은 처리량 디스크 구성이 도움이 될 수 있습니다. 크로스 리전 트래픽을 줄이기 위해 기본 인스턴스에서 wal_compression 플래그 값을 수정하는 것이 좋습니다.

cloudsql.googleapis.com/database/replication/network_lag 측정항목을 사용하여 네트워크 지연 시간을 모니터링할 수 있습니다. 실제 지연 시간이 더 길더라도 이 측정항목의 최대 한도는 25초입니다.

이 network_lag 측정항목은 replica_lag_type 라벨로 표시된 바이트 단위의 sent_location 지연 시간을 측정하는 cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag 측정항목과 유사합니다.

DDL로 인한 배타적 잠금

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

자세한 내용은 PostgreSQL 문서를 참고하세요.

과부하된 복제본

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

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

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

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

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

복제 지연 모니터링

replica_lag 및 network_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 수신자가 복제 변경사항을 충분히 빠르게 적용할 수 없음을 나타냅니다.

복제 지연
(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)

다음 단계:

리전 마이그레이션 또는 재해 복구용 복제본 승격