PostgreSQL 수집 파이프라인 유지 관리

이 페이지에서는 PostgreSQL 수집 파이프라인을 유지 관리하기 위한 진행 중인 작업에 대해 설명합니다.

일반 파이프라인 유지 관리

이 섹션의 파이프라인 유지 관리 작업은 Lakeflow Connect의 모든 관리형 커넥터에 적용됩니다.

일반적인 파이프라인 유지 관리 작업은 일반적인 파이프라인 유지 관리 작업을 참조하세요.

사용되지 않는 준비 파일 제거

2025년 1월 6일 이후에 만든 수집 파이프라인의 경우 볼륨 준비 데이터는 25일 후에 자동으로 삭제되도록 예약되고 30일 후에 물리적으로 제거됩니다. 25일 이상 성공적으로 완료되지 않은 수집 파이프라인은 대상 테이블의 데이터 간격을 초래할 수 있습니다. 간격을 방지하려면 대상 테이블의 전체 새로 고침을 트리거합니다.

2025년 1월 6일 이전에 생성된 수집 파이프라인의 경우 Databricks 지원에 문의하여 CDC 데이터 준비에 대한 자동 보존 관리 수동 사용을 요청하세요.

다음 데이터는 자동으로 정리됩니다.

• CDC 데이터 파일
• 스냅샷 파일
• 테이블 데이터 준비

커넥터별 파이프라인 유지 관리

이 섹션의 파이프라인 유지 관리 작업은 PostgreSQL 커넥터와 관련이 있습니다.

복제에 새 테이블 추가

기존 복제 흐름에 새 테이블을 추가하려면 다음을 수행합니다.

1. 복제 사용자에게 필요한 권한을 부여합니다. 필요한 권한의 전체 목록은 PostgreSQL 데이터베이스 사용자 요구 사항을 참조하세요.

2. 해당 구조에 따라 새 테이블의 복제본 ID를 설정합니다. 올바른 복제본 ID 설정을 선택하는 방법에 대한 지침은 테이블에 대한 복제본 ID 설정을 참조하세요.

3. 게시에 테이블을 추가합니다.

   ALTER PUBLICATION databricks_publication ADD TABLE schema_name.new_table;
   

4. 새 테이블을 포함하도록 수집 파이프라인 구성을 업데이트합니다. Azure Databricks UI를 통해 또는 Databricks 자산 번들이나 CLI 명령의 ingestion_definition를 업데이트하여 이 작업을 수행할 수 있습니다.

5. 수집 게이트웨이를 다시 시작하여 새 테이블을 검색합니다. 게이트웨이는 정기적으로 새 테이블을 확인하지만 게이트웨이를 다시 시작하면 검색 프로세스가 빨라집니다.

복제 슬롯 정리

수집 파이프라인을 삭제하면 ** 복제 슬롯이 원본 PostgreSQL 데이터베이스 **에서 자동으로 제거되지 않습니다. 사용되지 않는 복제 슬롯으로 인해 WAL(Write-Ahead Log) 파일이 누적되어 원본 데이터베이스의 디스크 공간이 채워질 수 있습니다.

모든 복제 슬롯을 나열하려면 다음을 수행합니다.

SELECT slot_name, slot_type, active, restart_lsn, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots;

더 이상 필요하지 않은 복제 슬롯을 삭제하려면 다음을 수행합니다.

SELECT pg_drop_replication_slot('slot_name');

인라인 DDL 추적 정리

인라인 DDL 추적을 사용하지 않도록 설정하는 경우 각 데이터베이스에 대해 아래 단계를 실행하여 감사 스크립트에서 만든 개체를 정리합니다.

1. 이벤트 트리거를 삭제합니다.

   DROP EVENT TRIGGER IF EXISTS lakeflow_ddl_trigger CASCADE;
   

2. 게시에서 감사 테이블을 제거합니다.

   ALTER PUBLICATION databricks_publication DROP TABLE public.lakeflow_ddl_audit;
   

3. 감사 테이블을 삭제합니다.

   DROP TABLE IF EXISTS public.lakeflow_ddl_audit CASCADE;
   

복제 슬롯 모니터링

복제 슬롯의 상태를 모니터링하여 활성 상태이고 WAL 데이터를 사용하고 있는지 확인합니다.

SELECT slot_name,
       active,
       wal_status,
       active_pid,
       restart_lsn,
       confirmed_flush_lsn,
       pg_current_wal_lsn() AS current_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS replication_lag
FROM pg_replication_slots
WHERE slot_name LIKE 'databricks%';

큰 복제 지연 값은 다음 문제 중 하나를 나타낼 수 있습니다.

• 수집 게이트웨이가 원본 데이터베이스의 변경 내용을 따라가지 않습니다.
• 수집 게이트웨이가 장기간 중지되었습니다.
• 게이트웨이와 원본 데이터베이스 간의 네트워크 연결 문제입니다.

복제 슬롯이 비활성(active = false)이고 해당 파이프라인이 더 이상 필요하지 않음을 확인한 경우 복제 슬롯을 삭제하여 리소스를 확보합니다. 복제 슬롯 정리를 참조하세요.

WAL 디스크 사용량 모니터링

WAL(Write-Ahead 로그) 디스크 사용량을 모니터링하여 디스크 공간 문제를 방지합니다.

SELECT pg_size_pretty(sum(size)) AS wal_size
FROM pg_ls_waldir();

특정 복제 슬롯에 대한 WAL 보존을 확인하려면 다음을 수행합니다.

SELECT slot_name,
       active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS pending_wal
FROM pg_replication_slots
WHERE slot_name = 'your_slot_name';

WAL 디스크 사용량이 높은 경우 다음 단계를 수행합니다.

1. 수집 게이트웨이가 지속적으로 실행되고 있는지 확인합니다.

2. 게이트웨이 로그에서 WAL 데이터를 사용하지 못할 수 있는 오류를 확인합니다.

3. WAL 보존을 제한하도록 설정하는 max_slot_wal_keep_size 것이 좋습니다(PostgreSQL 13 이상):

   ALTER SYSTEM SET max_slot_wal_keep_size = '10GB';
   SELECT pg_reload_conf();
   

   경고

   설정 max_slot_wal_keep_size 으로 인해 WAL 보존 제한을 초과하면 복제 슬롯이 무효화되어 모든 테이블을 완전히 새로 고쳐야 합니다.

인게스천 게이트웨이를 다시 시작하십시오.

원본 데이터베이스의 부하를 줄이기 위해 수집 게이트웨이는 정기적으로 새 테이블만 확인합니다. 게이트웨이가 새 테이블을 검색하는 데 최대 6시간이 걸릴 수 있습니다. 이 프로세스의 속도를 향상하려면 게이트웨이를 다시 시작합니다.

또한 다음과 같은 상황에서 게이트웨이를 다시 시작합니다.

• 원본 데이터베이스에 대한 구성을 변경했습니다.
• 게이트웨이에 오류 또는 성능 문제가 발생했습니다.

출판물 업데이트

복제에 포함되는 테이블을 수정해야 하는 경우:

-- Add a table to the publication
ALTER PUBLICATION databricks_publication ADD TABLE schema_name.table_name;

-- Remove a table from the publication
ALTER PUBLICATION databricks_publication DROP TABLE schema_name.table_name;

-- List all tables in a publication
SELECT schemaname, tablename
FROM pg_publication_tables
WHERE pubname = 'databricks_publication';

게시를 업데이트한 후 수집 게이트웨이를 다시 시작하여 변경 내용을 적용합니다.