체크포인트, 복구 및 전달 의미
데이터 스트림 구성에서 체크포인트, 복구 및 전달에 대해 알아봅니다.
pos 공공 계약
모든 비메타 데이터 DML 또는 DDL 레코드에는 기본적으로 불투명한 pos 토큰이 포함됩니다. 내부적으로 토큰은 커밋 또는 시퀀스 정보, 트랜잭션 ID 및 레코드 순서 지정을 포함하여 레코드를 식별할 수 있는 충분한 GoldenGate 위치 지정 정보를 전달합니다. 인코딩은 공용 소스 좌표 형식이 아니며 소스 유형 및 릴리스에 따라 다를 수 있습니다.
| 수행 | 하지 않음 |
|---|---|
| 처리 성공 후 정확한 문자열을 저장합니다. | 이를 구문 분석하여 Oracle SCN, PostgreSQL LSN, MySQL binlog 좌표, SQL Server LSN 또는 기타 소스별 오프셋을 얻습니다. |
| 이를 데이터 스트림, 소스 추적 계약 및 소비자로 범위 지정합니다. | 렉시칼 또는 숫자로 위치를 비교하여 순서를 결정합니다. |
URL에서 begin로 사용될 때 퍼센트 인코딩입니다. |
트림, 정규화, 연결, 해독 또는 재작성합니다. |
진단 또는 트랜잭션 분석을 위해 별도의 csn, xid, opSeqno 및 transInd 필드를 사용합니다. |
다른 스트림, 다른 필터 계약 또는 다른 환경의 위치를 재사용합니다. |
소스 이식성: 클라이언트 복구 알고리즘은 Oracle, PostgreSQL, MySQL, SQL Server 및 기타 지원되는 소스에 대해 의도적으로 동일합니다. 즉, 불투명한 pos를 유지하고 변경되지 않은 상태로 반환합니다. 데이터 스트림 클라이언트 계약에서는 소스별 좌표 구문 분석이 필요하거나 지원되지 않습니다.
체크포인트는 업무 효과가 지속 가능한 마지막 레코드를 나타내야 합니다. 비즈니스 쓰기 전에 저장하면 충돌 후 데이터가 손실될 수 있습니다. 별도의 트랜잭션에 비 멱등 쓰기 작업을 수행한 후에 저장하면 충돌 후 중복이 발생할 수 있습니다.
종단간 정확히 한 번 패턴
| 패턴 | 작동 방식 | 사용 시기 |
|---|---|---|
| 원자 싱크 및 체크포인트 트랜잭션 | 동일한 데이터베이스 트랜잭션에 업무 레코드와 새 pos를 기록합니다. |
싱크대와 체크포인트는 트랜잭션 데이터 저장소를 공유할 수 있습니다. |
| Idempotency 키 | pos 또는 비즈니스 키 + 운영 ID를 고유 키로 사용합니다. 동일한 레코드를 재시도하면 no-op이 됩니다. |
싱크는 고유성 또는 조건부 쓰기를 지원합니다. |
| 지속 스테이징 로그 | 레코드와 pos를 영구 로그에 원자적으로 추가한 다음 로그를 독립적으로 처리합니다. |
비즈니스 프로세싱은 느리거나 다단계이거나 여러 시스템에 걸쳐 있습니다. |
| 조정 시 최소 1회 | 중복을 수락하고, 주기적으로 중복을 제거하고, 개수 또는 체크섬을 조정합니다. | 사용 사례는 최종 수정을 허용합니다. |
참고: 데이터 스트림 exactlyOnce에서는 서비스측 중복 숨김 및 복구 응답에 대해 설명합니다. WebSocket 프로토콜에는 클라이언트와의 레코드별 트랜잭션 승인이 없기 때문에 임의의 다운스트림 부작용은 정확히 한 번만 발생하지 않습니다.
서비스 품질
다음 표에서 서비스 품질 지침을 참조하십시오.
| 모드 | 중복 | 저장된 직책을 사용할 수 없음 | 권장 사용 |
|---|---|---|---|
exactlyOnce |
복구 및 소스 트레일 재시작/절단 처리 중 인식된 중복을 억제합니다. | 오류로 인해 연결이 실패합니다. | 지속적 비즈니스 처리에 대한 기본값입니다. 원자 또는 멱등 소비자 로직과 쌍을 이룹니다. |
atLeastOnce |
복구 및 소스 추적 재시작/절단 처리 중 중복을 방지하지 않습니다. | 오류로 인해 연결이 실패합니다. | 리플레이가 선호되고 소비자가 복제 취소되도록 설계된 경우에 사용합니다. |
atMostOnce |
인식된 중복을 억제합니다. | 서비스는 사용 가능한 다음 레코드를 찾아 계속하여 데이터를 건너뛸 수 있습니다. | 데이터 손실이 명시적으로 허용되고 순방향 진행이 완전성보다 중요한 경우에만 사용합니다. |
트랜잭션 메타데이터 및 주문
트랜잭션 메타데이터 및 주문 요구 사항은 다음 표를 참조하십시오.
| 필드 | 목적 | 제한 사항 |
|---|---|---|
xid |
출처 트랜잭션과 연계된 레코드를 그룹화합니다. | 형식은 소스에 따라 다르며 문자열로 처리되어야 합니다. |
csn |
구성된 경우 출처 커밋 순번을 노출합니다. | 의미와 형식은 소스에 따라 다르므로 다시 시작 토큰으로 사용하지 마십시오. |
opSeqno |
트랜잭션 내의 레코드 순번입니다. | 명시적으로 활성화하고 선택적으로 이름을 바꿉니다. |
transInd |
B 먼저, M 중간, E 마지막 또는 W 전체/단일 작업 트랜잭션. |
필터링하면 레코드가 제거되고 관찰된 시퀀스가 불완전해질 수 있습니다. 조정된 프로세싱은 유용성을 줄일 수도 있습니다. |
pos |
레코드에 대한 고유 복구 포지션입니다. | 불투명: 해당 텍스트에서 트랜잭션 경계를 정렬하거나 파생하지 않습니다. |
연결이 항상 트랜잭션 경계에서 시작한다고 가정하지 마십시오. 이전 작업을 더 이상 사용할 수 없으면 타임스탬프 조회 또는 트레일 유지 경계를 시작할 수 있습니다. 응용 프로그램에 전체 소스 트랜잭션이 필요한 경우 트랜잭션 버퍼를 설계하고, 대용량 트랜잭션에 대한 제한을 정의하고, 트랜잭션 시작을 사용할 수 없을 때 수행할 작업을 지정합니다.
저장된 포지션을 사용할 수 없는 경우
사용할 수 없게 되는 저장된 위치를 확인하려면 다음을 확인합니다.
-
체크포인트가 동일한 데이터 스트림, 소스 추적 및 필터/출력 계약에 속하는지 확인합니다.
-
값을 변경하지 않고 값이 퍼센트 인코딩되었는지 확인하십시오.
-
위치를 포함하는 트레일 세그먼트가 지워지지 않았는지 확인합니다.
-
exactlyOnce또는atLeastOnce를 사용할 경우 오류를 복구 장애로 처리합니다. 추적 내역을 복원하고, 승인된 타임스탬프 또는 가장 이른 위치를 선택하고, 재개하기 전에 다운스트림 상태를 조정합니다. -
atMostOnce를 사용하면 다음 사용 가능한 레코드에서 서비스를 계속할 수 있습니다. 결과 데이터 격차를 기록하고 비즈니스 승인 조정 프로시저를 실행합니다.
추적 보존 계획
추적 보존을 복구 지점 목표와 운영 감지 및 응답 시간을 초과하도록 설정합니다. 예를 들어, 24시간 동안 오프라인 상태일 수 있고 장애 응답에 12시간이 필요한 소비자는 36시간 이상의 사용 가능한 추적이 필요하며, 대규모 백로그 및 유지 관리에 대한 추가 마진이 있습니다. bufferSize는 추적 보존 기간을 연장하지 않습니다.