Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comprendre les dossiers du CDC

Aurora DSQL CDC fournit chaque modification sous forme d'enregistrement JSON. L'enregistrement utilise une structure d'enveloppe avec le type d'opération, les images avant et après les lignes et les métadonnées de la source.

Comment les enregistrements sont mappés à Amazon Kinesis

Aurora DSQL écrit chaque enregistrement CDC sous la forme d'un enregistrement Kinesis unique. Le Data champ de l'enregistrement Kinesis contient la charge utile JSON. Aurora DSQL utilise une clé de partition Kinesis aléatoire pour répartir les enregistrements CDC de manière uniforme sur les partitions. Pour lire toutes les modifications, consommez toutes les partitions du flux de données Kinesis. Si un enregistrement dépasse la limite de taille d'enregistrement Kinesis, Aurora DSQL le divise en plusieurs enregistrements Kinesis. Pour en savoir plus, consultez Gestion de dossiers surdimensionnés.

Clé primaire dans la charge utile

Pour les tables dotées d'une clé primaire, les valeurs des colonnes de clé primaire apparaissent dans la charge utile :

Prenons l'exemple d'une table avec une clé primaire composite :

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

Une suppression sur cette table produit une charge utile où"before": {"order_id": 1001, "item_id": 42}.

Charge utile record

La charge utile utilise le format d'enveloppe JSON suivant.

Exemple INSERT

L'exemple suivant montre un enregistrement CDC pour une opération d'insertion :

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

Exemple de mise à jour

L'exemple suivant montre à quoi ressemblera un enregistrement CDC produit par une UPDATE instruction une fois qu'Aurora DSQL commencera à émettre op: "u" :

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

Exemple DELETE

Pour les suppressions effectuées sur des tables avec une clé primaire, le before champ contient les valeurs de clé primaire de la ligne supprimée :

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

Champs de charge utile

Détails du format

Les informations suivantes décrivent comment Aurora DSQL CDC met en forme les enregistrements. Concevez votre application pour gérer ces comportements.

Gestion de dossiers surdimensionnés

Lorsque le JSON sérialisé d'un enregistrement CDC dépasse 9 MiB, Aurora DSQL divise les images et fournit plusieurs enregistrements before and/or after Kinesis. Chaque enregistrement contient un type champ de niveau supérieur qui indique sa structure : full pour un enregistrement complet, chunked pour un enregistrement principal faisant référence à des fragments et fragment pour un élément individuel d'une image fragmentée. Les ts_ns champsop, sourcets_ms, et d'un enregistrement principal fragmenté se comportent de la même manière que ceux d'un enregistrement complet. Les enregistrements qui rentrent dans un seul enregistrement Kinesis sont type configurés full et ne nécessitent aucune manipulation supplémentaire.

A chunk_id est stable d'une tentative à l'autre. Si Aurora DSQL relivre un fragment, celui-ci est identique à la livraison d'origine, de sorte chunk_id que votre application peut continuer à être mise en mémoire tampon sous le même identifiant sans gérer les ensembles partiels issus de tentatives précédentes.

Record principal

Un enregistrement principal fragmenté remplace le niveau supérieur before ou le after champ de l'image divisée par un chunked objet qui décrit comment le réassembler. Chaque entrée ci-dessous chunked possède un chunk_id (l'identifiant qui lie les fragments à cet enregistrement), total_fragments (le nombre de fragments composant cette image) et crc32c (une somme de contrôle CRC32C, sous forme de chaîne décimale, sur le texte de l'image réassemblé). Si une image est en ligne et que l'autre est découpée, l'image en ligne apparaît toujours au niveau supérieur sous forme de valeur ou. 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
}

Enregistrement fragmenté

Chaque fragment est son propre enregistrement Kinesis avec trois champs type définis chunked.after.chunk_id sur : chunk_id correspond à fragment la valeur de l'enregistrement correspondant chunked.before.chunk_id ou de l'enregistrement principal, index correspond à la position de base zéro du fragment dans l'image et data constitue un segment du texte JSON de l'image divisé en limites de UTF-8 caractères (la data valeur de chaque fragment est une UTF-8 chaîne valide en soi). Comme Aurora DSQL CDC utilise le UNORDERED mode et des clés de partition aléatoires, les fragments et l'enregistrement principal peuvent arriver sur différentes partitions et dans n'importe quel ordre. Pour lire tous les fragments, consommez tous les fragments du flux de données Kinesis. Pour plus d'informations sur les commandes de livraison, consultezCommande.

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

Pour réassembler une image surdimensionnée, mettez chaque enregistrement en mémoire tampon type fragment par son. chunk_id Lorsque vous recevez un enregistrement principal avec typechunked, attendez d'avoir des total_fragments fragments pour chaque enregistrement chunk_id référencé sous chunked.before ouchunked.after, triez les fragments par index ordre croissant et concaténez les chaînes. data Le résultat concaténé est l'original before ou l'afterobjet sous forme de texte JSON. Analysez-le pour accéder aux valeurs des colonnes. Pour vérifier l'intégrité de la livraison, calculez CRC32C sur la chaîne concaténée et comparez le résultat à ou. chunked.before.crc32c chunked.after.crc32c

Sérialisation des types de données

Les tableaux suivants décrivent comment Aurora DSQL sérialise chaque type de données PostgreSQL dans les enregistrements CDC.

Types d’entier

Les valeurs bigint supérieures à ±2^53 peuvent perdre en précision dans les environnements. JavaScript Utilisez BigInt des bibliothèques de précision arbitraire dans ces cas.

Floating-point types

Booléen

Types caractères

Binaire

Types de date et d'heure

Autres types

Valeurs NULL

Quel que soit le type de données, les valeurs des NULL colonnes sont représentées au format JSONnull.

Évolution du schéma dans les dossiers du CDC

Lorsque vous modifiez le schéma d'une table, par exemple en ajoutant, en supprimant ou en renommant une colonne, les enregistrements CDC reflètent le changement à partir de la transaction qui a validé le changement DDL. Les enregistrements des transactions validées avant la modification du DDL utilisent le schéma précédent. Par exemple :

Suivez les modifications du schéma chez votre consommateur en aval en inspectant les noms de colonnes présents dans chaque enregistrement after et chaque before champ. Le source.version champ de chaque enregistrement identifie le format d'enveloppe du CDC.