Amazon Relational Database Service
사용 설명서 (API 버전 2014-10-31)

PostgreSQL 읽기 전용 복제본 작업

일반적으로 읽기 전용 복제본을 사용하여 Amazon RDS DB 인스턴스 간 복제를 구성합니다. 읽기 전용 복제본에 대한 일반적인 정보는 MariaDB, MySQL 및 PostgreSQL DB 인스턴스의 읽기 전용 복제본 작업 단원을 참조하십시오.

이 단원에는 PostgreSQL의 읽기 전용 복제본 작업에 대한 자세한 정보가 포함되어 있습니다.

PostgreSQL을 사용한 읽기 전용 복제본 구성

Amazon RDS PostgreSQL은 버전 9.3.5 이상부터 PostgreSQL의 기본 스트리밍 복제 기능을 사용하여 원본(Postgres 용어로 "마스터") DB 인스턴스의 읽기 전용 복제본을 생성합니다. 이 읽기 전용 복제본(PostgreSQL 용어로 "스탠바이") DB 인스턴스는 마스터 DB 인스턴스에서 비동기식으로 생성된 물리적 복제본입니다. 생성 방법은 이렇습니다. 먼저 Write Ahead Log(WAL) 데이터를 전송할 수 있도록 원본 DB 인스턴스와 읽기 전용 복제본 사이에 특별한 연결 채널이 만들어집니다. 그런 다음 PostgreSQL이 그때그때 데이터베이스 변경 사항을 비동기식으로 스트리밍합니다.

PostgreSQL은 "복제" 역할을 사용하여 스트리밍 복제를 실행합니다. 이 역할은 권한이 부여되기는 하지만 그렇다고 데이터까지 수정하지는 못합니다. PostgreSQL은 단일 프로세스를 통해 복제를 처리합니다.

임의의 DB 인스턴스를 원본 DB 인스턴스로 사용하려면 백업 보존 기간을 0이 아닌 다른 값으로 설정하여 원본 DB 인스턴스의 자동 백업을 활성화해야 합니다.

PostgreSQL 읽기 전용 복제본을 생성할 때는 마스터 DB 인스턴스를 중단할 필요가 없습니다. Amazon RDS가 원본 DB 인스턴스와 읽기 전용 복제본에 필요한 파라미터와 권한을 설정하기 때문에 서비스 중단은 발생하지 않습니다. 원본 DB 인스턴스를 캡처한 스냅샷이 읽기 전용 복제본이 됩니다. 읽기 전용 복제본을 삭제하더라도 중단은 발생하지 않습니다.

원본 DB 인스턴스 하나에서 최대 5개까지 읽기 전용 복제본을 생성할 수 있습니다. 효과적인 복제를 위해서는 읽기 전용 복제본도 각각 원본 DB 인스턴스와 동일한 용량의 컴퓨팅 파워와 스토리지 리소스를 가져야 합니다. 원본 DB 인스턴스를 확장하면 읽기 전용 복제본도 확장해야 합니다.

Amazon RDS는 읽기 전용 복제본에서 파라미터가 호환되지 않아 읽기 전용 복제본을 시작하지 못할 경우에는 호환되지 않는 파라미터를 모두 무시합니다. 예를 들어 max_connections 파라미터 값이 읽기 전용 복제본보다 원본 DB 인스턴스에서 더 크다고 가정하겠습니다. 이 경우 가 원본 DB 인스턴스의 파라미터 값이 동일하도록 읽기 전용 복제본의 파라미터를 업데이트합니다.

반면 PostgreSQL DB 인스턴스는 원본과 읽기 전용 복제본 인스턴스 모두 ssl 파라미터를 1로 설정하여 암호화가 가능하도록 함으로써 안전하게 연결합니다.

읽기 전용 복제본은 단일 AZ 또는 다중 AZ DB 인스턴스 배포를 통해서도 생성할 수 있습니다. 다중 AZ 배포는 중요 데이터의 내구성과 가용성을 개선하는 데 효과적이지만 읽기 전용 쿼리를 실행하는 데 보조로 사용할 수는 없습니다. 그 대신 읽기 전용 쿼리 부하를 줄일 목적으로 트래픽이 많은 다중 AZ DB 인스턴스에서 읽기 전용 복제본을 생성할 수 있습니다. 다중 AZ 배포의 원본 인스턴스가 보조 인스턴스로 장애 조치된 경우에는 연결된 모든 읽기 전용 복제본이 자동으로 전환되어 보조(이제는 기본) 인스턴스를 복제 원본으로 사용합니다. 자세한 내용은 Amazon RDS를 위한 고가용성(다중 AZ) 단원을 참조하십시오.

읽기 전용 복제본을 Multi-AZ DB 인스턴스를 생성할 수 있습니다. Amazon RDS는 복제본에 대한 장애 조치 지원을 위해 다른 가용 영역에 복제본의 대기를 생성합니다. 읽기 전용 복제본을 다중 AZ DB 인스턴스로 생성하는 작업은 원본 데이터베이스가 다중 AZ DB 인스턴스인지 여부와는 독립적입니다.

postgres_fdw 확장을 사용하여 원격 서버에서 데이터로 액세스하려면 읽기 전용 복제본도 원격 서버로 액세스해야 합니다. postgres_fdw 사용에 관한 자세한 내용은 postgres_fdw 확장으로 외부 데이터 액세스 단원을 참조하십시오.

PostgreSQL 읽기 전용 복제본 모니터링

PostgreSQL 읽기 전용 복제본의 경우 Amazon RDS ReplicaLag 지표를 보면서 Amazon CloudWatch의 복제 지연을 모니터링할 수 있습니다. ReplicaLag 지표는 SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS slave_lag의 값을 보고합니다.

PostgreSQL을 사용한 읽기 전용 복제본 제한

PostgreSQL 읽기 전용 복제본에 대한 제한 사항은 다음과 같습니다.

  • 각 PostgreSQL 읽기 전용 복제본은 읽기 전용이라서 쓰기가 가능한 읽기 전용 복제본으로 만들 수 없습니다.

  • 다른 읽기 전용 복제본에서 읽기 전용 복제본을 생성할 수 없습니다(즉, Cascading 방식의 읽기 전용 복제본은 생성할 수 없습니다).

  • PostgreSQL 읽기 전용 복제본은 새로운 원본 DB 인스턴스로 승격할 수 없습니다. 하지만 읽기 전용 복제본은 자동으로 새로운 원본 DB 인스턴스가 되지 않습니다. 읽기 전용 복제본을 승격하면 WAL 통신을 수신하지 못하고 더 이상 읽기 전용 인스턴스의 역할을 하지 못합니다. 승격된 읽기 전용 복제본은 새로운 원본 DB 인스턴스와 다름없기 때문에 예정되어 있는 모든 복제를 그대로 진행하도록 준비해야 합니다.

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

PostgreSQL 읽기 전용 복제본을 통한 복제 중단

몇몇 상황에서는 PostgreSQL 원본 DB 인스턴스가 읽기 전용 복제본을 이용한 복제를 우발적으로 중단할 수 있습니다. 이러한 상황은 다음과 같습니다.

  • max_wal_senders 파라미터가 너무 낮게 설정되어 읽기 전용 복제본의 수에 충분한 데이터를 제공하지 못하는 경우 복제가 중단됩니다.

  • PostgreSQL 파라미터인 wal_keep_segments는 데이터를 읽기 전용 복제본으로 보낼 때 유지할 WAL 파일 수를 결정합니다. 이 파라미터 값에 따라 유지할 로그 수가 결정됩니다. 이 파라미터 값이 너무 낮으면 읽기 전용 복제본이 너무 멀리 뒤처지면서 스트리밍 복제가 중단될 수 있습니다. 이 경우에는 Amazon RDS가 복제 오류를 보고한 후 원본 DB 인스턴스에 보관된 WAL 로그를 재실행하여 읽기 전용 복제본의 복구를 시작합니다. 이 복구 프로세스는 읽기 전용 복제본이 스트리밍 복제를 이어갈 만큼 충분히 따라잡을 때까지 계속됩니다. 자세한 내용은 PostgreSQL 읽기 전용 복제본의 문제 해결 단원을 참조하십시오.

  • PostgreSQL 읽기 전용 복제본은 원본 DB 인스턴스 엔드포인트가 변경되면 재부팅해야 합니다.

읽기 전용 복제본에 데이터를 전송하는 WAL 스트림이 중단되면 PostgreSQL이 복구 모드로 전환되면서 보관 중인 WAL 파일을 사용해 읽기 전용 복제본을 복구합니다. 복구 프로세스가 완료되면 PostgreSQL이 스트리밍 복제를 다시 구성합니다.

PostgreSQL 읽기 전용 복제본의 문제 해결

PostgreSQL은 리전 간 복제에 복제 슬롯을 사용하기 때문에 동일한 리전의 복제 문제와 리전 간 복제 문제를 해결하는 방법도 다릅니다.

AWS 리전 내 PostgreSQL 읽기 전용 복제본의 문제 해결

PostgreSQL 파라미터인 wal_keep_segments는 데이터를 읽기 전용 복제본으로 보낼 때 유지할 Write Ahead Log(WAL) 파일 수를 결정합니다. 이 파라미터 값에 따라 유지할 로그 수가 결정됩니다. 이 파라미터 값이 너무 낮으면 읽기 전용 복제본이 너무 멀리 뒤처지면서 스트리밍 복제가 중단될 수 있습니다. 이 경우에는 Amazon RDS가 복제 오류를 보고한 후 원본 DB 인스턴스에 보관된 WAL 로그를 재실행하여 읽기 전용 복제본의 복구를 시작합니다. 이 복구 프로세스는 읽기 전용 복제본이 스트리밍 복제를 이어갈 만큼 충분히 따라잡을 때까지 계속됩니다.

Amazon RDS가 보관 중인 WAL 파일을 재실행하여 이러한 상태의 읽기 전용 복제본을 복구할 때는 읽기 전용 복제본의 PostgreSQL 로그가 표시됩니다.

2014-11-07 19:01:10 UTC::@:[23180]:DEBUG:  switched WAL source from archive to stream after failure 2014-11-07 19:01:10 UTC::@:[11575]:LOG:  started streaming WAL from primary at 1A/D3000000 on timeline 1 2014-11-07 19:01:10 UTC::@:[11575]:FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000001A000000D3 has already been removed 2014-11-07 19:01:10 UTC::@:[23180]:DEBUG:  could not restore file "00000002.history" from archive: return code 0 2014-11-07 19:01:15 UTC::@:[23180]:DEBUG:  switched WAL source from stream to archive after failure recovering 000000010000001A000000D3 2014-11-07 19:01:16 UTC::@:[23180]:LOG:  restored log file "000000010000001A000000D3" from archive

일정 시간이 지나면 Amazon RDS가 복제본에 보관된 WAL 파일을 재실행하여 충분히 따라잡은 후 읽기 전용 복제본이 스트리밍을 재개할 수 있습니다. 이때부터는 PostgreSQL이 스트리밍을 재개하고 다음과 비슷한 라인을 로그 파일에 기록합니다.

2014-11-07 19:41:36 UTC::@:[24714]:LOG:  started streaming WAL from primary at 1B/B6000000 on timeline 1

로그의 체크포인트 정보를 보면 유지해야 할 WAL 파일 수를 결정할 수 있습니다. PostgreSQL 로그는 각 체크포인트마다 다음과 같은 정보를 표시합니다. 아래 로그 문에서 "# recycled" 트랜잭션 로그 파일을 보면 일정 시간에 재사용되는 트랜잭션 파일 수를 확인 후 이 정보를 사용해 wal_keep_segments 파라미터를 설정할 수 있습니다.

2014-11-07 19:59:35 UTC::@:[26820]:LOG:  checkpoint complete: wrote 376 buffers (0.2%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s; sync files=10, longest=0.013 s, average=0.001 s

예를 들어 PostgreSQL 로그의 "checkpoint completed" 로그 문에서 5분 안에 재사용되는 파일 수가 35개라고 표시되어 있다고 가정하겠습니다. 이러한 사용 패턴에서는 읽기 전용 복제본이 5분간 이용하는 트랜잭션 파일 수는 35개입니다. 원본 DB 인스턴스의 wal_keep_segments 파라미터 값이 32로 기본 설정되어 있는 경우에는 읽기 전용 복제본이 비스트리밍 상태로 5분을 넘길 수 없습니다.

AWS 리전 간 PostgreSQL 읽기 전용 복제본의 문제 해결

PostgreSQL(버전 9.4.7 및 9.5.2에 한함)은 물리적인 복제 슬롯을 사용하여 원본 DB 인스턴스의 Write Ahead Log(WAL) 보존을 관리합니다. Amazon RDS가 리전 간 읽기 전용 복제본 인스턴스마다 물리적 복제 슬롯을 생성하여 연동시킵니다. 2개의 Amazon CloudWatch 지표인 Oldest Replication Slot LagTransaction Logs Disk Usage를 통해 수신되는 WAL 데이터와 관련하여 가장 지체된 복제본이 얼마나 오래되었는지, 그리고 현재 WAL 데이터에 얼마나 많은 스토리지가 사용되고 있는지 알 수 있습니다. Transaction Logs Disk Usage 값은 리전 간 읽기 전용 복제본이 많이 지체될 수록 크게 증가합니다.

DB 인스턴스의 워크로드에서 대용량의 WAL 데이터가 생성되는 경우에는 원본 DB 인스턴스와 읽기 전용 복제본의 DB 인스턴스 클래스를 변경해야 할 수 있습니다. 이 경우 복제본이 뒤처지지 않도록 High(10Gbps) 네트워크 성능의 클래스로 변경합니다. Amazon CloudWatch 지표인 Transaction Logs Generation을 보면 워크로드에서 발생하는 WAL 데이터 비율을 쉽게 이해할 수 있습니다.

리전 간 읽기 전용 복제본의 상태를 알고 싶으면 아래 예제와 같이 원본 인스턴스에 대한 pg_replication_slots를 쿼리를 실행하면 됩니다.

postgres=# select * from pg_replication_slots; slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn _______________________________________________________________________________________________________________________________________________ rds_us_east_1_db_uzwlholddgpblksce6hgw4nkte | | physical | | | t | 12598 | | | 4E/95000060 (1 row)