기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
이 섹션에는 PostgreSQL과 관련된 복제 시나리오가 나와 있습니다.
소스에서 장시간 실행 중인 트랜잭션
소스 데이터베이스에 장시간 실행 중인 트랜잭션이 있는 경우(예: 단일 트랜잭션에 수천 개의 삽입이 있는 경우), 트랜잭션이 완료될 때까지 DMS CDC 이벤트 및 트랜잭션 카운터가 증가하지 않습니다. 이러한 지연으로 인해 CDCLatencyTarget
지표로 측정 가능한 지연 시간 문제가 발생할 수 있습니다.
장시간 실행 중인 트랜잭션을 검토하려면 다음 중 하나를 수행합니다.
pg_replication_slots
보기를 사용합니다.restart_lsn
값이 업데이트되지 않을 경우, 장시간 실행 중인 활성 트랜잭션으로 인해 PostgreSQL이 Write Ahead Log(WAL)를 릴리스하지 못할 수 있습니다.pg_replication_slots
보기에 대한 자세한 내용은 PostgreSQL 15.4 설명서의 pg_replication_slots 섹션을 참조하세요. 아래의 쿼리를 사용하여 데이터베이스의 모든 활성 쿼리 목록을 관련 정보와 함께 반환합니다.
SELECT pid, age(clock_timestamp(), query_start), usename, query FROM pg_stat_activity WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' ORDER BY query_start desc;
쿼리 결과의
age
필드에는 각 쿼리의 활성 기간이 표시되므로, 장시간 실행 중인 쿼리를 확인하는 데 사용할 수 있습니다.
소스의 높은 워크로드
소스에 PostgreSQL의 워크로드가 높은 경우, 다음 사항을 확인하여 지연 시간을 줄입니다.
-
초당 트랜잭션(TPS) 값이 높은 소스 데이터베이스에서 테이블의 하위 집합을 마이그레이션하는 동안
test_decoding
플러그인을 사용하면 지연 시간이 길어질 수 있습니다. 그 이유는test_decoding
플러그인이 모든 데이터베이스 변경 사항을 복제 인스턴스로 보낸 다음, DMS가 태스크의 테이블 매핑을 기반으로 필터링하기 때문입니다. 태스크의 테이블 매핑에 포함되지 않은 테이블의 이벤트는 소스 지연 시간을 증가시킬 수 있습니다. -
다음 방법 중 하나를 사용하여 TPS 처리량을 확인합니다.
Aurora PostgreSQL 소스의 경우
CommitThroughput
CloudWatch 지표를 사용합니다.Amazon RDS 또는 온프레미스에서 실행되는 PostgreSQL의 경우, PSQL 클라이언트 버전 11 이상을 활용하여 아래의 쿼리를 사용합니다(결과를 진행하려면 쿼리 중에
enter
를 누릅니다).SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset select pg_sleep(60); SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";
test_decoding
플러그인 사용 시 지연 시간을 줄이려면pglogical
플러그인을 대신 사용하는 것이 좋습니다.test_decoding
플러그인과 달리,pglogical
플러그인은 원본에서 Write Ahead Log(WAL) 변경 사항을 필터링하고 관련 변경 사항만 복제 인스턴스로 전송합니다.pglogical
플러그인을 AWS DMS와 함께 사용하는 방법에 대한 내용은 pglogical 플러그인 구성 섹션을 참조하세요.
높은 네트워크 처리량
test_decoding
플러그인을 사용할 경우, 특히 대용량 트랜잭션 시 복제를 수행할 때 네트워크 대역폭 사용량이 높을 수 있습니다. 그 이유는 test_decoding
플러그인은 변경 사항을 처리한 후 이를 사람이 읽을 수 있는 형식으로 변환하는데, 원래 바이너리 형식보다 용량이 크기 때문입니다.
성능을 개선하려면 바이너리 플러그인인 pglogical
플러그인을 대신 사용하는 것이 좋습니다. test_decoding
플러그인과 달리 pglogical
플러그인은 바이너리 형식의 출력을 생성하므로, 압축된 Write Ahead Log(WAL) 스트림 변경 사항이 발생합니다.
Aurora PostgreSQL에서 파일 유출
PostgreSQL 버전 13 이상에서 logical_decoding_work_mem
파라미터는 디코딩 및 스트리밍을 위한 메모리 할당을 결정합니다. logical_decoding_work_mem
파라미터에 대한 자세한 내용은 PostgreSQL 13.13 설명서
논리적 복제는 트랜잭션이 커밋될 때까지 메모리의 모든 트랜잭션에 대한 변경 사항을 누적합니다. 모든 트랜잭션에 저장된 데이터의 양이 데이터베이스 파라미터 logical_decoding_work_mem
에 지정된 양을 초과하는 경우 DMS는 트랜잭션 데이터를 디스크에 유출하여 새 디코딩 데이터에 대한 메모리를 릴리스합니다.
오래 실행되는 트랜잭션 또는 많은 하위 트랜잭션으로 인해 DMS에서 논리적 디코딩 메모리를 사용할 수 있습니다. 이렇게 메모리 사용량이 증가하면 DMS가 디스크에 유출 파일을 생성하여 복제 중에 소스 지연 시간이 높아집니다.
소스 워크로드 증가의 영향을 줄이려면 다음을 수행합니다.
장기 실행 트랜잭션을 줄입니다.
하위 트랜잭션 수를 줄입니다.
단일 트랜잭션에서 전체 테이블을 삭제하거나 업데이트하는 등 대량의 로그 레코드 버스트를 생성하는 작업을 수행하지 마세요. 대신 더 작은 배치로 작업을 수행합니다.
다음 CloudWatch 지표를 사용하여 소스의 워크로드를 모니터링할 수 있습니다.
TransactionLogsDiskUsage
: 논리적 WAL이 현재 점유하는 바이트 수입니다. 논리적 복제 슬롯이 새 쓰기 속도를 따라갈 수 없거나 오래 실행되는 트랜잭션으로 인해 오래된 파일의 폐영역 회수가 불가능한 경우 이 값은 단조롭게 증가합니다.ReplicationSlotDiskUsage
: 논리적 복제 슬롯이 현재 사용하는 디스크 공간의 양입니다.
logical_decoding_work_mem
파라미터를 조정하여 소스 지연 시간을 줄일 수 있습니다. 이 파라미터의 기본값은 64MB입니다. 이 파라미터는 각 논리적 스트리밍 복제 연결에 사용되는 메모리의 양을 제한합니다. DMS가 디스크에 쓰는 디코딩된 변경의 양을 줄이려면 logical_decoding_work_mem
값을 work_mem
값보다 크게 설정하는 것이 좋습니다.
특히 마이그레이션 활동이나 지연 시간이 많은 기간에는 유출 파일을 정기적으로 확인하는 것이 좋습니다. DMS가 상당한 수의 유출 파일을 생성하는 경우 논리적 디코딩이 효율적으로 작동하지 않아 지연 시간이 늘어날 수 있습니다. 이를 완화하려면 logical_decoding_work_mem
파라미터 값을 늘리세요.
aurora_stat_file
함수를 사용하여 현재 트랜잭션 오버플로를 확인할 수 있습니다. 자세한 내용은 Amazon Relational Database Service 개발자 안내서의 논리적 디코딩을 위한 작업 메모리 조정을 참조하세요.