Aurora PostgreSQL 호환 소스 DB 클러스터의 논리적 복제 문제를 해결하려면 어떻게 해야 합니까?

5분 분량

Amazon Aurora PostgreSQL 호환 버전 소스 데이터베이스(DB) 클러스터의 논리적 복제 문제를 해결하고 싶습니다.

해결 방법

복제 파라미터 구성

논리적 복제 문제를 해결하기 전에 DB 클러스터 파라미터 그룹에 대해 다음 파라미터를 구성하십시오.

rds.logical_replication 값을 1로 설정하여 DB 클러스터에서 논리적 복제를 활성화합니다.
max_replication_slots에 예상 구독 수와 추가 테이블 동기화 프로세스를 위한 충분한 슬롯이 포함된 값을 설정합니다.
max_wal_senders를 max_replication_slots 할당량과 현재 물리적 복제본을 지원하는 값으로 설정합니다.
max_logical_replication_workers를 복제 시스템에서 테이블 동기화에 필요한 추가 작업자 수와 구독 수를 지원하는 값으로 설정합니다.
max_worker_processes를 max_logical_replication_workers 값보다 하나 이상 큰 값으로 설정합니다. 예를 들어 max_logical_replication_workers가 25인 경우 max_worker_processes를 26으로 설정합니다.
데이터 복사가 느린 경우 구독 설정 및 새 테이블 추가를 처리하는 동기화 작업자 수를 제어하는 max_sync_workers_per_subscription 값을 늘리십시오.

중요: 위의 변경 사항을 적용하려면 Aurora PostgreSQL 호환 DB 클러스터를 재부팅해야 합니다.

게시 및 구독 구성 확인

논리적 복제 파라미터를 구성한 후 게시 및 구독을 올바르게 구성했는지 확인하십시오. 게시에 의도한 모든 테이블이 포함되어 있고 구독 파라미터가 정확하며 복제 사용자에게 적절한 권한이 있는지 확인하십시오.

소스 데이터베이스에 연결한 후 다음 명령을 실행합니다.

게시 구성을 확인하려면 다음 명령을 실행합니다.

SELECT * FROM pg_publication;
SELECT * FROM pg_publication_tables;

구독 구성을 확인하려면 다음 명령을 실행합니다.

SELECT * FROM pg_subscription;
SELECT * FROM pg_subscription_rel;

복제 슬롯이 활성 상태인지 확인

소스 데이터베이스에 연결한 후 다음 명령을 실행합니다.

SELECT slot_name, plugin, slot_type, active, restart_lsn,
       confirmed_flush_lsn, pg_current_wal_lsn(),
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots;

슬롯이 비활성 상태이거나 지연이 너무 심하면 복제 작업자를 검토하여 문제를 해결하십시오.

복제 작업자가 활성 상태인지 확인

대상 데이터베이스에 연결한 후 다음 명령을 실행합니다.

SELECT pid, state, query, wait_event, backend_type
FROM pg_stat_activity
WHERE backend_type LIKE 'logical replication%';

복제 작업자가 없는 경우 구독을 다시 시작합니다.

구독을 끄려면 다음 명령을 실행합니다.

ALTER SUBSCRIPTION subscription_name DISABLE;

구독을 켜려면 다음 명령을 실행합니다.

ALTER SUBSCRIPTION subscription_name ENABLE;

구독을 다시 시작한 후에도 여전히 복제 작업자가 없는 경우 PostgreSQL 오류 로그에서 오류 메시지를 확인하십시오.

복제 진행 상황 및 지연 모니터링

게시 트랜잭션 양과 개수가 많아서 복제가 지연될 수 있습니다. 또는 게시 또는 구독에 제약이 있을 수 있습니다.

복제가 중지되었는지 또는 느린지 확인하려면 몇 시간 간격으로 복제 진행 상황을 모니터링하십시오.

DB 클러스터에 연결한 후 다음 명령을 실행합니다.

게시의 복제 진행 상황을 확인하려면 다음 명령을 실행합니다.

SELECT slot_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag,
       active
FROM pg_replication_slots
WHERE slot_type = 'logical';

구독의 복제 진행 상황을 확인하려면 다음 명령을 실행합니다.

SELECT subname, pid, received_lsn, latest_end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(latest_end_lsn, received_lsn)) AS lag
FROM pg_stat_subscription;

복제 지연을 최소화하려면 write-through 캐시를 모니터링합니다. 캐시 크기가 워크로드에 충분하지 않은 경우 rds.logical_wal_cache 값을 수동으로 변경할 수 있습니다. 자세한 내용은 Aurora PostgreSQL의 새로운 write-through 캐시를 사용하여 복제 지연을 최대 17배 낮추기를 참조하십시오.

리소스 제약 모니터링

게시자와 구독자의 리소스 제약 문제를 해결하려면 향상된 모니터링을 켜고 CPUUtilization, FreeableMemory, SwapUsage 및 NetworkThroughput을 모니터링하십시오. 복제 문제가 발생하면 알림을 받도록 Amazon CloudWatch 경보를 설정합니다.

자세한 내용은 Amazon RDS for PostgreSQL 또는 Aurora PostgreSQL 호환 DB 인스턴스에서 성능 문제 및 실행 속도가 느린 쿼리를 파악하고 문제를 해결하려면 어떻게 해야 합니까?를 참조하십시오.

스키마 불일치 식별 및 데이터 불일치 해결

소스 데이터베이스 및 대상 데이터베이스에 연결합니다. 그런 다음 복제된 테이블에 열이 있고 데이터 유형이 호환되는지 확인합니다. 또한 기본 키와 고유 제약이 일치하는지 확인합니다.

구독을 켜려면 다음 명령을 실행합니다.

ALTER SUBSCRIPTION subscription_name ENABLE;

테이블 정의를 비교하려면 두 데이터베이스에서 다음 명령을 실행합니다.

SELECT column_name, data_type, character_maximum_length
FROM information_schema.columns
WHERE table_name = 'your_table_name'
ORDER BY ordinal_position;

참고: your_table_name을 테이블 이름으로 바꾸십시오.

충돌 해결

기본 PostgreSQL 논리적 복제는 여러 게시자의 데이터 충돌 또는 로컬에서 변경한 데이터와 충돌하는 복제된 수정 사항을 감지할 수 없습니다. 동일한 키를 가진 현재 행이 있는 경우 Aurora가 업데이트를 적용하고 삽입이 실패합니다.

충돌의 원인을 파악하려면 PostgreSQL 로그를 확인하십시오.

다음 예제 로그는 대상 데이터베이스에 이미 존재하는 자산 ID로 레코드를 삽입하려고 했기 때문에 복제가 실패했음을 보여줍니다.

ERROR: 23505: duplicate key value violates unique constraint "asset_pkey"
DETAIL: Key (asset_id)=(7) already exists.
CONTEXT: processing remote data for replication origin "pg_32796" during message type "INSERT" for replication target relation "public.asset" in transaction 315434, finished at 0/6A12458

복제 오리진은 pg_32796이며 논리적 시퀀스 번호(LSN) 0/6A12458에서 종료됩니다.

데이터를 수동으로 수정하려면 충돌 시 복제를 중지하거나 disable_on_error 옵션을 사용하여 구독을 구성하면 됩니다.

또는 소스 및 대상의 데이터를 검토하여 충돌을 일으킨 LSN을 건너뛸 수 있는지 여부를 결정할 수 있습니다. 그런 다음 pg_replication_origin_advance() 함수를 사용하여 충돌을 일으킨 LSN을 건너뛰십시오. 자세한 내용은 PostgreSQL 웹 사이트의 pg_replication_origin_advance(node_name text, lsn pg_lsn)를 참조하십시오.

참고: Aurora PostgreSQL 호환 버전 15 이상에서는 pg_replication_origin_advance() 함수를 지원합니다.

LSN을 건너뛰려면 다음 단계를 완료하십시오.

다음 SQL 명령을 실행하여 구독을 일시적으로 끕니다.
```
ALTER SUBSCRIPTION subscription_name DISABLE;
```
참고: disable_on_error 옵션을 사용하여 구독을 구성한 경우 오류가 발생하면 구독이 자동으로 꺼집니다.

다음 pg_replication_origin_advance() 함수를 사용하여 오리진을 Finish_LSN+1로 진행합니다.

SELECT pg_replication_origin_advance('node_name','Finish_LSN+1'::pg_lsn);

참고: node_name을 노드 이름으로 바꾸십시오.

다음 명령을 실행하여 구독을 켭니다.

ALTER SUBSCRIPTION subscription-name ENABLE;

참고: subscription-name을 구독 이름으로 바꾸십시오.

여러 데이터 불일치를 해결하려면 대상 테이블을 정리하고 게시 및 구독을 다시 구성해야 할 수 있습니다.