PostgreSQL용 Openflow 커넥터 유지 관리

이 문서에서는 소스 PostgreSQL 데이터베이스를 변경할 때 PostgreSQL용 Openflow 커넥터를 유지 관리하는 데 중요한 고려 사항과 모범 사례를 설명합니다. 또한 테이블 복제를 다시 시작하고 커넥터를 재설치하는 방법도 설명합니다.

출처: Snowflake 문서

본문

테이블의 복제 상태 확인

연결 오류나 고가용성 장애 조치 중 일시적 소스 사용 불가 같은 일시적 실패는 테이블 복제를 막지 않습니다. 복제된 테이블은 현재 상태를 유지하고 커넥터는 다음 폴링 주기에 재시도합니다. 그러나 지원되지 않는 데이터 유형 같은 영구 실패는 테이블 복제를 막습니다.

복제 문제를 해결하거나 테이블이 복제 흐름에서 성공적으로 제거되었는지 확인하려면 Table State Store를 확인하세요.

Openflow 런타임 캔버스에서 프로세스 그룹을 마우스 오른쪽 버튼으로 클릭하고 Controller Services를 선택하세요. 컨트롤러 서비스 목록이 표시됩니다.
Table State Store 레이블이 있는 행을 찾아 행 오른쪽의 More 버튼을 클릭하고 View State를 선택하세요.

테이블과 현재 상태 목록이 표시됩니다. 검색 상자에 입력해 테이블 이름으로 목록을 필터링할 수 있습니다. 가능한 상태는 다음과 같습니다.

NEW: 테이블이 복제 예정이지만 복제가 시작되지 않았습니다.
SNAPSHOT_REPLICATION: 커넥터가 기존 데이터를 복사 중입니다. 모든 레코드가 목적지 테이블에 저장될 때까지 이 상태가 표시됩니다.
INCREMENTAL_REPLICATION: 커넥터가 변경을 활발히 복제 중입니다. 이 상태는 스냅샷 복제가 끝난 뒤 표시되며, 테이블이 복제에서 제거되거나 복제가 실패할 때까지 계속 표시됩니다.
FAILED: 오류로 인해 복제가 영구적으로 중지되었습니다.

참고: Openflow 런타임 캔버스는 테이블 상태 변경을 표시하지 않고 현재 상태만 표시합니다. 그러나 테이블 상태 변경은 발생 시 로그에 기록됩니다. 다음 로그 메시지를 찾으세요.

Replication state for table <database_name>.<schema_name>.<table_name> changed from <old_state> to <new_state>

영구 실패가 테이블 복제를 막으면 테이블을 복제에서 제거하세요. 실패 원인을 해결한 뒤 테이블을 복제에 다시 추가할 수 있습니다. 자세한 내용은 'Restart table replication'을 참조하세요.

테이블 복제 다시 시작

참고: 이 절차는 테이블을 제자리에서 다시 스냅샷합니다. Runtime Extensions 버전 2026.6.18.9 이상과 커넥터 버전 0.55.0 이상이 필요합니다. 더 이른 버전에서는 Snowflake에 이미 존재하는 테이블 재스냅샷이 제자리에서 다시 로드하는 대신 실패합니다. 이 절차를 사용하기 전에 먼저 Runtime Extensions를 업그레이드한 뒤 커넥터 플로우를 업그레이드하세요.

FAILED 상태의 테이블(예: 기본 키 누락이나 지원되지 않는 스키마 변경 때문)은 자동으로 다시 시작되지 않습니다. 테이블이 FAILED 상태에 들어가거나 복제를 처음부터 다시 시작해야 한다면 다음 절차로 테이블을 복제에서 제거하고 다시 추가하세요.

참고: 실패가 기본 키 누락 같은 소스 테이블의 문제 때문이라면 계속하기 전에 소스 데이터베이스에서 해당 문제를 해결하세요.

다음 방법 중 하나로 테이블을 복제에서 제거하세요.
- 테이블을 Re-snapshot Table Exclusions 파라미터에 추가해 일시적으로 복제에서 제외합니다. 이 접근 방식은 테이블이 변경하고 싶지 않은 Included Table Regex와 일치할 때 편리합니다.
- Ingestion Parameters 컨텍스트에서 Included Table Names에서 테이블을 제거하거나, Included Table Regex를 수정해 테이블이 더 이상 일치하지 않게 하세요.
테이블이 제거되었는지 확인하세요.
- Openflow 런타임 캔버스에서 프로세스 그룹을 마우스 오른쪽 버튼으로 클릭하고 Controller Services를 선택하세요.
- 테이블 목록 컨트롤러 서비스에서 Table State Store 행을 찾아 행 오른쪽의 세로 점 3개를 클릭한 뒤 View State를 선택하세요.
- 중요: 계속하기 전에 테이블 상태가 이 목록에서 완전히 제거될 때까지 기다려야 합니다. 이 구성 변경이 완료되기 전에는 계속하지 마세요.
테이블을 다시 추가하기 전에 커넥터의 모든 큐가 비워질 때까지 기다리세요. 모든 FlowFile이 처리되면 커넥터 프로세스 그룹의 Queued 값이 0이 됩니다.
- 경고: 제거 전에 캡처된 변경 이벤트가 여전히 큐에 있는 동안 테이블을 다시 추가하지 마세요. 테이블을 다시 추가하면 커넥터가 추가 전용 모드로 새 스냅샷을 로드하므로, 재스냅샷 후 테이블에 병합되는 남은 변경 이벤트가 목적지 테이블에 중복 행을 만들 수 있습니다.
첫 단계에서 한 변경을 되돌려 테이블을 다시 추가하세요. 즉 Re-snapshot Table Exclusions에서 테이블을 제거하거나, Included Table Names 또는 Included Table Regex에 다시 추가하세요.
- 목적지 테이블을 먼저 삭제할 필요는 없습니다. 커넥터가 테이블을 제자리에서 재스냅샷합니다. 즉 현재 목적지 테이블의 제로 카피 클론을 <destination_table>_ARCHIVE_<timestamp>라는 보관 테이블로 만들고, 목적지 테이블을 비운 뒤 같은 목적지 테이블에 새 스냅샷을 로드합니다. 목적지 테이블 객체가 보존되므로 스트림 같은 종속 객체는 연결된 상태로 계속 작동합니다.
- 보관 테이블은 안전 장치로 다시 로드 직전의 목적지 테이블 콘텐츠 복사본을 유지합니다. 커넥터는 그것을 다시 읽거나 쓰지 않으므로, 백업이 더 이상 필요 없어지면 언제든 삭제할 수 있습니다. 일반적으로 재스냅샷이 완료되고 목적지 데이터가 올바른지 확인한 뒤입니다.
다시 시작을 확인하세요. 앞서 주어진 지침으로 Table State Store를 확인하세요. 테이블 상태가 NEW로 나타난 뒤 SNAPSHOT_REPLICATION으로, 마지막으로 INCREMENTAL_REPLICATION으로 전환되어야 합니다.

초과 크기 값 한도 높이기

기본적으로 커넥터는 최대 16 MB까지의 개별 값을 복제하고, 더 큰 값을 포함하는 테이블을 영구 실패로 표시합니다. Snowflake 계정에 ENABLE_OPENFLOW_CDC_POSTGRES_SSV2 파라미터가 true로 설정되어 있으면 값당 한도를 16 MB에서 128 MB로 높일 수 있습니다.

중요: 128 MB 한도는 두 가지 방식으로 적용됩니다. 단일 값의 최대 크기이자 행의 최대 총 크기입니다. 커넥터는 복제된 모든 행에 메타데이터 열(_SNOWFLAKE_UPDATED_AT, _SNOWFLAKE_INSERTED_AT, _SNOWFLAKE_DELETED)을 추가하는데, 이 열들이 행의 다른 모든 열과 함께 행당 한도에 포함됩니다. 그 결과 행에 다른 데이터가 있으면 실제로 단일 값이 전체 128 MB에 도달할 수 없습니다.

증가된 한도는 모든 열 유형에 동일하게 적용되지 않습니다.

참고: Snowflake에서 BINARY의 최대 크기는 증가된 크기 제한을 활성화해도 64 MB(BINARY(67108864))입니다. 최대 128 MB를 담을 수 있는 것은 VARCHAR, VARIANT, ARRAY, OBJECT 열뿐입니다.

128 MB 한도 사용 가능 여부 확인

ENABLE_OPENFLOW_CDC_POSTGRES_SSV2 파라미터 값은 쿼리로 확인하지 못할 수 있습니다. 활성화되었는지 확인하려면 FlowFiles가 'Upload Rows via Snowpipe Streaming 2' 프로세서를 통해 흐르는지('Upload Rows via Snowpipe Streaming'이 아닌) 확인하세요.

프로세서 구성

다음 두 프로세서 모두에서 Oversized Value Limit 속성을 128 MB로 업데이트하세요.

Fetch Table Rows(Snapshot Load 그룹)
Read PostgreSQL CDC Stream(Incremental Load 그룹)

각 프로세서에 대해:

플로우에서 프로세서를 찾으세요. 커넥터 캔버스의 오른쪽 위 검색 상자로 이름별 프로세서를 찾을 수 있습니다.
프로세서를 마우스 오른쪽 버튼으로 클릭하고 Configure를 선택하세요.
Properties 탭을 여세요.
Oversized Value Limit을 128 MB로 설정하세요.
변경을 적용하세요.

이미 복제 중이고 목적지 열이 VARCHAR(134217728) 또는 BINARY(67108864)보다 좁은 테이블은 '기존 테이블 마이그레이션'을 참조하세요.

기존 테이블 마이그레이션

'초과 크기 값 한도 높이기'의 단계는 새로 생성되는 목적지 테이블의 한도를 높입니다. 이미 복제 중이고 목적지 열 유형이 VARCHAR(134217728)이나 BINARY(67108864)가 아니지만, 지금 원래 16 MB 한도보다 큰 값을 로드하려면 저널 테이블과 목적지 테이블 모두에서 열 유형을 수동으로 넓혀야 합니다.

마이그레이션 전에 현재 목적지 열 유형을 확인하세요. 스냅샷 복제가 수행된 시점에 따라 달라질 수 있기 때문입니다.

경고: 영향을 받는 테이블의 저널 또는 목적지 테이블을 변경하기 전에 해당 테이블의 복제를 중지해야 합니다. 복제가 활성화된 동안 이러한 테이블을 변경하면 진행 중인 데이터가 손상될 수 있습니다.

테이블을 마이그레이션하려면:

Snapshot Load와 Incremental Load 그룹의 최상위 프로세서를 중지해 모든 큐가 빌 때까지 영향을 받는 테이블의 복제를 중지하세요. 동등한 중지 절차는 'Reclaim journal table storage' 하위 단계를 참조하세요.
열 유형에 따라 저널 테이블과 목적지 테이블 모두에서 열을 넓히세요.
- VARCHAR 열: 저널·목적지 테이블 모두에서 단일 ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE VARCHAR(134217728)를 실행합니다.
- BINARY 열: Snowflake는 BINARY를 제자리에서 넓히는 것을 허용하지 않으므로 저널·목적지 테이블 양쪽에서 다음을 수행하세요.
  - BINARY(67108864) 유형의 새 열을 추가합니다.
  - 원래 열에서 새 열로 데이터를 복사합니다.
  - 원래 열을 삭제하고 새 열 이름을 원래 이름으로 바꿉니다.
프로세서를 다시 활성화해 복제를 다시 시작하세요.

성능 고려 사항

값당 한도를 높이면 커넥터가 메모리에 로드하고 플로우를 통해 이동하는 데이터 양이 늘어나 런타임과 웨어하우스 양쪽의 부하가 높아집니다. 이에 맞게 런타임과 웨어하우스 크기를 조정하세요.

스냅샷과 증분 복제 모두에서 'Upload Rows via Snowpipe Streaming 2' 프로세서 앞의 큐가 FlowFiles로 차 백프레셔를 유발할 수 있으며, 이는 많은 런타임 디스크 공간을 소비합니다. 큰 테이블에서는 추가 스토리지를 제공하도록 Large 런타임을 사용하세요. 크기 선택에 대한 지침은 Runtime sizing을 참조하세요.

스냅샷 복제

스냅샷 복제 중 fetchSize * rowSize * concurrentQueries의 곱은 NiFi 런타임의 힙 크기를 초과할 수 없습니다. 여기서:

fetchSize는 쿼리당 가져오는 행 수로 Fetch Table Rows 프로세서에 설정(기본: 100).
rowSize는 가져오는 단일 행의 크기.
concurrentQueries는 동시 쿼리 수로 Fetch Table Rows 프로세서에 설정(기본: 2).

이 메모리 요구 사항은 Oversized Value Strategy가 Set Null로 설정된 경우에도 적용됩니다. 커넥터가 값을 NULL로 바꾸기 전에 각 초과 크기 값을 메모리에 로드해야 하기 때문입니다.

소스 데이터베이스에 조밀하게 포장된 초과 크기 값이 많다면 스냅샷을 시작하기 전에 영향을 받는 열을 복제에서 제외하는 것을 고려하세요. 예를 들어 1 GB 값을 포함하는 열이 있으면 9개 행(~9 GB)만 로드해도 힙을 소진해 Medium 런타임에서 메모리 부족 오류가 발생할 수 있습니다.

스냅샷 복제를 빠르게 하려면 'Upload Rows via Snowpipe Streaming 2' 프로세서가 사용하는 채널 수를 늘릴 수 있습니다. 채널 수는 프로세서의 Channel Group 속성으로 설정되며 기본값은 ${chunk.index:isEmpty():ifElse('1', ${chunk.index:mod(8)})}입니다.

채널 수를 늘리려면:

플로우에서 Upload Rows via Snowpipe Streaming 2 프로세서를 찾으세요.
프로세서를 중지하세요. 속성을 변경하려면 먼저 프로세서를 중지해야 합니다.
프로세서를 마우스 오른쪽 버튼으로 클릭하고 Configure를 선택하세요.
Properties 탭을 여세요.
Channel Group 속성에서 표현식의 값 8을 늘리세요. 예: 채널 수를 두 배로 하려면 8을 16으로 변경.
변경을 적용하세요.
프로세서를 시작하세요.

경고: 스냅샷 복제가 진행 중인 동안에는 채널 수를 늘리기만 하세요. 활성 스냅샷 중 채널 수를 줄이면 데이터 손실이 발생할 수 있습니다.

증분 복제

소스가 큰 값을 포함한 행에 잦은 변경을 만들면 Large 웨어하우스가 필요할 수 있습니다. 더 작은 웨어하우스에서는 많은 8 MB 행을 복제하면 메모리 부족 오류가 발생할 수 있습니다. 반대로 연속 병합으로 128 MB 행을 복제하면 웨어하우스 오류 없이 완료됩니다. 커넥터가 'Upload Rows via Snowpipe Streaming 2' 프로세서를 통해 파일을 파일별로 스트리밍하고 병합이 이를 점진적으로 처리하기 때문입니다.

기존 스키마에 오류 로깅 활성화

Error Handling Strategy 파라미터를 Log Errors and Continue로 설정하면 커넥터는 그 후에 만드는 테이블에서만 오류 로깅을 자동으로 활성화합니다. 더 일찍 만든 테이블은 오류 로깅을 켤 때까지 거부된 행을 캡처하지 않습니다. 오류 처리 전략에 대한 자세한 내용은 'Error handling for invalid rows'를 참조하세요.

커넥터는 저널 테이블을 목적지 테이블과 같은 스키마에 저장하므로, 전체 목적지 스키마에 대해 한 번에 오류 로깅을 켤 수 있습니다. 목적지 스키마마다 다음 저장 프로시저를 한 번 실행하세요. my_database를 목적지 데이터베이스로, my_schema를 목적지 스키마로 바꾸세요.

참고: 스키마 이름은 따옴표로 묶인 식별자(예: '"my_schema"')로 전달되어 커넥터가 만든 정확한 대소문자 구분 이름과 일치합니다. 커넥터가 목적지 스키마 이름을 지정하는 방식에 대한 자세한 내용은 'PostgreSQL Destination Parameters'를 참조하세요.

USE DATABASE my_database;

WITH enable_error_logging AS PROCEDURE (schema_name STRING)
RETURNS STRING
LANGUAGE SQL
AS
$$
DECLARE
 tables RESULTSET;
 table_count NUMBER DEFAULT 0;
BEGIN
 SHOW TABLES IN SCHEMA IDENTIFIER(:schema_name);

 -- Assign AFTER SHOW TABLES so LAST_QUERY_ID() refers to that result
 tables := (
 SELECT "database_name", "schema_name", "name"
 FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
 WHERE "kind" = 'TABLE'
 );

 FOR t IN tables DO
 -- Double-quote each identifier so names with special characters are handled safely
 EXECUTE IMMEDIATE
 'ALTER TABLE "' || REPLACE(t."database_name", '"', '""') || '".' ||
 '"' || REPLACE(t."schema_name", '"', '""') || '".' ||
 '"' || REPLACE(t."name", '"', '""') || '" ' ||
 'SET ERROR_LOGGING = TRUE';

 table_count := table_count + 1;
 END FOR;

 RETURN 'Enabled ERROR_LOGGING on ' || table_count || ' table(s) in schema ' || :schema_name;
END;
$$
CALL enable_error_logging('"my_schema"');

오류 로깅이 활성화되었는지 확인

스키마의 모든 테이블에서 오류 로깅이 활성화되었는지 확인하려면 다음 프로시저를 실행하세요. 오류 로깅이 활성화된 테이블 수와 그렇지 않은 테이블 수를 보고합니다.

USE DATABASE my_database;

WITH verify_error_logging AS PROCEDURE (schema_name STRING)
RETURNS STRING
LANGUAGE SQL
AS
$$
DECLARE
 tables RESULTSET;
 probe RESULTSET;
 total_tables NUMBER DEFAULT 0;
 logging_enabled NUMBER DEFAULT 0;
 disabled_or_invisible NUMBER DEFAULT 0;
BEGIN
 SHOW TABLES IN SCHEMA IDENTIFIER(:schema_name);

 -- Assign AFTER SHOW TABLES so LAST_QUERY_ID() refers to that result
 tables := (
 SELECT "database_name", "schema_name", "name"
 FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
 WHERE "kind" = 'TABLE'
 );

 FOR t IN tables DO
 total_tables := total_tables + 1;

 -- Probe ERROR_TABLE(): it succeeds only when error logging is enabled and visible
 BEGIN
 probe := (
 EXECUTE IMMEDIATE
 'SELECT 1 FROM ERROR_TABLE(' ||
 '"' || REPLACE(t."database_name", '"', '""') || '".' ||
 '"' || REPLACE(t."schema_name", '"', '""') || '".' ||
 '"' || REPLACE(t."name", '"', '""') || '"' ||
 ') LIMIT 1'
 );
 logging_enabled := logging_enabled + 1;
 EXCEPTION
 WHEN STATEMENT_ERROR THEN
 disabled_or_invisible := disabled_or_invisible + 1;
 END;
 END FOR;

 RETURN 'schema=' || :schema_name ||
 ', total_tables=' || total_tables ||
 ', error_logging_enabled=' || logging_enabled ||
 ', error_logging_disabled_or_not_visible=' || disabled_or_invisible;
END;
$$
CALL verify_error_logging('"my_schema"');

PostgreSQL 업그레이드

커넥터 업그레이드는 PostgreSQL이 다음 마이너 또는 메이저 버전으로 업그레이드되는지에 따라 접근 방식이 다릅니다.

마이너 버전 업그레이드

데이터 안전(data-safe)합니다.
특별한 처리가 필요 없습니다.
연결 문제 보고를 피하기 위해 업그레이드 기간 동안 커넥터를 중지해야 합니다.
업그레이드 후 데이터 손실 없이 복제를 계속합니다.

메이저 버전 업그레이드

PostgreSQL 서버가 커넥터가 사용하는 것을 포함한 복제 슬롯을 삭제해야 합니다.
복제 슬롯을 새 버전으로 보존하거나 마이그레이션할 수 없습니다. PostgreSQL 17 이상 업그레이드도 참조하세요.
업그레이드 기간 동안 소스 데이터베이스에 대한 모든 쓰기를 중지할 수 없는 한, 모든 테이블의 복제를 스냅샷 단계부터 다시 시작해야 합니다. 그 경우 복제된 데이터를 유지하고 증분 복제만으로 재개할 수 있습니다. 자세한 내용은 'Upgrade without re-snapshotting tables'를 참조하세요.

마이너 버전 업그레이드를 수행하려면 다음을 수행하세요.

모든 Processors와 Controller Services를 포함해 커넥터를 중지합니다.
PostgreSQL을 업그레이드합니다.
커넥터를 다시 시작합니다.

메이저 버전 업그레이드를 수행하려면 다음을 수행하세요.

Included Table Names와 Included Table Regex 파라미터를 비워 커넥터에서 모든 테이블을 복제에서 제거합니다.
캡처된 모든 변경이 목적지 테이블에 병합되도록 커넥터의 모든 큐가 비워질 때까지 기다립니다.
모든 Processors와 Controller Services를 포함해 커넥터를 중지합니다.
커넥터에서 Incremental Load 그룹을 엽니다.
CDC 프로세서의 상태를 지웁니다.
- 커넥터에서 Incremental Load 그룹을 엽니다.
- 그룹의 최상위 프로세서인 Read PostgreSQL CDC Stream을 마우스 오른쪽 버튼으로 클릭하고 View state를 선택합니다.
- Clear state를 클릭합니다.
- Close를 클릭합니다.
PostgreSQL을 업그레이드합니다.
커넥터를 다시 시작합니다. 새 복제 슬롯이 생성됩니다.
모든 테이블을 Included Table Names 또는 Included Table Regex 파라미터에 다시 추가합니다.

테이블을 다시 추가하기 전에 목적지 테이블을 삭제하거나 이름을 바꿀 필요는 없습니다. 커넥터는 각 테이블을 제자리에서 재스냅샷하며, 이는 스트림 같은 종속 객체와 함께 목적지 테이블 객체를 보존합니다. 새 스냅샷을 로드하기 전에 커넥터는 이전 내용의 복사본을 <destination_table>_ARCHIVE_<timestamp>라는 보관 테이블에 저장하며, 재스냅샷이 완료되었음을 확인한 뒤 삭제할 수 있습니다. 자세한 내용은 'Restart table replication'을 참조하세요.

테이블 재스냅샷 없이 업그레이드

업그레이드가 복제 슬롯을 삭제할 때, 업그레이드 기간 동안 소스 데이터베이스에 대한 모든 쓰기를 중지할 수 있다면 모든 테이블을 재스냅샷하지 않아도 됩니다. 이는 메이저 버전 업그레이드와 16 이하 버전에서 PostgreSQL 17.0으로의 모든 업그레이드에 적용됩니다. 커넥터는 이미 복제한 데이터를 유지하고 증분 복제만으로 계속합니다.

경고: 커넥터를 중지한 시점부터 모든 테이블이 증분 복제로 돌아올 때까지 복제된 데이터베이스에 어떤 종류의 쓰기도(DML이든 DDL이든) 도달할 수 없습니다. 새 복제 슬롯은 현재 write-ahead 로그 위치에서 시작하므로, 그 기간 중 이루어진 변경은 손실되며 새 스냅샷 없이는 복구할 방법이 없습니다.

테이블을 재스냅샷하지 않고 업그레이드하려면 다음을 수행하세요.

Included Table Names와 Included Table Regex 파라미터를 비워 커넥터에서 모든 테이블을 복제에서 제거합니다.
캡처된 모든 변경이 목적지 테이블에 병합되도록 커넥터의 모든 큐가 비워질 때까지 기다립니다.
모든 Processors와 Controller Services를 포함해 커넥터를 중지합니다.
소스 데이터베이스에 대한 모든 쓰기를 중지하고, 이 절차의 나머지 동안 중지 상태를 유지합니다.
CDC 프로세서의 상태를 지웁니다.
- 커넥터에서 Incremental Load 그룹을 엽니다.
- 그룹의 최상위 프로세서인 Read PostgreSQL CDC Stream을 마우스 오른쪽 버튼으로 클릭하고 View state를 선택합니다.
- Clear state를 클릭합니다.
- Close를 클릭합니다.
PostgreSQL을 업그레이드합니다.
PostgreSQL Ingestion Parameters 컨텍스트에서 Ingestion Type 파라미터를 incremental로 설정합니다. 자세한 내용은 'Openflow Connector for PostgreSQL: Set up incremental replication without snapshots'를 참조하세요.
커넥터를 다시 시작합니다. 새 복제 슬롯이 생성됩니다.
모든 테이블을 Included Table Names 또는 Included Table Regex 파라미터에 다시 추가합니다. 테이블은 스냅샷 단계를 건너뛰고 기존 목적지 테이블로 증분 복제됩니다.
Table State Store 컨트롤러 서비스에서 모든 테이블이 INCREMENTAL_REPLICATION 상태에 도달하는지 확인합니다. 테이블 상태 보기 지침은 'Check the replication status of a table'을 참조하세요.
소스 데이터베이스에 대한 쓰기를 재개합니다.
나중에 추가하는 테이블이 여전히 스냅샷을 받도록 Ingestion Type 파라미터를 full로 다시 설정합니다.

PostgreSQL 17 이상 버전 업그레이드

PostgreSQL 17은 업그레이드를 개선해 17.1 » 18.0 같은 이후 버전으로 업그레이드할 때 더 이상 복제 슬롯을 삭제하지 않습니다. 이전 버전(16 및 이하)에서 PostgreSQL 17.0 이상으로 업그레이드하면 복제 슬롯이 삭제되며 메이저 업그레이드로 취급해야 합니다.

향후 PostgreSQL 버전도 업그레이드 과정을 더 개선할 수 있습니다.

커넥터가 failover 슬롯 지원을 사용한다면 업그레이드를 시작하기 전에 슬롯이 따라잡혀 있고 충돌하지 않는지 확인하세요. 'Additional step when running pg_upgrade'를 참조하세요.

저널 테이블 스토리지 회수

저널 테이블은 복제된 테이블의 모든 변경을 담고 있습니다. 커넥터는 절대 삭제하지 않지만, 저널 위에 놓인 추가 전용 스트림을 사용해 각 복제된 소스 테이블의 최신 저널만 읽습니다. 스토리지를 회수하려면 다음을 할 수 있습니다.

언제든 모든 저널 테이블을 잘라냅니다(truncate).
복제에서 제거된 소스 테이블과 관련된 저널 테이블을 삭제합니다.
활발히 복제되는 테이블의 최신 세대 저널 테이블을 제외한 나머지를 삭제합니다.

예를 들어 커넥터가 소스 테이블 orders를 활발히 복제하도록 설정되어 있고, 이전에 테이블 customers를 복제에서 제거했다면 다음과 같은 저널 테이블이 있을 수 있습니다. 이 경우 orders_5678_2를 제외한 나머지를 모두 삭제할 수 있습니다.

customers_1234_1
customers_1234_2
orders_5678_1
orders_5678_2

커넥터 중지 또는 삭제

커넥터를 중지하거나 제거할 때 커넥터가 사용하는 복제 슬롯을 고려해야 합니다.

커넥터는 snowflake_connector_로 시작하고 임의 접미사가 붙는 이름의 자체 복제 슬롯을 만듭니다. 커넥터가 복제 스트림을 읽을 때 슬롯을 진행시켜, PostgreSQL이 WAL 로그를 다듬고 디스크 공간을 확보할 수 있게 합니다.

커넥터가 일시 중지되면 슬롯이 진행되지 않고 소스 데이터베이스의 변경이 계속 WAL 로그 크기를 늘립니다. 특히 트래픽이 많은 데이터베이스에서는 커넥터를 오래 일시 중지해 두면 안 됩니다.

커넥터가 제거될 때, DROP OPENFLOW CONNECTOR(gen 2)로 삭제하든 Openflow 캔버스에서 삭제하든, 또는 전체 Openflow 인스턴스를 삭제하는 식의 다른 수단이든, 복제 슬롯은 그대로 남아 있어 수동으로 삭제해야 합니다.

같은 PostgreSQL 데이터베이스에서 복제하는 커넥터 인스턴스가 여러 개라면 각 인스턴스가 고유한 이름의 복제 슬롯을 만듭니다. 복제 슬롯을 수동으로 삭제할 때 올바른 슬롯인지 확인하세요. 특정 커넥터 인스턴스가 사용하는 복제 슬롯은 CaptureChangePostgreSQL 프로세서의 상태를 확인해 알 수 있습니다.

커넥터 재설치

이 섹션에서는 커넥터를 재설치하는 방법을 설명합니다. 새 커넥터가 같은 런타임에 설치되는 경우와 새 런타임으로 이동되는 경우를 모두 다룹니다. 재설치는 '스냅샷 없는 증분 복제'와 함께 자주 사용됩니다.

경고: 커넥터가 재설치 전에 중단된 것과 같은 CDC 스트림 위치부터 계속 복제하려면, 소스 데이터베이스가 이전 커넥터가 중지되고 새 커넥터가 시작되는 사이의 시간을 커버할 만큼 오래 WAL을 유지해야 합니다. 트래픽에 따라 PostgreSQL 서버의 max_wal_size 파라미터가 충분히 높은지 확인하고 재설치 시간을 최소화하세요.

사전 준비 사항

커넥터 파라미터 컨텍스트 값을 검토하고 기록하세요. 같은 런타임에 커넥터를 재설치한다면 기존 컨텍스트를 재사용할 수 있습니다. 새 인스턴스가 다른 런타임에 있다면 모든 파라미터를 다시 입력해야 합니다.

커넥터를 재설치하려면:

기존 커넥터의 진행 중인 모든 FlowFile 처리를 마친 뒤 커넥터를 중지하세요.
- Snowsight에 로그인합니다.
- 내비게이션 메뉴에서 Ingestion » Openflow를 선택합니다.
- Launch Openflow를 선택합니다.
- Openflow 창에서 Runtimes 탭을 선택합니다.
- 커넥터가 포함된 런타임을 선택합니다.
- 커넥터를 선택합니다.
- Snapshot Load 그룹의 최상위 프로세서 Set Tables for Replication을 중지합니다.
- Incremental Load 그룹의 최상위 프로세서 Read PostgreSQL CDC Stream을 중지합니다.
- Merge Task Schedule CRON 파라미터 값을 변경했다면 * * * * * ?로 되돌리세요. 그렇지 않으면 다음 예약 실행까지 큐가 비워지지 않습니다.
- 커넥터의 모든 FlowFile이 처리되고 모든 큐가 비워질 때까지 기다리세요. 모든 FlowFile이 처리되면 커넥터 프로세스 그룹의 Queued 값이 0이 됩니다. 원래 커넥터 큐에 항목이 남아 있으면 새 커넥터가 시작될 때 데이터 공백이 있을 수 있습니다.
- 커넥터의 모든 Processors와 Controller Services를 중지하세요.
- Incremental Load 그룹의 최상위 프로세서인 Read PostgreSQL CDC Stream의 상태를 확인해 원래 커넥터가 사용한 복제 슬롯 이름을 찾아 복사하세요. 복제 슬롯 이름은 replication.slot.name 키 아래에 저장됩니다. 키 값을 텍스트 편집기에 복사하세요.
커넥터의 새 인스턴스를 만드세요. 원래 커넥터와 같은 런타임을 사용한다면 기존 파라미터 컨텍스트를 유지하고 설정을 재사용할 수 있습니다.
- 주의: 기존 커넥터는 중지된 상태로 유지되는 한 런타임에 남아 있어도 새 인스턴스와 간섭하지 않습니다.
다른 런타임에 설치하거나 이전 파라미터 컨텍스트를 삭제했다면 'Set up the Openflow Connector for PostgreSQL'에 설명된 테이블 이름과 패턴을 포함해 모든 구성 설정을 새 파라미터 컨텍스트에 입력하세요.
PostgreSQL Ingestion Parameters 컨텍스트를 열고 Ingestion Type 파라미터를 incremental로 설정하세요. 자세한 내용은 'Enable incremental replication without snapshots'를 참조하세요.
PostgreSQL Source Parameters 컨텍스트를 열고 Replication Slot Name 파라미터를 아까 복사한 값으로 설정하세요.
새 커넥터를 시작하세요.

사용 메모

새 커넥터는 원래 커넥터가 만든 기존 목적지 테이블을 사용하지만, 새 저널 테이블을 만듭니다.

PostgreSQL용 Openflow 커넥터 유지 관리