RDS for PostgreSQL DB 인스턴스에 복제 지연 및 오류가 발생하는 이유는 무엇입니까?

7분 분량
0

Amazon Relational Database Service(RDS) for PostgreSQL 인스턴스에서 복제 오류 및 지연이 발생합니다.

간략한 설명

인스턴스에 읽기 전용 복제본을 추가하여 Amazon RDS for PostgreSQL에 대한 읽기를 조정할 수 있습니다. RDS for PostgreSQL은 PostgreSQL 네이티브 스트리밍 복제를 사용하여 원본 DB 인스턴스의 읽기 전용 복사본을 생성합니다. 이 읽기 전용 복제본 DB 인스턴스는 원본 DB 인스턴스의 비동기적으로 생성된 물리적 복제본입니다. 따라서 복제본에 기본 DB 인스턴스의 변경 사항이 반영되지 않는 경우가 있습니다. 그로 인해 복제 지연이 발생할 수 있습니다. 복제본 DB는 오리진 DB 인스턴스에서 읽기 전용 복제본으로 Write Ahead Log(WAL) 데이터를 전송하는 특수 연결로 생성합니다. 따라서 해당 읽기 전용 복제본은 WAL 로그를 검사하여 기본 인스턴스에서 수행된 변경 사항을 복제합니다. 읽기 전용 복제본이 기본 인스턴스에서 WAL을 찾을 수 없는 경우, Amazon Simple Storage Service(S3)에 보관한 WAL 데이터에서 읽기 전용 복제본이 복구됩니다. 자세한 내용은 여러 RDS for PostgreSQL 버전에서 스트리밍 복제가 작동하는 방식을 참조하십시오.

Amazon RDS ReplicaLag 지표를 보고 Amazon CloudWatch의 복제 지연을 모니터링 할 수 있습니다. 이 지표는 읽기 전용 복제본이 소스 DB 인스턴스보다 얼마나 뒤쳐졌는지를 보여줍니다. Amazon RDS는 읽기 전용 복제본의 복제 상태를 모니터링합니다. 그런 다음 어떤 이유로든 복제가 중지되면 Amazon RDS 콘솔의 복제 상태 필드를 Error로 업데이트합니다. ReplicaLag 지표는 읽기 전용 복제본이 원본 DB 인스턴스를 얼마나 잘 따라가는지를, 그리고 원본 DB 인스턴스와 특정 읽기 인스턴스 간의 지연 시간을 나타냅니다.

해결 방법

복제 지연이 증가할 때 RDS for PostgreSQL 오류 로그에 다음 오류 중 하나가 표시될 수 있습니다.

  • 스트리밍 복제가 중지됨: 기본 인스턴스와 복제본 인스턴스 간의 스트리밍 복제가 중단되면 이 오류가 발생합니다. 이 경우 Amazon S3의 아카이브 위치에서 복제가 재생되기 시작하므로, 복제본 지연 시간이 더 늘어납니다.
  • 스트리밍 복제가 종료됨: 수동으로 또는 복제 오류로 인해 연속 30일 이상 복제가 중지된 경우 이 오류가 발생합니다. 이 경우 Amazon RDS는 기본 DB 인스턴스와 모든 읽기 전용 복제본 간의 복제를 종료하여, 기본 인스턴스에 대한 스토리지 요구 사항이 증가하고 장애 조치 시간이 길어지는 것을 방지합니다.

읽기 전용 복제본 인스턴스는 복제가 종료된 후에도 사용할 수 있습니다. 그러나 읽기 전용 복제본에 필요한 트랜잭션 로그가 복제가 종료된 후 기본 인스턴스에서 삭제되므로 복제를 재개할 수 없습니다.

복제본 지연이 증가하는 가장 일반적인 이유는 다음과 같습니다.

  • 기본 및 읽기 전용 복제본의 구성 차이
  • 기본 인스턴스의 과중한 쓰기 워크로드
  • 오랜 시간 동안 실행 중인 트랜잭션
  • 기본 인스턴스 테이블에 대한 배타적 잠금
  • WAL 파일이 손상되었거나 누락됨
  • 네트워크 문제
  • 잘못된 파라미터 설정
  • 트랜잭션 없음

기본 인스턴스와 읽기 전용 복제본의 구성 차이

잘못된 복제본 인스턴스 구성은 복제 성능에 영향을 줄 수 있습니다. 읽기 전용 복제본은 추가 읽기 쿼리와 함께 원본 인스턴스와 유사한 쓰기 워크로드를 처리합니다. 따라서 원본 인스턴스와 동일하거나, 더 높은 인스턴스 클래스 및 스토리지 유형의 복제본을 사용합니다. 복제본은 원본 인스턴스와 동일한 쓰기 작업을 재생해야 하므로 하위 인스턴스 클래스 복제본을 사용하면 복제본에 대한 지연 시간이 길어지고 복제 지연이 증가할 수 있습니다. 스토리지 구성이 일치하지 않으면 복제 지연도 증가합니다.

기본 인스턴스의 과중한 쓰기 워크로드

기본 인스턴스의 쓰기 워크로드가 많으면 WAL 파일이 많이 유입될 수 있습니다. WAL 파일 수가 증가하고, 이러한 파일을 읽기 전용 복제본에서 재생하면 전반적인 복제 성능이 저하될 수 있습니다. 따라서 복제본 지연 시간이 증가할 경우 기본 인스턴스의 쓰기 작업을 확인해야 합니다. CloudWatch 지표 또는 향상된 모니터링을 사용하여 이 워크로드를 분석할 수 있습니다. TransactionLogsDiskUsage, TransactionLogsGeneration, WriteIOPS, WriteThroughput, 및 WriteLatency에 대한 값을 확인하여 소스 인스턴스가 과중한 쓰기 워크로드 하에 있는지 확인하십시오. 처리량 수준에서 병목 현상을 확인할 수도 있습니다. 각 인스턴스 유형에는 전용 처리량이 있습니다. 자세한 내용은 DB 인스턴스 클래스의 하드웨어 사양을 확인하십시오.

이 문제를 방지하려면 원본 인스턴스에 대한 쓰기 작업을 제어 및 배포하십시오. 여러 쓰기 작업을 함께 수행하는 대신 작업을 더 작은 작업 번들로 분할한 다음, 이러한 번들을 여러 트랜잭션에 균등하게 분배하십시오. WritelatencyWriteIOPS 등의 지표에 CloudWatch 알림을 사용해 소스 인스턴스에 과중한 쓰기가 발생할 경우 알림을 받을 수 있습니다.

오랜 시간 동안 실행 중인 트랜잭션

데이터베이스에서 장시간 실행 중인 활성 트랜잭션은 WAL 복제 프로세스를 방해하여 복제 지연을 증가시킬 수 있습니다. 따라서 PostgreSQL pg_stat_activity 뷰를 사용하여 활성 트랜잭션의 런타임을 모니터링해야 합니다.

기본 인스턴스에서 다음과 유사한 쿼리를 실행하여 장시간 실행되는 쿼리의 프로세스 ID(PID)를 찾습니다.

SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';

쿼리의 PID를 식별한 후 쿼리를 종료하도록 선택할 수 있습니다.

기본 인스턴스에서 다음과 유사한 쿼리를 실행하여 쿼리를 종료합니다.

SELECT pg_terminate_backend(PID);

또한, 장시간 실행되는 트랜잭션을 방지하도록 쿼리를 다시 작성하거나 조정할 수도 있습니다.

기본 인스턴스 테이블에 대한 배타적 잠금

기본 인스턴스에서 드롭 테이블, 자르기, 재인덱스, 진공 전체, 구체화된 뷰 새로 고침(동시에 사용하지 않음) 과 같은 명령을 실행하면 PostgreSQL은 액세스 배타 잠금을 처리합니다. 이 잠금은 잠금 보류 기간 동안 다른 모든 트랜잭션이 테이블에 액세스하지 못하도록 합니다. 일반적으로 테이블은 트랜잭션이 끝날 때까지 잠긴 상태로 유지됩니다. 이 잠금 활동은 WAL에 기록된 다음, 읽기 전용 복제본에 의해 다시 재생 및 보류됩니다. 테이블이 Access Exclusive 잠금으로 유지되는 시간이 길어질 수록 복제 지연이 길어집니다.

이 문제를 방지하려면 pg_lockspg_stat_activity 카탈로그 테이블을 주기적으로 쿼리하여, 트랜잭션을 모니터링하는 것이 가장 좋습니다.

예:

SELECT pid, usename, pg_blocking_pids(pid) AS blocked_by, QUERY AS blocked_query<br>FROM pg_stat_activity<br>WHERE cardinality(pg_blocking_pids(pid)) > 0;

WAL 파일이 손상되었거나 누락됨

WAL 파일이 손상되거나 누락되면 복제 지연이 발생할 수 있습니다. 이 경우 PostgreSQL 로그에 WAL을 열 수 없다는 오류가 표시됩니다. 또한 “요청된 WAL 세그먼트 XXX가 이미 제거되었습니다.” 오류가 표시될 수 있습니다.

네트워크 문제

기본 인스턴스와 복제본 인스턴스 간의 네트워크 중단으로 인해 스트리밍 복제에 문제가 발생하여 복제본 지연이 증가할 수 있습니다.

잘못된 파라미터 설정

서버 구성 파라미터 그룹 내 일부 사용자 지정 파라미터를 잘못 설정하면 복제 지연이 증가할 수 있습니다. 다음은 올바르게 설정해야 하는 몇 가지 파라미터입니다.

  • wal_keep_segments: 이 파라미터는 기본 인스턴스가 pg_wal 디렉터리에 보관하는 WAL 파일의 수를 지정합니다. 이 파라미터의 기본값은 32로 설정됩니다. 이 파라미터가 배포하기에 충분히 높은 값으로 설정되지 않은 경우, 읽기 전용 복제본이 지연되어 스트리밍 복제가 중지될 수 있습니다. 이 경우 RDS는 복제 오류를 생성하고, S3에서 기본 인스턴스의 아카이브된 WAL 데이터를 재생하여, 읽기 전용 복제본에 대한 복구를 시작합니다. 이 복구 프로세스는 읽기 전용 복제본이 스트리밍 복제를 계속할 수 있을 때까지 계속됩니다.
    참고: PostgreSQL 버전 13에서 wal_keep_segments 파라미터는 wal_keep_size로 명명합니다. 이 파라미터는 wal_keep_segments와 동일한 용도로 사용합니다. 그러나 이 파라미터의 기본값은 파일의 수가 아닌 MB(2048MB)로 정의합니다.
  • max_wal_senders: 이 파라미터는 스트리밍 복제 프로토콜을 통해 기본 인스턴스가 동시에 지원할 수 있는 최대 연결 수를 지정합니다. RDS for PostgreSQL 13 이상에 대한 이 파라미터의 기본값은 20입니다. 이 파라미터는 실제 읽기 전용 복제본 수보다 약간 높은 값으로 설정해야 합니다. 이 파라미터를 읽기 전용 복제본의 수보다 작은 값으로 설정하면 복제가 중지됩니다.
  • hot_standby_feedback: 이 파라미터는 복제본 인스턴스가 복제본 인스턴스에서 현재 실행 중인 쿼리에 대한 피드백을 기본 인스턴스로 보낼지 여부를 지정합니다. 이 파라미터를 설정하면, 복제본 인스턴스의 읽기 쿼리가 완료되지 않는 한 원본 인스턴스에서 다음 오류 메시지를 큐레이팅하고, 관련 테이블에서 VACUUM 작업을 연기합니다. 따라서 hot_standby_feedback이 켜져 있는 복제본 인스턴스는 장기 실행 쿼리를 제공할 수 있습니다. 하지만 이 파라미터는 원본 인스턴스에서 테이블을 부풀릴 수 있습니다. 기본 인스턴스의 스토리지 부족 및 트랜잭션 ID 랩어라운드와 같은 심각한 문제를 방지하려면 복제본 인스턴스에서 장기 실행 쿼리를 모니터링해야 합니다.
ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed
  • max_standby_streaming_delay/max_standby_archive_delay: 장기 실행 읽기 쿼리를 완료하기 위해 복제본 인스턴스에서 max_standby_archive_delay 또는 max_standby_streaming_delay 와 같은 파라미터를 활성화할 수 있습니다. 이러한 파라미터는 복제본에서 읽기 쿼리가 실행 중일 때 소스 데이터가 수정되면, 복제본에서 WAL 재생을 일시 중지합니다. 이러한 파라미터의 값이 -1이면, WAL 리플레이가 읽기 쿼리가 완료될 때까지 대기할 수 있습니다. 그러나 이러한 일시 중지는 복제 지연을 무기한으로 증가시키고, WAL 누적으로 인해 소스에서 높은 스토리지 소비를 유발합니다.

트랜잭션 없음

원본 DB 인스턴스에서 사용자 트랜잭션이 발생하지 않는 경우 PostgreSQL 읽기 전용 복제본은 최대 5분의 복제 지연을 보고합니다.


관련 정보

Amazon RDS for PostgreSQL용 읽기 전용 복제본 사용

서버 구성을 위한 PostgreSQL 설명서