MySQL용 Openflow 커넥터: 유지 관리

이 문서에서는 MySQL용 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.5.14.16 이상과 커넥터 버전 0.49.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이 됩니다.
- 경고: 제거 전에 캡처된 변경 이벤트가 여전히 큐에 있는 동안 테이블을 다시 추가하지 마세요. 테이블을 다시 추가하면 커넥터가 추가 전용(append-only) 모드로 새 스냅샷을 로드하므로, 재스냅샷 후 테이블에 병합되는 남은 변경 이벤트가 목적지 테이블에 중복 행을 만들 수 있습니다.
첫 단계에서 한 변경을 되돌려 테이블을 다시 추가하세요. 즉 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_MYSQL_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_MYSQL_SSV2 파라미터 값은 쿼리로 확인하지 못할 수 있습니다. 활성화되었는지 확인하려면 FlowFiles가 'Upload Rows via Snowpipe Streaming 2' 프로세서를 통해 흐르는지('Upload Rows via Snowpipe Streaming'이 아닌) 확인하세요.

프로세서 구성

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

Fetch Table Rows(Snapshot Load 그룹)
Read MySQL 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로 차 백프레셔(back pressure)를 유발할 수 있으며, 이는 많은 런타임 디스크 공간을 소비합니다. 큰 테이블에서는 추가 스토리지를 제공하도록 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' 프로세서를 통해 파일을 파일별로 스트리밍하고 병합이 이를 점진적으로 처리하기 때문입니다.

증분 복제는 또한 MySQL 트랜잭션 크기 제한을 따릅니다. 단일 트랜잭션은 4 GB 이하의 바이너리 로그 메시지에 들어맞아야 합니다. 자세한 내용은 제한 사항 섹션을 참조하세요.

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

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

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

참고: 스키마 이름은 따옴표로 묶인 식별자(예: '"my_schema"')로 전달되어 커넥터가 만든 정확한 대소문자 구분 이름과 일치합니다. 커넥터가 목적지 스키마 이름을 지정하는 방식에 대한 자세한 내용은 'MySQL 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"');

저널 테이블 스토리지 회수

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

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

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

customers_1234_1
customers_1234_2
orders_5678_1
orders_5678_2

커넥터 재설치

이 섹션에서는 커넥터를 재설치하면서, 같은 테이블에 대해 다시 스냅샷하지 않고 데이터 복제를 계속하는 방법을 설명합니다. 새 커넥터가 같은 런타임에 설치되는 경우와 새 런타임으로 이동되는 경우를 모두 다룹니다.

경고: 커넥터가 재설치 전에 중단된 것과 같은 CDC 스트림 위치부터 계속 복제하려면, 소스 데이터베이스가 이전 커넥터가 중지된 시점부터 새 커넥터가 시작되는 시점까지의 시간을 커버할 만큼 오래 바이너리 로그를 보존해야 합니다. MySQL 서버의 binlog_expire_logs_seconds 파라미터가 충분히 높은지 확인하고 재설치 시간을 최소화하세요. binlog_expire_logs_seconds 값은 커넥터를 재설치하는 데 예상되는 시간보다 길어야 합니다. 일반적으로 86400초(하루의 초)면 충분하지만, 재설치에 시간이 걸리도록 더 긴 시간이 적절할 수 있습니다.

사전 준비 사항

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

기존 커넥터의 진행 중인 모든 FlowFile 처리를 마친 뒤 커넥터를 중지하세요.
- Snowsight에 로그인합니다.
- 내비게이션 메뉴에서 Ingestion » Openflow를 선택합니다.
- Launch Openflow를 선택합니다.
- Openflow 창에서 Runtimes 탭을 선택합니다.
- 커넥터가 포함된 런타임을 선택합니다.
- 커넥터를 선택합니다.
- Snapshot Load 그룹의 최상위 프로세서 Set Tables for Replication을 중지합니다.
- Incremental Load 그룹의 최상위 프로세서 Read MySQL CDC Stream을 중지합니다.
- Merge Task Schedule CRON 파라미터 값을 변경했다면 * * * * * ?로 되돌리세요. 그렇지 않으면 다음 예약 실행까지 큐가 비워지지 않습니다.
- 커넥터의 모든 FlowFile이 처리되고 모든 큐가 비워질 때까지 기다리세요. 모든 FlowFile이 처리되면 커넥터 프로세스 그룹의 Queued 값이 0이 됩니다. 원래 커넥터 큐에 항목이 남아 있으면 새 커넥터가 시작될 때 데이터 공백이 있을 수 있습니다.
- 커넥터의 모든 프로세서와 컨트롤러 서비스를 중지하세요.
- 주의: 기존 커넥터는 중지된 상태로 유지되는 한 런타임에 남아 있어도 새 인스턴스와 간섭하지 않습니다.
커넥터를 새 런타임으로 이동한다면, 처음부터 구성하는 대신 현재 상태로 커넥터를 재현할 수 있도록 기존 커넥터에서 플로우 정의를 다운로드하세요. 플로우 정의 다운로드에는 Openflow Runtime Server 버전 2026.6.4.18 이상이 필요합니다.
- 커넥터의 프로세스 그룹을 마우스 오른쪽 버튼으로 클릭한 뒤 Download flow definition을 선택하세요.
- 다음 두 옵션을 모두 선택한 뒤 플로우 정의를 다운로드하세요.
  - Export with External Services: 커넥터가 상위 프로세스 그룹에서 참조하는 컨트롤러 서비스를 포함.
  - Export with Components State: 바이너리 로그 위치와 증분 복제 상태 같은 구성 요소 상태를 포함해, 복제가 중단된 지점부터 계속되게 함.
대상 런타임에서 커넥터를 만드세요.
- 플로우 정의를 다운로드했다면 새 런타임으로 가져오세요. 플로우 정의를 가져오면 내보내기 중 캡처된 구성 요소 상태가 보존되어 커넥터가 이전 위치부터 증분 복제를 재개합니다.
- 그렇지 않으면 커넥터의 새 인스턴스를 만드세요. 원래 커넥터와 같은 런타임을 사용한다면 기존 파라미터 컨텍스트를 유지하고 설정을 재사용할 수 있습니다.
- 다른 런타임에 설치하거나 이전 파라미터 컨텍스트를 삭제했다면 'Set up the Openflow Connector for MySQL'에 설명된 테이블 이름과 패턴을 포함해 구성 설정을 새 파라미터 컨텍스트에 입력하세요. 다운로드한 플로우 정의는 비밀번호 같은 민감한 값을 포함하지 않으므로 다시 입력해야 합니다.
MySQL Ingestion Parameters 컨텍스트로 이동해 다음 파라미터를 설정하세요.
- Ingestion Type 파라미터를 incremental로 설정하세요. 우려 사항에 대한 자세한 내용은 'Enable incremental replication without snapshots'를 참조하세요.
- Starting Binlog Position 파라미터를 Earliest로 설정하세요. 자세한 내용과 잠재적 우려 사항은 'Specify load from binary log position'을 참조하세요.
- 참고: Export with Components State를 선택해 플로우 정의를 가져왔다면 커넥터는 이전 바이너리 로그 위치를 유지합니다. 이 경우 Starting Binlog Position을 Latest로 두고 중단된 지점부터 복제를 계속하세요.
새 커넥터를 시작하세요.

사용 메모

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

바이너리 로그 위치에서 로드 지정

MySQL용 Openflow 커넥터는 MySQL 바이너리 로그가 읽히는 시작 위치를 선택할 수 있게 해 줍니다. 기본적으로 커넥터는 최신 사용 가능 위치에서 읽습니다. 또는 소스 인스턴스에서 사용 가능한 가장 이른 위치를 선택할 수 있습니다. 가장 이른 위치에서 시작하는 것은 커넥터를 재설치할 때 흔합니다. 그러면 새 인스턴스가 다시 스냅샷하지 않고 기존 테이블 복제를 따라잡아 계속할 수 있습니다.

실행 중인 커넥터를 최신 위치에서 가장 이른 위치로 전환하면 전체 사용 가능 바이너리 로그가 다시 읽히고, 재처리되고, 목적지 테이블에 다시 적용됩니다.

경고: 바이너리 로그가 다시 읽히는 동안 모든 이벤트가 재처리·병합될 때까지 영향을 받는 목적지 테이블의 열과 데이터가 해당 소스와 동기화되지 않을 수 있습니다.

스냅샷 로드를 제어하는 다음 파라미터는 Ingestion Parameters 컨텍스트에서 사용할 수 있습니다.

파라미터	설명
Starting Binlog Position	Latest(기본): CDC 스트림 읽기가 최신 사용 가능 위치에서 시작해 계속됨. Earliest: 증분 로드가 가장 이른 사용 가능 바이너리 로그 위치에서 시작하거나 다시 읽기 시작하도록 전환
Re-read Tables in State	New(기본): 바이너리 로그를 다시 읽는 동안 재읽기 시작 후 복제에 추가된 새 테이블의 이벤트만 처리됨. 커넥터가 재읽기 시작 직전 위치에 도달할 때까지 다른 이벤트는 폐기됨. Any active: 현재 복제 중인 모든 테이블의 이벤트를 다시 읽고 재처리

커넥터가 바이너리 로그 재읽기를 끝냈는지 확인하려면:

Openflow 캔버스로 이동합니다.
Incremental Load 프로세스 그룹을 엽니다.
Read MySQL CDC Stream이라는 최상위 프로세서를 마우스 오른쪽 버튼으로 클릭한 뒤 View state를 선택합니다.
상태 항목을 비교합니다.
- binlog.position.rewind: 바이너리 로그 재읽기가 시작되기 전에 프로세서가 읽은 최신 위치.
- binlog.position.dml: 프로세서가 읽은 현재 최신 위치. 이 값이 위의 rewind 값보다 낮은 동안 프로세서는 여전히 바이너리 로그를 재읽는 중입니다.

참고: binlog.position.rewind에 /4가 표시되면 커넥터가 레지스트리에서 새로 설치되어 기록할 이전 상태가 없다는 뜻입니다. /4는 '가장 오래된 사용 가능 위치'를 의미하는 플레이스홀더 값이며, 이 경우 dml 대 rewind 비교로 진행 상황을 측정할 수 없습니다. 커넥터가 따라잡았는지 확인하려면 다음 확인 중 하나를 사용하세요.

행 수: 소스와 목적지 테이블 행 수를 비교.

바이너리 로그 위치: 소스에서 SHOW BINARY LOG STATUS(MySQL 8.2 이상) 또는 SHOW MASTER STATUS(MySQL 8.1 이하)를 실행해 현재 binlog 헤드를 얻은 뒤 binlog.position.dml과 비교. 간격이 작고 새 변경이 도착해도 낮게 유지되면 커넥터가 따라잡은 것입니다.

사용 메모

실행 중인 커넥터가 가장 이른 위치에서 읽도록 전환된 뒤 실행을 시작하면, 프로세스는 재구성되거나 취소될 수 없으며 현재 읽기 위치가 시작 전 위치에 도달할 때까지 계속됩니다.
실행 중인 커넥터에서 가장 이른 위치로 전환하면, 재처리되는 모든 테이블에 대해 기존 저널이 끝나고 새 저널 테이블이 만들어집니다.
바이너리 로그에 소스 데이터베이스에서 삭제 후 재생성된 이전 테이블의 이벤트가 포함되어 있다면, 스트림 재읽기는 현재 목적지의 모든 이벤트를 재처리합니다. 커넥터는 이름이 같으면 이전 소스 테이블과 현재 소스 테이블을 구분할 수 없습니다.

MySQL용 Openflow 커넥터: 유지 관리