CDC 레코드 이해

Aurora DSQL CDC는 각 변경 사항을 JSON 레코드로 전달합니다. 레코드는 작업 유형, 행 이미지 전후 및 소스 메타데이터가 있는 봉투 구조를 사용합니다.

레코드가 Amazon Kinesis에 매핑되는 방법

Aurora DSQL은 각 CDC 레코드를 단일 Kinesis 레코드로 기록합니다. Kinesis 레코드의 Data 필드에는 JSON 페이로드가 포함됩니다. Aurora DSQL은 무작위 Kinesis 파티션 키를 사용하여 CDC 레코드를 샤드에 균등하게 분산합니다. 모든 변경 사항을 읽으려면 Kinesis 데이터 스트림의 모든 샤드를 사용합니다. 레코드가 Kinesis 레코드 크기 제한을 초과하면 Aurora DSQL은 이를 여러 Kinesis 레코드로 분할합니다. 자세한 내용은 크기 초과 레코드 처리을 참조하세요.

페이로드의 프라이머리 키

프라이머리 키가 있는 테이블의 경우 프라이머리 키 열 값이 페이로드에 나타납니다.

복합 프라이머리 키가 하나만 있는 테이블을 예로 들어 보겠습니다.

CREATE TABLE order_items (
    order_id INT,
    item_id INT,
    quantity INT,
    price NUMERIC,
    PRIMARY KEY (order_id, item_id)
);

이 테이블에서 삭제하면 "before": {"order_id": 1001, "item_id": 42}인 페이로드가 생성됩니다.

레코드 페이로드

페이로드는 다음 JSON 봉투 형식을 사용합니다.

INSERT 예

다음 예제에서는 삽입 작업에 대한 CDC 레코드를 보여줍니다.

{
    "type": "full",
    "op": "c",
    "before": null,
    "after": {"order_id": 1001, "item_id": 42, "quantity": 5, "price": "29.99"},
    "source": {
        "version": "1.0",
        "ts_ms": 1705318200000,
        "ts_ns": 1705318200000000000,
        "txId": "ffthunp5stx6ffs2vyfqoatmfu",
        "schema": "public",
        "table": "order_items",
        "db": "postgres",
        "cluster": "kmabugltfmjdaj2siqr2qbxgju"
    },
    "ts_ms": 1705318200125,
    "ts_ns": 1705318200125483291
}

UPDATE 예제

다음 예제는 Aurora DSQL이 op: "u"를 내보내기 시작한 후 UPDATE 문에서 생성된 CDC 레코드가 어떻게 보이는지 보여줍니다.

{
    "type": "full",
    "op": "u",
    "before": null,
    "after": {"order_id": 1001, "item_id": 42, "quantity": 10, "price": "29.99"},
    "source": {
        "version": "1.0",
        "ts_ms": 1705318300000,
        "ts_ns": 1705318300000000000,
        "txId": "qvtiesgmd55cvlfukm3dfuotji",
        "schema": "public",
        "table": "order_items",
        "db": "postgres",
        "cluster": "kmabugltfmjdaj2siqr2qbxgju"
    },
    "ts_ms": 1705318300125,
    "ts_ns": 1705318300125483291
}

DELETE 예제

프라이머리 키가 있는 테이블에 대한 삭제의 경우 before 필드에는 삭제된 행의 프라이머리 키 값이 포함됩니다.

{
    "type": "full",
    "op": "d",
    "before": {"order_id": 1001, "item_id": 42},
    "after": null,
    "source": {
        "version": "1.0",
        "ts_ms": 1705318400000,
        "ts_ns": 1705318400000000000,
        "txId": "xyzabc123def456ghi789jklmno",
        "schema": "public",
        "table": "order_items",
        "db": "postgres",
        "cluster": "kmabugltfmjdaj2siqr2qbxgju"
    },
    "ts_ms": 1705318400125,
    "ts_ns": 1705318400125483291
}

페이로드 필드

형식 세부 정보

다음 세부 정보는 Aurora DSQL CDC가 레코드의 형식을 지정하는 방법을 설명합니다. 이러한 동작을 처리하도록 앱을 설계합니다.

크기 초과 레코드 처리

CDC 레코드의 직렬화된 JSON이 9MiB를 초과하면 Aurora DSQL은 before 및/또는 after 이미지를 분할하여 여러 Kinesis 레코드를 전송합니다. 각 레코드에는 전체 레코드의 경우 full, 조각을 참조하는 기본 레코드의 경우 chunked, 청크 이미지의 개별 조각의 경우 fragment 등 구조를 나타내는 최상위 type 필드가 포함되어 있습니다. 청크된 기본 레코드의 op, source, ts_ms 및 ts_ns 필드는 전체 레코드와 동일하게 작동합니다. 단일 Kinesis 레코드에 맞는 레코드는 type이 full로 설정되며 추가 처리가 필요하지 않습니다.

chunk_id는 재시도 시 안정적입니다. Aurora DSQL이 조각을 재전송하는 경우 조각은 원래 전송과 동일한 chunk_id를 전달하므로 앱은 이전 시도의 부분 세트를 처리하지 않고도 동일한 식별자로 버퍼링을 계속할 수 있습니다.

기본 레코드

청크된 기본 레코드는 분할 이미지의 최상위 before 또는 after 필드를 재조립 방법을 설명하는 chunked 객체로 대체합니다. chunked의 각 항목에는 chunk_id(이 레코드에 조각을 연결하는 식별자), total_fragments(해당 이미지를 구성하는 조각 수) 및 crc32c(재조립된 이미지 텍스트 위에 10진수 문자열로 CRC32C 체크섬)가 있습니다. 한 이미지가 인라인이고 다른 이미지가 청크된 경우에도 인라인 이미지는 최상위 수준에 값 또는 null로 표시됩니다.

{
    "type": "chunked",
    "op": "c",
    "before": null,
    "after": null,
    "source": {
        "version": "1.0",
        "ts_ms": 1705318200000,
        "ts_ns": 1705318200000000000,
        "txId": "ffthunp5stx6ffs2vyfqoatmfu",
        "schema": "public",
        "table": "order_items",
        "db": "postgres",
        "cluster": "cluster-id"
    },
    "chunked": {
        "after": {
            "chunk_id": "chunk-id",
            "total_fragments": 3,
            "crc32c": "2073618257"
        }
    },
    "ts_ms": 1705318200125,
    "ts_ns": 1705318200125483291
}

조각 레코드

각 조각은 type이 fragment로 설정되고 다음 세 개의 필드가 있는 자체 Kinesis 레코드입니다. chunk_id는 기본 레코드에 있는 해당 chunked.before.chunk_id 또는 chunked.after.chunk_id의 값과 일치하고, index는 이미지 내 조각의 0 기반 위치이며, data는 UTF-8 문자 경계에 분할된 이미지 JSON 텍스트의 세그먼트입니다(각 조각의 data 값은 자체적으로 유효한 UTF-8 문자열임). Aurora DSQL CDC는 UNORDERED 모드 및 무작위 파티션 키를 사용하기 때문에 조각과 기본 레코드는 어떤 순서로든 서로 다른 샤드에 도착할 수 있습니다. 모든 조각을 읽으려면 Kinesis 데이터 스트림의 모든 샤드를 사용합니다. 전송 순서 지정에 대한 자세한 내용은 순서 지정 섹션을 참조하세요.

{
    "type": "fragment",
    "chunk_id": "chunk-id",
    "index": 0,
    "data": "partial-JSON-text"
}

크기 초과 이미지를 재조립하려면 각 레코드를 chunk_id별로 type fragment로 버퍼링합니다. type chunked로 기본 레코드를 받으면 chunked.before 또는 chunked.after에서 참조되는 각 chunk_id에 대한 total_fragments 조각이 있을 때까지 기다렸다가 index 오름차순으로 조각을 정렬하고 data 문자열을 연결합니다. 연결된 결과는 원본 before 또는 after 객체를 JSON 텍스트로 구문 분석하여 열 값에 액세스합니다. 전송 무결성을 확인하려면 연결된 문자열을 통해 CRC32C를 계산하고 결과를 chunked.before.crc32c 또는 chunked.after.crc32c와 비교합니다.

데이터 유형 직렬화

다음 표에서는 Aurora DSQL이 CDC 레코드의 각 PostgreSQL 데이터 형식을 직렬화하는 방법을 설명합니다.

정수 형식

bigint 값이 ±2^53을 초과하면 JavaScript 환경에서 정밀도가 떨어질 수 있습니다. 이러한 경우 BigInt 또는 임의 정밀도 라이브러리를 사용합니다.

부동 소수점 형식

부울

문자 형식

바이너리

날짜 및 시간 형식

기타 유형

Null 값

모든 데이터 유형의 경우 NULL 열 값은 JSON null로 표시됩니다.

CDC 레코드의 스키마 진화

열 추가, 삭제 또는 이름 변경과 같이 테이블의 스키마를 수정하는 경우 CDC 레코드는 DDL 변경을 커밋한 트랜잭션부터 시작하여 변경 사항을 반영합니다. DDL 변경 전에 커밋된 트랜잭션의 레코드는 이전 스키마를 사용합니다. 예제:

각 레코드의 after 및 before 필드에 있는 열 이름을 검사하여 다운스트림 소비자의 스키마 변경 사항을 추적합니다. 각 레코드의 source.version 필드는 CDC 봉투 형식을 식별합니다.