DDL 및 스키마 전개 처리

예상 순서

테이블 정의가 변경되고 DDL 캡처가 활성화되면 스트림은 새 정의를 사용하는 후속 레코드보다 먼저 DDL 레코드를 전달한 다음 객체 메타 데이터 및 테이블 특정 DML 스키마를 갱신할 수 있습니다. WebSocket 메시지의 정확한 일괄 처리 및 순서는 구현 세부 정보입니다. 소비자는 스키마 또는 메타 데이터 레코드가 나타날 때마다 처리해야 합니다.

• 테이블 이름뿐만 아니라 id를 기준으로 스키마를 캐시에 저장합니다.

• 객체 메타데이터를 qual_table로 캐시에 저장하고 최신 레코드가 도착하면 바꿉니다.

• 연결 시 수신된 스키마가 연결 수명 동안 유효하다고 가정하지 마십시오.

• 필요한 스키마를 알 수 없고 다운스트림 시스템에서 스키마 없는 데이터를 받아들일 수 없는 경우 DML 레코드를 일시 정지하거나 소진합니다.

• 정책이 허용하는 경우 호환되는 변경 사항을 자동으로 적용합니다. 호환되지 않는 변경 사항을 제어되는 마이그레이션 워크플로우로 경로 지정합니다.

호환 및 호환되지 않는 변경 사항

변경	일반 소비자 작업
널 가능 열 추가	새 필드를 수락하고 다운스트림 스키마를 비동기 또는 동적으로 업데이트합니다.
널이 아닌 열 추가	레코드를 적용하기 전에 기본/백필 동작을 확인합니다.
열 삭제	필드 쓰기를 중지하고 보존 정책에 따라 과거 다운스트림 데이터를 보존합니다.
열 이름 바꾸기	관리되는 매핑 상태가 아닌 경우 드롭 플러스 추가로 처리합니다.
JSON 기본 데이터 유형 또는 소스 소수점 이하 자릿수 변경	계속하기 전에 변환, 정밀도 및 다운스트림 호환성을 검증합니다.
키 열 변경	새 키에서 레코드를 소비하기 전에 idempotency, 병합 및 삭제 논리를 재구축합니다.

DDL 처리 정책

• 감사 로그에 DDL pos, 객체 ID, 명령문 및 작업 시간 기록을 기록합니다.

• 해당 동작이 명시적으로 승인되고 보안되지 않는 한 다운스트림 시스템에 대해 검토되지 않은 소스 DDL을 직접 실행하지 마십시오.

• 조직의 DDL에 맞게 충분히 큰 maxDDLTextSize를 사용하고 잘림이 감지되거나 의심될 때 경보를 보냅니다.

• 시간에 따라 동일한 테이블에 대해 여러 스키마 버전이 필요합니다. 아카이브된 이벤트로 스키마 식별자를 유지합니다.

스키마 레지스트리 통합

소비자는 인밴드 JSON 스키마 레코드를 엔터프라이즈 스키마 레지스트리에 게시할 수 있습니다. 과거 스키마 정의를 겹쳐쓰지 않고 원래 id를 보존하고, 데이터 스트림 및 배포와 연계하고, 버전을 변경합니다. 레지스트리는 런타임 스키마를 보완하며 체크포인트 또는 소스-트레일 복구를 대체하지 않습니다.