Openflow Connector for SQL Server 정보¶

데이터 복제¶

커넥터는 단일 SQL Server 인스턴스의 여러 SQL Server 데이터베이스에서 테이블 복제를 지원합니다. 커넥터는 대상 Snowflake 데이터베이스의 별도 스키마에 있는 다른 데이터베이스에서 복제된 테이블을 생성합니다.

소스 데이터베이스 이름, 소스 스키마 이름, 테이블 이름을 다음 형식으로 결합하여 복제된 테이블을 참조합니다.

<database_name>.<schema_name>.<table_name>

복제되는 각 소스 데이터베이스의 각 스키마에 대해 커넥터는 대상 Snowflake 데이터베이스에 별도의 스키마를 생성합니다. 대상 스키마의 이름은 소스 데이터베이스 이름과 소스 스키마 이름의 조합으로, 다음 예제와 같이 밑줄 문자(_)로 구분됩니다.

<source_database_name>_<source_schema_name>

커넥터는 다음 예제와 같이 소스 테이블 이름과 동일한 이름으로 대상 스키마에 테이블을 생성합니다.

<destination_database>_<destination_schema_name>.<source_table_name>

테이블이 복제되는 방법¶

커넥터는 다음 스테이지에서 테이블을 복제합니다.

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

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

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

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

테이블 복제 상태¶

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

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

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_sql_server_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``일 수 있습니다.