Openflow Connector for PostgreSQL 정보¶

테이블이 복제되는 방법¶

1. 스키마 검사: 커넥터는 소스 테이블의 열, 이름, 유형을 검색한 다음 Snowflake 및 커넥터의 제한 사항에 대해 유효성을 검사합니다. 유효성 검사에 실패하면 이 스테이지가 실패하고 사이클이 완료됩니다. 스키마 자가 분석을 성공적으로 완료한 후 커넥터는 빈 대상 테이블을 생성합니다.

2. 스냅샷 로딩: 커넥터는 소스 테이블에서 사용 가능한 모든 데이터를 대상 테이블에 복사본으로 복사합니다. 이 스테이지가 실패하면 사이클이 종료되고 더 이상 데이터가 복제되지 않습니다. 성공적으로 완료되면 소스 테이블의 전체 데이터 세트를 대상 테이블에서 사용할 수 있습니다.

3. 증분 로딩: 커넥터는 계속해서 원본 테이블의 변경 내용을 추적하고 대상 테이블에 복사합니다. 테이블이 복제에서 제거될 때까지 이 과정이 계속됩니다. 이 스테이지에서 실패하면 문제가 제거될 때까지 소스 테이블의 복제가 영구적으로 중지됩니다.

   참고

   이 커넥터는 스냅샷 로드 단계를 우회하여 새로 추가된 테이블에 대한 증분 변경 사항 복제를 즉시 시작하도록 구성할 수 있습니다. 이 옵션은 이전에 복제된 데이터가 있는 계정에 커넥터를 다시 설치하며 테이블 스냅샷을 다시 생성하지 않고 복제를 계속하려는 경우에 유용한 경우가 많습니다.

   스냅샷 로드 우회 및 증분 로드 프로세스 사용에 대한 자세한 내용은 :doc:`증분 복제<incremental-replication>`를 참조하세요.

TOASTed 값 지원¶

커넥터는 array, bytea, json, jsonb, text, varchar, xml 유형의 열에 대해 `TOAST 값<https://www.postgresql.org/docs/current/storage-toast.html>`_을 사용한 테이블 복제를 지원합니다.

커넥터가 CDC 스트림에서 TOASTed 값을 발견할 때마다 지정된 열 유형에 대해 형식이 지정된 기본 자리 표시자인 __previous_value_unchanged``로 대체하고 를 저널 테이블에 저장합니다. 그런 후 ``MERGE 쿼리는 자리 표시자 값을 설명하므로 대상 테이블에는 항상 TOASTed가 아닌 마지막 값이 포함됩니다.

범위를 벗어난 값 지원¶

커넥터는 범위를 벗어난 값을 포함하는 date, timestamp 및 timestamptz 유형의 열이 있는 테이블의 복제를 지원합니다. 커넥터가 CDC 스트림에서 범위를 벗어난 값을 발견하면 열 유형에 따라 기본 자리 표시자를 대체합니다.

테이블 복제 상태¶

연결 오류와 같은 임시 오류가 발생해도 테이블 복제가 멈추지 않습니다. 그러나 지원되지 않는 데이터 타입과 같은 영구적인 오류가 발생하면 테이블 복제가 이루어지지 않습니다.

복제 문제를 해결하거나 복제 흐름에서 테이블이 성공적으로 제거되었는지 확인하려면 테이블 상태 저장소를 확인합니다.

1. Openflow 런타임 캔버스에서 프로세서 그룹을 마우스 오른쪽 버튼으로 클릭하고 :ui:`Controller Services`를 선택합니다. 컨트롤러 서비스 목록을 보여주는 테이블이 표시됩니다.

2. Table State Store 레이블이 지정된 행을 찾아 행의 오른쪽에 있는 More 버튼을 클릭한 다음 :ui:`View State`를 선택합니다.

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

• NEW: 테이블 복제가 예약되었지만 복제가 시작되지 않았습니다.

• SNAPSHOT_REPLICATION: 커넥터가 기존 데이터를 복사하고 있습니다. 이 상태는 모든 레코드가 대상 테이블에 저장될 때까지 표시됩니다.

• INCREMENTAL_REPLICATION: 커넥터가 변경 사항을 적극적으로 복제하고 있습니다. 이 상태는 스냅샷 복제가 끝난 후에 표시되며 테이블이 복제에서 제거되거나 복제가 실패할 때까지 무기한으로 계속 표시됩니다.

• FAILED: 오류로 인해 복제가 영구적으로 중지되었습니다.

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

영구적인 오류로 인해 테이블 복제가 불가능한 경우 복제에서 테이블을 제거합니다. 실패의 원인이 된 문제를 해결한 후에는 테이블을 복제에 다시 추가할 수 있습니다. 자세한 내용은 :ref:`테이블 복제 다시 시작 <label-of_postgres_restart_table_replication>`을 참조하세요.

대상 테이블 메타데이터 열¶

각 대상 테이블에는 복제 정보를 추적하는 다음 메타데이터 열이 포함됩니다.

일시 삭제된 행¶

소스 테이블에서 행이 삭제될 때 커넥터는 대상 테이블에서 해당 행을 물리적으로 제거하지 않습니다. 대신 _SNOWFLAKE_DELETED 메타데이터를 ``true``로 설정하여 행이 삭제된 것으로 표시됩니다.

이러한 접근 방식을 통해 다음을 수행할 수 있습니다.

• 감사 또는 규정 준수 목적으로 과거 데이터를 보존합니다.

• 필요할 때 삭제된 레코드를 쿼리합니다.

• 요구 사항에 따라 데이터를 영구적으로 제거하는 시기와 방법을 결정합니다.

활성(삭제되지 않은) 행만 쿼리하려면 _SNOWFLAKE_DELETED 열에서 필터링합니다.

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = FALSE;

삭제된 행을 쿼리하려면 다음을 수행합니다.

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = TRUE;

삭제된 열¶

소스 테이블에서 열이 삭제될 때 커넥터는 대상 테이블에서 해당 열을 삭제하지 않습니다. 대신 과거 값을 보존하기 위해 __SNOWFLAKE_DELETED 접미사를 추가하여 열의 이름이 변경됩니다.

예를 들어, ``EMAIL``이라는 열이 소스 테이블에서 삭제되면 대상 테이블의 이름이 ``EMAIL__SNOWFLAKE_DELETED``로 변경됩니다. 열이 삭제되기 전에 존재했던 행은 원래 값을 유지하는 반면, 삭제 후에 추가된 행은 이 열에 ``NULL``이 있습니다.

이름이 변경된 열에서 과거 값을 계속 쿼리할 수 있습니다.

SELECT EMAIL__SNOWFLAKE_DELETED FROM my_table;

이름이 변경된 열¶

변경 데이터 캡처(CDC) 메커니즘의 제한 사항으로 인해 커넥터는 이름이 변경된 열과 삭제된 후 추가된 새 열을 구분할 수 없습니다. 결과적으로, 소스 테이블에서 열의 이름을 변경하는 경우 커넥터는 이를 두 개의 별개 작업(원래 열 삭제 및 새 이름으로 새 열 추가)으로 처리합니다.

예를 들어, 소스 테이블에서 열의 이름을 ``A``에서 ``B``로 변경하는 경우 대상 테이블에는 다음이 포함됩니다.

• A__SNOWFLAKE_DELETED: 이름 변경 전의 값을 포함합니다. 이름 변경 후에 추가된 행은 이 열에 ``NULL``이 있습니다.

• B: 이름 변경 이후의 값을 포함합니다. 이름 변경 전에 존재했던 행은 이 열에 ``NULL``이 있습니다.

SELECT
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

SELECT
    CASE
        WHEN B IS NOT NULL THEN B
        ELSE A__SNOWFLAKE_DELETED
    END AS A_RENAMED_TO_B
FROM my_table;

CREATE VIEW my_table_unified AS
SELECT
    *,
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

저널 테이블¶

증분 복제 중에 소스 데이터베이스의 변경 사항은 대상 테이블에 병합되기 전에 먼저 저널 테이블에 기록됩니다. 이러한 데이터는 감사, 디버깅 또는 재처리 목적으로 유용할 수 있으므로 커넥터는 저널 테이블에서 데이터를 자동으로 제거하지 않습니다.

저널 테이블은 해당 대상 테이블과 동일한 스키마에 생성되며 다음 명명 규칙을 따릅니다.

<TABLE_NAME>_JOURNAL_<timestamp>_<number>

여기서

• ``<TABLE_NAME>``은 대상 테이블의 이름입니다.

• ``<timestamp>``는 Unix epoch 형식의 생성 타임스탬프(1970년 1월 1일 이후의 초)로, 고유성을 보장합니다.

• ``<number>``는 1에서 시작하며 소스 테이블의 스키마 변경 또는 열 필터의 수정으로 인해 대상 테이블 스키마가 변경될 때마다 증가합니다.

예를 들어 대상 테이블이 ``SALES.ORDERS``인 경우 저널 테이블의 이름은 ``SALES.ORDERS_JOURNAL_1705320000_1``일 수 있습니다.