Postgre 엔드포인트 문제 해결 SQL - AWS Database Migration Service
소스에서 장시간 실행 중인 트랜잭션소스의 높은 워크로드높은 네트워크 처리량Aurora Postgre에서 파일 재생하기 SQL

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Postgre 엔드포인트 문제 해결 SQL

이 섹션에는 Postgre와 관련된 복제 시나리오가 포함되어 있습니다. SQL

소스에서 장시간 실행 중인 트랜잭션

소스 데이터베이스에 장기 실행 트랜잭션이 있는 경우 (예: 단일 트랜잭션에 수천 개의 삽입이 있는 경우) 트랜잭션이 완료될 때까지 DMS CDC 이벤트 및 트랜잭션 카운터가 증가하지 않습니다. 이러한 지연으로 인해 CDCLatencyTarget 지표로 측정 가능한 지연 시간 문제가 발생할 수 있습니다.

장시간 실행 중인 트랜잭션을 검토하려면 다음 중 하나를 수행합니다.

  • pg_replication_slots 보기를 사용합니다. restart_lsn값이 업데이트되지 않는 경우 장기간 실행되는 활성 트랜잭션으로 인해 SQL Postgre에서 Write Ahead Logs (WALs) 를 릴리스하지 못할 수 있습니다. pg_replication_slots뷰에 대한 자세한 내용은 Postgre 15.4 설명서의 pg_replication_slots를 참조하십시오. SQL

  • 아래의 쿼리를 사용하여 데이터베이스의 모든 활성 쿼리 목록을 관련 정보와 함께 반환합니다.

    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 필드에는 각 쿼리의 활성 기간이 표시되므로, 장시간 실행 중인 쿼리를 확인하는 데 사용할 수 있습니다.

소스의 높은 워크로드

소스 Postgre의 SQL 워크로드가 많은 경우 다음을 확인하여 지연 시간을 줄이십시오.

  • test_decoding플러그인을 사용하면 초당 트랜잭션 수 () 값이 높은 원본 데이터베이스에서 테이블의 하위 집합을 마이그레이션하는 동안 지연 시간이 길어질 수 있습니다. TPS 이는 test_decoding 플러그인이 모든 데이터베이스 변경 내용을 복제 인스턴스로 DMS 전송한 다음 작업의 테이블 매핑을 기반으로 필터링하기 때문입니다. 태스크의 테이블 매핑에 포함되지 않은 테이블의 이벤트는 소스 지연 시간을 증가시킬 수 있습니다.

  • 다음 방법 중 하나를 사용하여 TPS 처리량을 확인합니다.

    • Aurora Postgre SQL 소스의 경우 메트릭을 사용하십시오. CommitThroughput CloudWatch

    • Amazon RDS 또는 온프레미스에서 SQL 실행되는 Postgre의 경우 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 플러그인은 원본에서 log (WAL) 변경 내용을 미리 쓰고 관련 변경 사항만 복제 인스턴스로 전송합니다. 에서 pglogical 플러그인을 사용하는 방법에 대한 자세한 내용은 AWS DMS을 참조하십시오pglogical 플러그인 구성.

높은 네트워크 처리량

test_decoding 플러그인을 사용할 경우, 특히 대용량 트랜잭션 시 복제를 수행할 때 네트워크 대역폭 사용량이 높을 수 있습니다. 그 이유는 test_decoding 플러그인은 변경 사항을 처리한 후 이를 사람이 읽을 수 있는 형식으로 변환하는데, 원래 바이너리 형식보다 용량이 크기 때문입니다.

성능을 개선하려면 바이너리 플러그인인 pglogical 플러그인을 대신 사용하는 것이 좋습니다. test_decoding플러그인과 달리 pglogical 플러그인은 바이너리 형식 출력을 생성하므로 write ahead log (WAL) 스트림 변경이 압축됩니다.

Aurora Postgre에서 파일 재생하기 SQL

Postgre SQL 버전 13 이상에서는 logical_decoding_work_mem 파라미터가 디코딩 및 스트리밍을 위한 메모리 할당을 결정합니다. logical_decoding_work_mem파라미터에 대한 자세한 내용은 Postgre 13.13 설명서의 Postgre의 리소스 소비를 참조하십시오SQL. SQL

논리적 복제는 해당 트랜잭션이 커밋될 때까지 모든 트랜잭션의 변경 내용을 메모리에 누적합니다. 모든 트랜잭션에 저장된 데이터 양이 데이터베이스 매개 logical_decoding_work_mem 변수로 지정된 양을 초과하는 경우 새 디코딩 데이터에 사용할 메모리를 확보하기 위해 트랜잭션 데이터를 디스크로 넘깁니다. DMS

트랜잭션 실행 DMS 시간이 길거나 하위 트랜잭션이 많으면 논리적 디코딩 메모리 사용량이 증가할 수 있습니다. 이렇게 메모리 사용량이 증가하면 디스크에 유출 파일이 DMS 생성되어 복제 중에 소스 지연 시간이 길어집니다.

소스 워크로드 증가로 인한 영향을 줄이려면 다음과 같이 하십시오.

  • 장기 실행 트랜잭션을 줄이십시오.

  • 하위 트랜잭션 수를 줄이세요.

  • 단일 트랜잭션에서 전체 테이블을 삭제하거나 업데이트하는 등 대량의 로그 레코드를 생성하는 작업은 수행하지 마십시오. 대신 작은 일괄 처리로 작업을 수행하세요.

다음 CloudWatch 지표를 사용하여 소스의 워크로드를 모니터링할 수 있습니다.

  • TransactionLogsDiskUsage: 로직이 현재 점유하고 있는 바이트 수입니다. WAL 논리적 복제 슬롯이 새 쓰기 속도를 따라갈 수 없거나 장기간 실행되는 트랜잭션으로 인해 오래된 파일이 불필요한 수집이 불가능한 경우 이 값은 일정하게 증가합니다.

  • ReplicationSlotDiskUsage: 논리적 복제 슬롯이 현재 사용하는 디스크 공간의 양.

logical_decoding_work_mem파라미터를 조정하여 소스 지연 시간을 줄일 수 있습니다. 이 매개변수의 기본값은 64MB입니다. 이 매개 변수는 각 논리적 스트리밍 복제 연결에서 사용되는 메모리 양을 제한합니다. 디스크에 DMS 기록되는 디코딩된 변경 사항의 양을 줄이려면 work_mem 값을 값보다 훨씬 높게 설정하는 것이 좋습니다. logical_decoding_work_mem

특히 마이그레이션 작업이나 지연 시간이 많은 기간에는 유출 파일이 있는지 정기적으로 확인하는 것이 좋습니다. 너무 많은 수의 유출 파일이 생성되면 논리적 디코딩이 효율적으로 작동하지 않아 지연 시간이 늘어날 수 있다는 DMS 뜻입니다. 이 문제를 해결하려면 파라미터 값을 늘리십시오. logical_decoding_work_mem

함수를 사용하여 현재 트랜잭션 오버플로를 aurora_stat_file 확인할 수 있습니다. 자세한 내용은 Amazon 관계형 데이터베이스 서비스 개발자 안내서의 논리적 디코딩을 위한 작업 메모리 조정을 참조하십시오.