# Amazon Aurora PostgreSQL를 사용한 복제
아래에서 Amazon Aurora PostgreSQL을 이용한 복제에 관한 정보를 확인할 수 있습니다. 논리적 복제를 모니터링하고 사용하는 방법에 관한 내용도 포함되어 있습니다.
**Topics**
+ [Aurora 복제본 사용](#AuroraPostgreSQL.Replication.Replicas)
+ [Aurora 복제본의 읽기 가용성 향상](#AuroraPostgreSQL.Replication.Replicas.SRO)
+ [Aurora PostgreSQL 복제 모니터링](#AuroraPostgreSQL.Replication.Monitoring)
+ [Aurora에서의 PostgreSQL 논리적 복제 개요](AuroraPostgreSQL.Replication.Logical.md)
+ [Aurora PostgreSQL DB 클러스터의 논리적 복제 설정](AuroraPostgreSQL.Replication.Logical.Configure.md)
+ [논리적 복제 비활성화](AuroraPostgreSQL.Replication.Logical.Stop.md)
+ [Aurora PostgreSQL 논리적 복제를 위한 라이트-스루 캐시 및 논리적 슬롯 모니터링](AuroraPostgreSQL.Replication.Logical-monitoring.md)
+ [예: Aurora PostgreSQL DB 클러스터에서 논리적 복제 사용](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)
+ [예: Aurora PostgreSQL 및 AWS Database Migration Service를 사용하는 논리적 복제](AuroraPostgreSQL.Replication.Logical.DMS-Example.md)
+ [논리적 복제 연결을 위한 IAM 인증 구성](AuroraPostgreSQL.Replication.Logical.IAM-auth.md)
## Aurora 복제본 사용
*Aurora복제본*Aurora은 DB 클러스터의 독립 엔드포인트로서, 읽기 작업을 조정하고 가용성을 높이는 데 사용하기에 가장 적합합니다. Aurora DB 클러스터는 Aurora DB 클러스터의 AWS 리전의 가용 영역 전체에서 최대 15개의 Aurora 복제본까지 포함할 수 있습니다.
DB 클러스터 볼륨은 DB 클러스터의 데이터 사본들로 구성됩니다. 하지만 DB 클러스터의 기본 라이터 DB 인스턴스 및 Aurora 복제본에는 클러스터 볼륨의 데이터가 단 하나의 논리 볼륨으로 표시됩니다. Aurora 복제본에 대한 자세한 내용은 [Aurora 복제본](Aurora.Replication.md#Aurora.Replication.Replicas) 단원을 참조하십시오.
Aurora 복제본은 클러스터 볼륨의 읽기 연산에 전적으로 사용되므로 읽기 조정에 유용합니다. 라이터 DB 인스턴스는 쓰기 작업을 관리합니다. 클러스터 볼륨은 Aurora PostgreSQL DB 클러스터에 있는 모든 인스턴스에 공유됩니다. 따라서 각 Aurora 복제본에 대해 데이터 사본을 복제하기 위해 추가 작업을 할 필요가 없습니다.
Aurora PostgreSQL에서 Aurora 복제본이 삭제되면 인스턴스 엔드포인트가 즉시 제거되고 Aurora 복제본이 리더 엔드포인트에서 제거됩니다. 삭제되는 Aurora 복제본을 실행하는 문이 있는 경우 3분의 유예 기간이 있습니다. 기존 문은 유예 기간 동안 정상적으로 완료할 수 있습니다. 유예 기간이 종료되면 Aurora 복제본이 종료 및 삭제됩니다.
Aurora PostgreSQL DB 클러스터는 Aurora Global Database를 사용하여 서로 다른 AWS 리전에서 Aurora 복제본을 지원합니다. 자세한 내용은 [Amazon Aurora Global Database 사용](aurora-global-database.md) 섹션을 참조하세요.
**참고**
읽기 가용성 기능을 사용할 때는 DB 클러스터의 Aurora 복제본을 재부팅해야 하는 경우 수동으로 재부팅해야 합니다. 이 기능 재부팅 전에 생성된 DB 클러스터의 경우 라이터 DB 인스턴스가 Aurora 복제본을 자동으로 재부팅합니다. 자동 재부팅을 통해 DB 클러스터 전반에 걸친 읽기/쓰기 일관성을 보장하는 진입점이 다시 구성됩니다.
## Aurora 복제본의 읽기 가용성 향상
Aurora PostgreSQL은 라이터 DB 인스턴스가 다시 시작되거나 Aurora 복제본이 쓰기 트래픽을 따라가지 못할 때 읽기 요청을 지속적으로 처리하여 DB 클러스터의 읽기 가용성을 향상시킵니다.
읽기 가용성 기능은 다음 버전의 Aurora PostgreSQL에서 기본적으로 사용할 수 있습니다.
+ 16.1 이상의 모든 버전
+ 15.2 이상의 15 버전
+ 14.7 이상의 14 버전
+ 13.10 이상의 13 버전
+ 12.14 이상의 12 버전
읽기 가용성 기능은 다음 버전의 Aurora Global Database에서 지원됩니다.
+ 16.1 이상의 모든 버전
+ 15.4 이상의 15 버전
+ 14.9 이상의 14 버전
+ 13.12 이상의 13 버전
+ 12.16 이상의 12 버전
이 출시 전에 이러한 버전 중 하나에서 생성된 DB 클러스터의 읽기 가용성 기능을 사용하려면 DB 클러스터의 라이터 인스턴스를 다시 시작하세요.
Aurora PostgreSQL DB 클러스터의 정적 파라미터를 수정하는 경우, 파라미터 변경 사항이 적용되도록 라이터 인스턴스를 다시 시작해야 합니다. 예를 들어 `shared_buffers` 값을 설정할 때 라이터 인스턴스를 다시 시작해야 합니다. Aurora 복제본의 읽기 가용성을 통해 DB 클러스터는 개선된 가용성을 유지하므로 라이터 인스턴스가 다시 시작할 때 영향이 줄어듭니다. 리더 인스턴스는 다시 시작되지 않고 읽기 요청에 계속 응답합니다. 정적 파라미터 변경 사항을 적용하려면 각 개별 리더 인스턴스를 재부팅합니다.
Aurora PostgreSQL DB 클러스터의 Aurora 복제본은 라이터와 다시 연결된 후 인 메모리 데이터베이스 상태로 빠르게 복구하여 라이터 다시 시작, 장애 조치, 느린 복제 및 네트워크 문제와 같은 복제 오류를 복구할 수 있습니다. 이 접근 방식을 통해 클라이언트 데이터베이스의 가용성을 유지하면서도 Aurora 복제본 인스턴스가 최신 스토리지 업데이트로 일관성을 달성할 수 있습니다.
복제 복구와 충돌하는 진행 중인 트랜잭션에서는 오류가 발생할 수 있지만, 리더가 라이터를 따라잡은 후에 클라이언트가 이러한 트랜잭션을 다시 시도할 수 있습니다.
### Aurora 복제본 모니터링
라이터 연결이 끊긴 상태에서 복구될 때 Aurora 복제본을 모니터링할 수 있습니다. 아래 지표를 사용하여 리더 인스턴스에 대한 최신 정보를 확인하고 처리 중인 읽기 전용 트랜잭션을 추적하세요.
+ 리더 인스턴스가 계속 연결되어 있는 동안 리더 인스턴스에 대한 최신 정보를 반환하도록 `aurora_replica_status` 기능이 업데이트되었습니다. `aurora_replica_status`에서 쿼리가 실행되는 DB 인스턴스에 해당하는 행의 마지막 업데이트 타임스탬프는 항상 비어 있습니다. 이는 리더 인스턴스에 최신 데이터가 있음을 나타냅니다.
+ Aurora 복제본이 라이터 인스턴스와의 연결을 끊었다가 다시 연결되면 다음 데이터베이스 이벤트가 발생합니다.
`Read replica has been disconnected from the writer instance and reconnected.`
+ 복구 충돌로 인해 읽기 전용 쿼리가 취소되면 데이터베이스 오류 로그에 다음과 같은 오류 메시지가 하나 이상 표시될 수 있습니다.
`Canceling statement due to conflict with recovery`.
`User query may not have access to page data to replica disconnect.`
`User query might have tried to access a file that no longer exists.`
`When the replica reconnects, you will be able to repeat your command.`
### 제한 사항
읽기 가용성 기능을 사용하는 Aurora 복제본에는 다음 제한 사항이 적용됩니다.
+ 복제 복구 중에 쓰기 인스턴스에서 데이터를 스트리밍할 수 없는 경우 보조 DB 클러스터의 Aurora 복제본이 다시 시작될 수 있습니다.
+ Aurora 복제본은 온라인 복제 복구가 이미 진행 중이고 다시 시작될 경우 온라인 복제 복구를 지원하지 않습니다.
+ Aurora 복제본은 DB 인스턴스가 트랜잭션 ID 랩어라운드에 가까워지면 다시 시작됩니다. 트랜잭션 ID 랩어라운드에 대한 자세한 내용은 [트랜잭션 ID 랩어라운드 실패 방지](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND )를 참조하세요.
+ 특정 상황에서 복제 프로세스가 차단되면 Aurora 복제본을 다시 시작할 수 있습니다.
## Aurora PostgreSQL 복제 모니터링
읽기 조정과 고가용성은 최소 지연 시간에 따라 달라집니다. Amazon CloudWatch `ReplicaLag` 지표를 모니터링하면 Aurora 복제본의 Aurora PostgreSQL DB 클러스터 라이터 DB 인스턴스 지연 시간을 모니터링할 수 있습니다. Aurora 복제본은 라이터 DB 인스턴스와 동일한 클러스터 볼륨에서 읽으므로 `ReplicaLag` 지표가 Aurora PostgreSQL DB 클러스터에서와는 다른 의미를 갖습니다. Aurora 복제본의 `ReplicaLag` 지표는 라이터 DB 인스턴스 대비 Aurora 복제본의 페이지 캐시 지연 시간을 나타냅니다.
RDS 인스턴스 및 CloudWatch 지표 모니터링에 대한 자세한 내용은 [Amazon Aurora 클러스터에서 지표 모니터링](MonitoringAurora.md) 단원을 참조하십시오.
# Aurora에서의 PostgreSQL 논리적 복제 개요
PostgreSQL의 논리적 복제 기능을 Aurora PostgreSQL DB 클러스터와 함께 사용하면 전체 데이터베이스 인스턴스가 아닌 개별 테이블을 복제하고 동기화할 수 있습니다. 논리적 복제에서는 게시 및 구독 모델을 사용하여 원본에서 한 명 이상의 수신자에게 변경 내용을 복제합니다. 이 작업은 PostgreSQL 미리 쓰기 로그(WAL)의 변경 레코드를 사용하여 작동합니다. 소스 또는 게시자는 지정된 테이블에 대한 WAL 데이터를 한 명 이상의 수신자(구독자)에게 전송하여 변경 사항을 복제하고 구독자의 테이블을 게시자의 테이블과 동기화된 상태로 유지합니다.**** 게시자의 변경 사항 집합은 게시를 사용하여 식별됩니다.** 구독자는 게시자의 데이터베이스 및 게시에 대한 연결을 정의하는 구독을 만들어 변경 사항을 적용합니다.** 복제 슬롯은 이 체계에서 구독 진행 상황을 추적하는 데 사용되는 메커니즘입니다.**
Aurora PostgreSQL DB 클러스터의 경우 WAL 레코드가 Aurora 스토리지에 저장됩니다. 논리적 복제 시나리오에서 게시자 역할을 하는 Aurora PostgreSQL DB 클러스터는 Aurora 스토리지에서 WAL 데이터를 읽고 디코딩하고 구독자에게 전송하여 변경 사항이 해당 인스턴스의 테이블에 적용될 수 있도록 합니다. 게시자는 논리적 디코더를 사용하여 구독자가 사용할 데이터를 디코딩합니다.** 기본적으로 Aurora PostgreSQL DB 클러스터는 데이터를 전송할 때 네이티브 PostgreSQL `pgoutput` 플러그인을 사용합니다. 다른 논리적 디코더도 사용할 수 있습니다. 예를 들어, Aurora PostgreSQL는 WAL 데이터를 JSON으로 변환하는 `[wal2json](https://github.com/eulerto/wal2json)` 플러그인도 지원합니다.
Aurora PostgreSQL 버전 14.5, 13.8, 12.12 및 11.17부터 Aurora PostgreSQL은 라이트-스루 캐시**를 통해 PostgreSQL 논리적 복제 프로세스를 보강하여 성능을 개선합니다. WAL 트랜잭션 로그는 버퍼에 로컬로 캐시되어 디스크 I/O의 양, 즉 논리적 디코딩 중에 Aurora 스토리지에서 읽는 양을 줄입니다. 기본적으로 라이트-스루 캐시는 Aurora PostgreSQL DB 클러스터에 대한 논리적 복제를 사용할 때마다 사용됩니다. Aurora는 캐시 관리에 사용할 수 있는 다양한 함수를 제공합니다. 자세한 내용은 [Aurora PostgreSQL 논리적 복제 라이트-스루 캐시 모니터링](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache) 섹션을 참조하세요.
논리적 복제는 현재 사용 가능한 모든 Aurora PostgreSQL 버전에서 지원됩니다. 자세한 정보는 Aurora PostgreSQL 릴리스 정보**에서 [Amazon Aurora PostgreSQL 업데이트 내용](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html)을 참조하세요.
Babelfish for Aurora PostgreSQL은 다음 버전에서 논리적 복제를 지원합니다.
+ 15.7 이상 버전
+ 16.3 이상 버전
**참고**
Aurora PostgreSQL은 PostgreSQL 10에 도입된 기본 PostgreSQL 논리적 복제 기능 외에 `pglogical` 확장도 지원합니다. 자세한 내용은 [pglogical을 사용하여 인스턴스 간 데이터 동기화](Appendix.PostgreSQL.CommonDBATasks.pglogical.md) 섹션을 참조하세요.
PostgreSQL 논리적 복제에 대한 자세한 내용은 PostgreSQL 설명서의 [Logical replication](https://www.postgresql.org/docs/current/logical-replication.html)(논리적 복제) 및 [Logical decoding concepts](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html)(논리적 디코딩 개념)을 참조하세요.
**참고**
PostgreSQL 16에는 읽기 전용 복제본의 논리적 디코딩에 대한 지원이 추가되었습니다. 이 기능은 Aurora PostgreSQL에서 지원되지 않습니다.
# Aurora PostgreSQL DB 클러스터의 논리적 복제 설정
논리적 복제를 설정하려면 `rds_superuser` 권한이 필요합니다. 다음 절차에 설명된 대로 필요한 파라미터를 설정하려면 사용자 지정 DB 클러스터 파라미터 그룹을 사용하도록 Aurora PostgreSQL DB 클러스터를 구성해야 합니다. 자세한 내용은 [Amazon Aurora DB 클러스터의 DB 클러스터 파라미터 그룹](USER_WorkingWithDBClusterParamGroups.md) 섹션을 참조하세요.
**Aurora PostgreSQL DB 클러스터에 논리적 복제를 설정하는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 Aurora PostgreSQL DB 클러스터를 선택합니다.
1. **구성** 탭을 엽니다. 인스턴스 세부 정보 중에서 **유형**이 **DB 클러스터 파라미터 그룹**인 **파라미터 그룹** 링크를 찾아보세요.
1. 링크를 선택하여 Aurora PostgreSQL DB 클러스터와 연결된 사용자 지정 파라미터를 엽니다.
1. **파라미터** 검색 필드에 `rds`를 입력하여 `rds.logical_replication` 파라미터를 찾습니다. 이 파라미터의 기본값은 `0`이며 기본적으로 꺼져 있음을 의미합니다.
1. **파라미터 편집**을 선택하여 속성 값에 액세스한 다음 선택기에서 기능을 켜도록 `1`을 선택합니다. 예상 사용량에 따라 다음 파라미터의 설정을 변경해야 할 수도 있습니다. 하지만 대부분의 경우 기본값이면 충분합니다.
+ `max_replication_slots` - 이 파라미터를 적어도 계획한 총 논리적 복제 게시 및 구독 수와 동일한 값으로 설정합니다. AWS DMS를 사용하는 경우 이 파라미터를 적어도 클러스터에서 계획한 변경 데이터 캡처 작업과 논리적 복제 게시 및 구독 수를 합친 값과 동일해야 합니다.
+ `max_wal_senders` 및 `max_logical_replication_workers` - 이 파라미터를 적어도 활성화하려는 논리적 복제 슬롯 수 또는 변경 데이터 캡쳐를 위한 활성 AWS DMS 작업의 수와 동일한 값으로 설정합니다. 논리적 복제 슬롯을 비활성 상태로 두면 vacuum이 테이블에서 사용되지 않는 튜플을 제거할 수 없으므로 복제 슬롯을 모니터링하고 필요에 따라 비활성 슬롯을 제거하는 것이 좋습니다.
+ `max_worker_processes` - 이 파라미터를 적어도 `max_logical_replication_workers`, `autovacuum_max_workers` 및 `max_parallel_workers` 값의 합계와 동일한 값으로 설정합니다. 소규모 DB 인스턴스 클래스에서는 백그라운드 작업자 프로세스 수가 애플리케이션 워크로드에 영향을 줄 수 있으므로 `max_worker_processes`를 기본값보다 높게 설정한 경우 데이터베이스 성능을 모니터링합니다. (기본값은 `GREATEST(${DBInstanceVCPU*2},8}`의 결과입니다. 즉, 기본적으로 DB 인스턴스 클래스에 해당하는 CPU의 2배 또는 8 중 더 큰 값입니다.)
**참고**
고객이 생성한 DB 파라미터 그룹의 파라미터 값은 수정할 수 있지만, 기본 DB 파라미터 그룹의 파라미터 값은 변경할 수 없습니다.
1. **변경 사항 저장**을 선택합니다.
1. Aurora PostgreSQL DB 클러스터의 라이터 인스턴스를 재부팅하여 변경 사항이 적용되도록 합니다. Amazon RDS 콘솔에서 클러스터의 기본 DB 인스턴스를 선택하고 **작업** 메뉴에서 **재부팅**을 선택합니다.
1. 인스턴스를 사용할 수 있게 되면 다음과 같이 논리적 복제가 활성화되어 있는지 확인할 수 있습니다.
1. `psql`을 사용하여 Aurora PostgreSQL DB 클러스터의 라이터 인스턴스에 연결합니다.
```
psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. 다음 명령을 사용하여 논리적 복제가 활성화되었는지 확인합니다.
```
labdb=> SHOW rds.logical_replication;
rds.logical_replication
-------------------------
on
(1 row)
```
1. `wal_level`이 `logical`로 설정되어 있는지 확인합니다.
```
labdb=> SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
논리적 복제를 사용하여 데이터베이스 테이블을 원본 Aurora PostgreSQL DB 클러스터의 변경 사항과 동기화된 상태로 유지하는 예는 [예: Aurora PostgreSQL DB 클러스터에서 논리적 복제 사용](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md) 섹션을 참조하세요.
# 논리적 복제 비활성화
복제 작업을 완료한 후에는 복제 프로세스를 중지하고 복제 슬롯을 삭제한 다음 논리적 복제를 비활성화해야 합니다. 슬롯을 삭제하기 전에 슬롯이 더 이상 필요가 없는지 확인합니다. 활성 복제 슬롯은 삭제할 수 없습니다.
**논리적 복제를 비활성화하는 방법**
1. 모든 복제 슬롯을 삭제합니다.
모든 복제 슬롯을 삭제하려면 게시자에 연결하고 다음 SQL 명령을 실행합니다.
```
SELECT pg_drop_replication_slot(slot_name)
FROM pg_replication_slots
WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);
```
이 명령을 실행할 때는 복제 슬롯을 활성화할 수 없습니다.
1. [Aurora PostgreSQL DB 클러스터의 논리적 복제 설정](AuroraPostgreSQL.Replication.Logical.Configure.md)에 설명된 대로 게시자와 연결된 사용자 지정 DB 클러스터 파라미터 그룹을 수정하되 `rds.logical_replication` 파라미터를 0으로 설정합니다.
사용자 지정 파라미터 그룹에 대한 자세한 내용은 [Amazon Aurora에서 DB 클러스터 파라미터 그룹의 파라미터 수정](USER_WorkingWithParamGroups.ModifyingCluster.md) 단원을 참조하세요.
1. `rds.logical_replication` 파라미터 변경 사항이 적용되도록 게시자 Aurora PostgreSQL DB 클러스터를 다시 시작합니다.
# Aurora PostgreSQL 논리적 복제를 위한 라이트-스루 캐시 및 논리적 슬롯 모니터링
논리적 복제 라이트-스루 캐시를 모니터링하고 논리적 슬롯을 관리하여 Aurora PostgreSQL DB 클러스터의 성능을 개선합니다. 아래에서 라이트-스루 캐시 및 논리적 슬롯에 대한 자세한 내용을 찾아보세요.
**Topics**
+ [Aurora PostgreSQL 논리적 복제 라이트-스루 캐시 모니터링](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [Aurora PostgreSQL 논리적 슬롯 관리](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## Aurora PostgreSQL 논리적 복제 라이트-스루 캐시 모니터링
기본적으로 Aurora PostgreSQL 버전 14.5, 13.8, 12.12 및 11.17 이상에서는 라이트-스루 캐시를 사용하여 논리적 복제의 성능을 개선합니다. 라이트-스루 캐시가 없으면 Aurora PostgreSQL은 기본 PostgreSQL 논리적 복제 프로세스를 구현할 때 Aurora 스토리지 계층을 사용합니다. 이를 위해 WAL 데이터를 스토리지에 쓴 다음 스토리지에서 데이터를 다시 읽어 디코딩하고 대상(가입자)에 전송(복제)합니다. 그 결과 Aurora PostgreSQL DB 클러스터의 논리적 복제 중에 병목 현상이 발생할 수 있습니다.
라이트-스루 캐시는 Aurora 스토리지 계층에 대한 의존도를 최소화합니다. Aurora PostgreSQL은 이 계층에 지속적으로 쓰고 읽는 대신 버퍼를 사용하여 복제 프로세스 중에 사용할 논리적 WAL 스트림을 캐싱하므로 디스크에 액세스할 필요가 줄어듭니다. 이 버퍼는 논리적 복제에서 사용하는 기본 PostgreSQL 캐시이며, Aurora PostgreSQL DB 클러스터 파라미터에서 `rds.logical_wal_cache`로 식별됩니다.
(라이트-스루 캐시를 지원하는 버전의) Aurora PostgreSQL DB 클러스터에서 논리적 복제를 사용하는 경우, 캐시 적중률을 모니터링하여 사용 사례에 맞게 작동하는지 확인할 수 있습니다. 이렇게 하려면 다음 예제와 같이 `psql`을 사용하여 Aurora PostgreSQL DB 클러스터의 쓰기 인스턴스에 연결한 다음 Aurora 함수(`aurora_stat_logical_wal_cache`)를 사용해야 합니다.
```
SELECT * FROM aurora_stat_logical_wal_cache();
```
이 함수는 다음과 같은 출력을 반환합니다.
```
name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39...
test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34...
(2 rows)
```
가독성을 위해 `last_reset_timestamp` 값을 줄였습니다. 이 함수에 대한 자세한 내용은 [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md) 단원을 참조하세요.
Aurora PostgreSQL는 라이트-스루 캐시를 모니터링하는 다음 두 가지 함수를 제공합니다.
+ `aurora_stat_logical_wal_cache` 함수 – 참조 설명서는 [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md)에서 확인할 수 있습니다.
+ `aurora_stat_reset_wal_cache` 함수 – 참조 설명서는 [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md)에서 확인할 수 있습니다.
자동으로 조정된 WAL 캐시 크기가 워크로드에 충분하지 않은 경우, `rds.logical_wal_cache` 값을 수동으로 변경할 수 있습니다. 다음을 고려하세요.
+ `rds.logical_replication` 파라미터가 비활성화되면 `rds.logical_wal_cache`가 0으로 설정됩니다.
+ `rds.logical_replication` 파라미터가 활성화되면 `rds.logical_wal_cache`의 기본값이 16MB입니다.
+ `rds.logical_wal_cache` 파라미터는 정적이므로 변경 사항을 적용하려면 데이터베이스 인스턴스 재부팅이 필요합니다. 이 파라미터는 8Kb 블록으로 정의됩니다. 32kB 미만의 모든 양수 값은 32kB로 처리됩니다. `wal_buffers`에 대한 자세한 내용은 PostgreSQL 설명서에서 [Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS)를 참조하세요.
## Aurora PostgreSQL 논리적 슬롯 관리
스트리밍 활동이 `pg_replication_origin_status` 보기에 캡처됩니다. 이 보기의 내용을 보려면 다음과 같이 `pg_show_replication_origin_status()` 함수를 사용하면 됩니다.
```
SELECT * FROM pg_show_replication_origin_status();
```
다음 SQL 쿼리를 사용하여 논리적 슬롯 목록을 가져올 수 있습니다.
```
SELECT * FROM pg_replication_slots;
```
논리적 슬롯을 삭제하려면 다음 명령에서처럼 `pg_drop_replication_slot`를 슬롯 이름과 함께 사용합니다.
```
SELECT pg_drop_replication_slot('test_slot');
```
# 예: Aurora PostgreSQL DB 클러스터에서 논리적 복제 사용
다음 절차는 두 Aurora PostgreSQL DB 클러스터 간에 논리적 복제를 시작하는 방법을 보여줍니다. 게시자와 구독자 모두 [Aurora PostgreSQL DB 클러스터의 논리적 복제 설정](AuroraPostgreSQL.Replication.Logical.Configure.md)에 설명된 대로 논리적 복제를 구성해야 합니다.
지정된 게시자인 Aurora PostgreSQL DB 클러스터도 복제 슬롯에 대한 액세스를 허용해야 합니다. 그러려면 Aurora PostgreSQL DB 클러스터의 Amazon VPC 서비스를 기반으로 Virtual Public Cloud(VPC)와 연결된 보안 그룹을 수정합니다. 구독자의 VPC와 연결된 보안 그룹을 게시자의 보안 그룹에 추가하여 인바운드 액세스를 허용합니다. 자세한 내용을 알아보려면 Amazon VPC 사용 설명서의 [보안 그룹을 사용하여 리소스에 대한 트래픽 제어](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)를 참조하세요.**
이러한 예비 단계가 완료되면 다음 절차에 설명된 대로 게시자에는 `CREATE PUBLICATION`, 구독자에는 `CREATE SUBSCRIPTION` PostgreSQL 명령을 사용할 수 있습니다.
**두 Aurora PostgreSQL DB 클러스터 간에 논리적 복제를 시작하는 방법**
이 단계에서는 Aurora PostgreSQL DB 클러스터에 예시 테이블을 생성할 데이터베이스가 있는 라이터 인스턴스가 있다고 가정합니다.
1. **게시자 Aurora PostgreSQL DB 클러스터에서**
1. 다음 SQL 문을 사용하여 테이블을 생성합니다.
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. 다음 SQL 문을 사용해 게시자 데이터베이스에 데이터를 삽입합니다.
```
INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
```
1. 다음 SQL 문을 사용하여 테이블에 데이터가 있는지 확인합니다.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. 다음과 같이 `CREATE PUBLICATION` 문을 사용하여 이 테이블에 대한 게시를 생성합니다.
```
CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
```
1. **구독자 Aurora PostgreSQL DB 클러스터에서**
1. 다음과 같이 게시자에서 생성한 것과 동일한 `LogicalReplicationTest` 테이블을 구독자에 생성합니다.
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. 이 테이블이 비어 있는지 확인합니다.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. 구독을 만들어 게시자로부터 변경 사항을 받습니다. 게시자 Aurora PostgreSQL DB 클러스터에 다음 세부 정보를 사용해야 합니다.
+ **host** - 게시자 Aurora PostgreSQL DB 클러스터의 라이터 DB 인스턴스입니다.
+ **포트** - 라이터 DB 인스턴스가 수신 대기하는 포트입니다. PostgreSQL의 기본값은 5432입니다.
+ **dbname** - 데이터베이스의 이름입니다.
```
CREATE SUBSCRIPTION testsub CONNECTION
'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password'
PUBLICATION testpub;
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 암호를 지정하는 것이 좋습니다.
구독이 생성된 후 논리적 복제 슬롯이 게시자 측에 생성됩니다.
1. 이 예시에서 초기 데이터가 구독자 측에서 복제된다는 것을 확인하려면 구독자 데이터베이스에서 다음 SQL 문을 사용하십시오.
```
SELECT count(*) FROM LogicalReplicationTest;
```
게시자에 대한 추가 변경 사항은 구독자에게로 복제됩니다.
논리적 복제는 성능에 영향을 미칩니다. 복제 작업이 완료된 후에는 논리적 복제를 해제하는 것이 좋습니다.
# 예: Aurora PostgreSQL 및 AWS Database Migration Service를 사용하는 논리적 복제
AWS Database Migration Service(AWS DMS)를 사용해 데이터베이스 또는 데이터베이스의 일부를 복제할 수 있습니다. AWS DMS를 사용해 데이터를 Aurora PostgreSQL 데이터베이스에서 다른 오픈 소스 또는 상용 데이터베이스로 마이그레이션합니다. AWS DMS에 대한 자세한 내용은 [AWS Database Migration Service 사용 설명서](https://docs.aws.amazon.com/dms/latest/userguide/)를 참조하십시오.
다음 예에서는 게시자인 Aurora PostgreSQL 데이터베이스에서 논리적 복제를 설정한 다음 마이그레이션을 위해 AWS DMS를 사용하는 방법을 보여줍니다. 이 예시에서는 [예: Aurora PostgreSQL DB 클러스터에서 논리적 복제 사용](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)에서 생성된 동일한 게시자 및 구독자를 사용합니다.
AWS DMS를 이용해 논리적 복제를 설정하려면 Amazon RDS에서 게시자 및 구독자에 대한 세부 정보를 얻어야 합니다. 특히 게시자의 라이터 DB 인스턴스와 구독자의 DB 인스턴스에 대한 세부 정보가 필요합니다.
게시자의 라이터 DB 인스턴스에 대해 다음 정보를 얻으십시오.
+ Virtual Private Cloud(VPC) 식별자
+ 서브넷 그룹
+ 가용 영역(AZ)
+ VPC 보안 그룹
+ DB 인스턴스 ID
구독자의 DB 인스턴스에 대해 다음 정보를 얻으십시오.
+ DB 인스턴스 ID
+ 소스 엔진
**Aurora PostgreSQL에서 논리적 복제를 위해 AWS DMS를 사용하려면**
1. AWS DMS 작업을 할 게시자 데이터베이스를 준비합니다.
이를 위해 PostgreSQL 10.x 이상 데이터베이스에서는 AWS DMS 래퍼 함수를 게시자 데이터베이스에 적용해야 합니다. 이와 관련된 사항과 후속 단계에 대한 자세한 내용은 *AWS Database Migration Service 사용 설명서*의 [PostgreSQL 버전 10.x 이상을 AWS DMS의 소스로 사용](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10)을 참조하세요.
1. AWS Management Console에 로그인한 다음 AWS DMS에서 [https://console.aws.amazon.com/dms/v2](https://console.aws.amazon.com/dms/v2) 콘솔을 엽니다. 상단 오른쪽에서 게시자와 구독자가 위치한 리전과 동일한 AWS 리전을 선택합니다.
1. AWS DMS 복제 인스턴스를 생성합니다.
게시자의 라이터 DB 인스턴스에 대한 값과 동일한 값을 선택합니다. 여기에는 다음 설정이 포함합니다.
+ **VPC**에서 라이터 DB 인스턴스의 VPC와 동일한 VPC를 선택합니다.
+ **복제 서브넷 그룹**에서 라이터 DB 인스턴스의 서브넷 그룹과 동일한 서브넷 그룹을 선택합니다. 필요한 경우 새 것을 만듭니다.
+ **가용 영역**에서 라이터 DB 인스턴스의 영역과 동일한 영역을 선택합니다.
+ **VPC 보안 그룹**에서 라이터 DB 인스턴스의 그룹과 동일한 그룹을 선택합니다.
1. 원본에 대해 AWS DMS 엔드포인트를 생성합니다.
다음 설정을 사용해 게시자를 원본 엔드포인트로 지정합니다.
+ **Endpoint type(엔드포인트 유형)**에서 **Source endpoint(원본 엔드포인트)**를 선택합니다.
+ **Select RDS DB Instance(RDS DB 인스턴스 선택)**을 선택합니다.
+ **RDS Instance(RDS 인스턴스)**에서 게시자의 라이터 DB 인스턴스의 DB 식별자를 선택합니다.
+ **소스 엔진**에서 **postgres**를 선택합니다.
1. 대상에 대해 AWS DMS 엔드포인트를 생성합니다.
다음 설정을 사용해 구독자를 대상 엔드포인트로 지정합니다.
+ **Endpoint type(엔드포인트 유형)**에서 **Target endpoint(대상 엔드포인트)**를 선택합니다.
+ **Select RDS DB Instance(RDS DB 인스턴스 선택)**을 선택합니다.
+ **RDS Instance(RDS 인스턴스)**에서 구독자 DB 인스턴스의 DB 식별자를 선택합니다.
+ **소스 엔진**의 값을 선택합니다. 예를 들어 구독자가 RDS PostgreSQL 데이터베이스인 경우 **postgres**를 선택합니다. 구독자가 Aurora PostgreSQL 데이터베이스인 경우 **aurora-postgresql**을 선택합니다.
1. AWS DMS 데이터베이스 마이그레이션 작업을 생성합니다.
데이터베이스 마이그레이션 작업을 사용하여 마이그레이션할 데이터베이스 테이블을 지정하고, 대상 스키마를 사용해 데이터를 매핑하고, 대상 데이터베이스에 새 테이블을 생성합니다. 최소한 **Task configuration(작업 구성)**에 대해 다음 설정을 사용하십시오.
+ **Replication instance(복제 인스턴스)**에서 이전 단계에서 생성한 복제 인스턴스를 선택합니다.
+ **Source database endpoint(원본 데이터베이스 엔드포인트)**에서 이전 단계에서 생성한 게시자 원본을 선택합니다.
+ **Target database endpoint(대상 데이터베이스 엔드포인트)**에서 이전 단계에서 생성한 구독자 대상을 선택합니다.
작업에 관한 나머지 세부 정보는 마이그레이션 프로젝트에 따라 다릅니다. DMS 태스크의 모든 세부 정보 지정에 대한 자세한 내용은 *AWS Database Migration Service 사용 설명서*에서 [AWS DMS 태스크 사용](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html)을 참조하세요.
작업이 생성되고 나면 AWS DMS에서 게시자에서 구독자로 데이터가 마이그레이션되기 시작합니다.
# 논리적 복제 연결을 위한 IAM 인증 구성
Aurora PostgreSQL 버전 11 이상부터 복제 연결에 AWS Identity and Access Management(IAM) 인증을 사용할 수 있습니다. 이 기능을 사용하면 암호 대신 IAM 역할을 사용하여 데이터베이스 액세스를 관리할 수 있으므로 보안이 강화됩니다. 클러스터 수준에서 작동하며, 표준 IAM 인증과 동일한 보안 모델을 따릅니다.
복제 연결을 위한 IAM 인증은 옵트인 기능입니다. 활성화하려면 DB 클러스터 파라미터 그룹의 `rds.iam_auth_for_replication` 파라미터를 `1`로 설정합니다. 동적 파라미터이므로 DB 클러스터를 다시 시작할 필요가 없으므로, 가동 중지 시간 없이 기존 워크로드에서 IAM 인증을 활용할 수 있습니다. 이 기능을 활성화하기 전에 아래 나열된 [사전 조건](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites)을 충족해야 합니다.
## 사전 조건
복제 연결에 IAM 인증을 사용하려면 다음 요구 사항을 모두 충족해야 합니다.
+ Aurora PostgreSQL DB 클러스터는 버전 11 이상이어야 합니다.
+ 게시자 Aurora PostgreSQL DB 클러스터에서 다음을 수행합니다.
+ IAM 데이터베이스 인증을 활성화합니다.
자세한 내용은 [IAM 데이터베이스 인증의 활성화 및 비활성화](UsingWithRDS.IAMDBAuth.Enabling.md) 섹션을 참조하세요.
+ `rds.logical_replication` 파라미터를 `1`로 설정하여 로컬 복제를 활성화합니다.
자세한 내용은 [Aurora PostgreSQL DB 클러스터의 논리적 복제 설정](AuroraPostgreSQL.Replication.Logical.Configure.md) 섹션을 참조하세요.
논리적 복제에서 게시자는 구독자 클러스터로 데이터를 전송하는 소스 Aurora PostgreSQL DB 클러스터입니다. 자세한 내용은 [Aurora의 PostgreSQL 논리적 복제 개요](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html)를 참조하세요.
**참고**
게시자 Aurora PostgreSQL DB 클러스터에서 IAM 인증과 논리적 복제를 모두 활성화해야 합니다. 둘 중 하나가 활성화되지 않은 경우 복제 연결에 IAM 인증을 사용할 수 없습니다.
## 복제 연결에 대한 IAM 인증 활성화
다음 단계를 완료하여 복제 연결에 대한 IAM 인증을 활성화합니다.
1. Aurora PostgreSQL DB 클러스터가 복제 연결을 통한 IAM 인증을 위한 모든 사전 조건을 충족하는지 확인합니다. 자세한 내용은 [사전 조건](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites)을 참조하세요.
1. DB 클러스터 `rds.iam_auth_for_replication` 파라미터 그룹을 수정하여 파라미터를 구성합니다.
+ `rds.iam_auth_for_replication` 파라미터를 `1`로 설정합니다. 이는 재부팅이 필요하지 않은 동적 파라미터입니다.
1. 데이터베이스에 연결하고 복제 사용자에게 필요한 역할을 부여합니다.
다음 SQL 명령은 복제 연결에 대한 IAM 인증을 활성화하는 데 필요한 역할을 부여합니다.
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
이 단계를 완료한 후, 지정된 사용자는 복제 연결에 IAM 인증을 사용해야 합니다.
**중요**
기능을 활성화할 때 `rds_iam` 및 `rds_replication` 역할이 모두 있는 사용자는 복제 연결에 IAM 인증을 사용해야 합니다. 이는 역할이 사용자에게 직접 할당되는지 아니면 다른 역할을 통해 상속되는지에 관계없이 적용됩니다.
## 복제 연결에 대한 IAM 인증 비활성화
다음 방법 중 하나를 사용하여 복제 연결에 대한 IAM 인증을 비활성화할 수 있습니다.
+ DB 클러스터 파라미터 그룹의 `rds.iam_auth_for_replication` 파라미터를 `0`으로 설정합니다.
+ 또는 Aurora PostgreSQL DB 클러스터에서 다음 기능 중 하나를 비활성화할 수 있습니다.
+ `rds.logical_replication` 파라미터를 `0`으로 설정하여 논리적 복제 비활성화
+ IAM 인증 비활성화
기능을 비활성화하면 복제 연결이 구성된 경우 인증에 데이터베이스 암호를 사용할 수 있습니다.
**참고**
`rds_iam` 역할이 없는 사용자의 복제 연결은 기능이 활성화된 경우에도 암호 인증을 사용할 수 있습니다.
## 제한 사항 및 고려 사항
복제 연결에 IAM 인증을 사용할 때는 다음과 같은 제한 및 고려 사항이 적용됩니다.
+ 복제 연결에 대한 IAM 인증은 Aurora PostgreSQL 버전 11 이상에서만 사용할 수 있습니다.
+ 게시자는 복제 연결에 대한 IAM 인증을 지원해야 합니다.
+ IAM 인증 토큰은 기본적으로 15분 후에 만료됩니다. 토큰이 만료되기 전에 장기 실행 복제 연결을 새로 고쳐야 할 수 있습니다.