Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Comprensione dei record CDC

Aurora DSQL CDC fornisce ogni modifica come record JSON. Il record utilizza una struttura a busta con tipo di operazione, immagini di riga prima e dopo e metadati di origine.

In che modo i record vengono mappati su Amazon Kinesis

Aurora DSQL scrive ogni record CDC come un singolo record Kinesis. Il Data campo del record Kinesis contiene il payload JSON. Aurora DSQL utilizza una chiave di partizione Kinesis randomizzata per distribuire i record CDC in modo uniforme tra gli shard. Per leggere tutte le modifiche, utilizza tutti gli shard del flusso di dati Kinesis. Se un record supera il limite di dimensione dei record Kinesis, Aurora DSQL lo divide tra più record Kinesis. Per informazioni dettagliate, vedi Gestione di record di grandi dimensioni.

Chiave primaria nel payload

Per le tabelle con una chiave primaria, i valori della colonna della chiave primaria vengono visualizzati nel payload:

Ad esempio, considera una tabella con una chiave primaria composita:

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

Un'eliminazione su questa tabella produce un payload dove"before": {"order_id": 1001, "item_id": 42}.

Registra il payload

Il payload utilizza il seguente formato di busta JSON.

Esempio INSERT

L'esempio seguente mostra un record CDC per un'INSERToperazione:

{
    "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
}

Esempio UPDATE

L'esempio seguente mostra un record CDC per un'UPDATEoperazione:

{
    "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
}

Esempio DELETE

Per a DELETE su una tabella con una chiave primaria, il before campo contiene i valori della chiave primaria:

{
    "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
}

Campi del payload

Dettagli sul formato

I seguenti dettagli descrivono come Aurora DSQL CDC formatta i record. Progetta la tua app per gestire questi comportamenti.

Write-set compattazione

Aurora DSQL compatta il set di scrittura di ogni transazione confermata prima di pubblicare i record CDC. Aurora DSQL confronta lo stato di ogni riga prima della transazione con quello successivo ed emette al massimo un record per riga che riflette l'effetto netto.

Regole di compattazione

Aurora DSQL determina il op codice in base alla modifica dello stato di rete della riga:

Gestione di record di grandi dimensioni

Quando il codice JSON serializzato di un record CDC supera i 9 MiB, Aurora DSQL before and/or after divide le immagini, fornendo più record Kinesis. Ogni record contiene un type campo di primo livello che ne indica la struttura: full per un record completo, per un record principale che fa riferimento ai frammenti e chunked per una singola parte di un'immagine suddivisa in blocchi. fragment I ts_ns campiop, sourcets_ms, e di un record principale suddiviso in blocchi si comportano come in un record completo. I record che rientrano in un singolo record Kinesis sono type impostati full e non richiedono alcuna gestione aggiuntiva.

A chunk_id è stabile tra i tentativi. Se Aurora DSQL riconsegna nuovamente un frammento, ha lo stesso chunk_id contenuto della distribuzione originale, in modo che l'app possa continuare a memorizzare nel buffer con lo stesso identificatore senza gestire set parziali dei tentativi precedenti.

Record principale

Un record principale suddiviso in blocchi sostituisce il livello before o il after campo superiore dell'immagine divisa con un chunked oggetto che descrive come riassemblarla. Ogni voce sottostante chunked ha un chunk_id (l'identificatore che collega i frammenti a questo record), total_fragments (il numero di frammenti che compongono quell'immagine) e crc32c (un checksum CRC32C, come stringa decimale, sul testo dell'immagine riassemblato). Se un'immagine è in linea e l'altra è suddivisa in blocchi, l'immagine in linea viene comunque visualizzata al livello superiore come valore o. 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
}

Record di frammenti

Ogni frammento è il proprio record Kinesis type con set fragment to e tre campichunk_id: corrisponde al valore nel record chunked.before.chunk_id corrispondente chunked.after.chunk_id o nel record principaleindex, è la posizione in base zero del frammento all'interno dell'immagine data ed è un segmento del testo JSON dell'immagine suddiviso UTF-8 sui limiti dei caratteri (il valore di ogni frammento data è una stringa valida a sé stante). UTF-8 Poiché Aurora DSQL CDC utilizza la UNORDERED modalità e le chiavi di partizione randomizzate, i frammenti e il record principale possono arrivare su diversi shard e in qualsiasi ordine. Per leggere tutti i frammenti, utilizza tutti gli shard del flusso di dati Kinesis. Per ulteriori informazioni sugli ordini con consegna, consulta. Ordinazione

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

Per riassemblare un'immagine sovradimensionata, inserite nel buffer ogni record con il relativo. type fragment chunk_id Quando ricevete un record principale con typechunked, attendete di avere total_fragments frammenti per ogni chunk_id riferimento sotto chunked.before ochunked.after, ordinate i frammenti in ordine crescente e concatenate le stringhe. index data Il risultato concatenato è l'originale before o after l'oggetto come testo JSON: analizzatelo per accedere ai valori delle colonne. Per verificare l'integrità della consegna, calcola CRC32C sulla stringa concatenata e confronta il risultato con o. chunked.before.crc32c chunked.after.crc32c

Serializzazione del tipo di dati

Le tabelle seguenti descrivono come Aurora DSQL serializza ogni tipo di dati PostgreSQL nei record CDC.

Tipi Integer

I valori bigint superiori a ±2^53 potrebbero perdere la precisione negli ambienti. JavaScript In questi casi, utilizzate BigInt librerie a precisione arbitraria.

Floating-point tipi

Booleano

Tipi di carattere

Binario

Tipi di data e ora

Altri tipi

Valori NULL

Per qualsiasi tipo di dati, i valori NULL delle colonne sono rappresentati come null JSON.

Evoluzione dello schema nei record CDC

Quando si modifica lo schema di una tabella, ad esempio aggiungendo, eliminando o rinominando una colonna, i record CDC riflettono la modifica a partire dalla transazione che ha eseguito la modifica DDL. I record delle transazioni eseguite prima della modifica DDL utilizzano lo schema precedente. Ad esempio:

Tieni traccia delle modifiche allo schema nel tuo consumatore a valle esaminando i nomi delle colonne presenti in ogni record e campo. after before Il source.version campo in ogni record identifica il formato della busta CDC.