Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# CDC-Datensätze verstehen
**Wichtig**
Diese Funktion wird als AWS Vorversion bereitgestellt und kann sich ändern. Weitere Informationen finden Sie in Abschnitt 2, Betas und Vorschauen, in den [AWS Servicebedingungen](https://aws.amazon.com/service-terms/). Weitere Informationen zu den Preisen für CDC-Streams finden Sie auf der [Aurora DSQL-Preisseite](https://aws.amazon.com/rds/aurora/dsql/pricing/).
Vor der allgemeinen Verfügbarkeit werden wir Ihrer Stream-Payload neue Operationstypen (`"op": "u"`für Updates) hinzufügen. Um sicherzustellen, dass Ihre Anwendung diese Änderungen unverändert verarbeitet, behandeln Sie jeden unbekannten `op` Wert als Fehler, indem Sie die Payload übernehmen. `after` Details dazu finden Sie unter [CDC-Datensätze verstehen](#cdc-record-format).
Aurora DSQL CDC liefert jede Änderung als JSON-Datensatz. Der Datensatz verwendet eine Hüllstruktur mit Operationstyp, Bildern vor und nach der Zeile und Quellmetadaten.
## So werden Datensätze Amazon Kinesis zugeordnet
Aurora DSQL schreibt jeden CDC-Datensatz als einen einzelnen Kinesis-Datensatz. Das `Data` Feld des Kinesis-Datensatzes enthält die JSON-Nutzlast. Aurora DSQL verwendet einen randomisierten Kinesis-Partitionsschlüssel, um CDC-Datensätze gleichmäßig auf Shards zu verteilen. Um alle Änderungen zu lesen, verwenden Sie alle Shards im Kinesis-Datenstrom. Wenn ein Datensatz die Größenbeschränkung für Kinesis-Datensätze überschreitet, teilt Aurora DSQL ihn auf mehrere Kinesis-Datensätze auf. Details hierzu finden Sie unter [Umgang mit übergroßen Datensätzen](#cdc-oversized-records).
**Anmerkung**
Ein Kinesis-Datensatz hat einen `Data` Blob. Die Primärschlüsselwerte werden im Feld der JSON-Payload für Löschungen oder `before` im Feld für Einfügungen und `after` Aktualisierungen angezeigt. Um den Primärschlüssel für die nachfolgende Verarbeitung zu extrahieren, lesen Sie ihn aus dem entsprechenden Feld in der Payload.
## Primärschlüssel in der Payload
Bei Tabellen mit einem Primärschlüssel erscheinen die Werte der Primärschlüsselspalte in der Payload:
+ Bei **Einfügungen** und **Aktualisierungen** umfasst die Payload die Primärschlüsselspalten zusammen mit allen anderen Spalten im `after` Feld.
+ Bei **Löschungen werden** die Primärschlüsselspalten im `before` Feld angezeigt.
Stellen Sie sich zum Beispiel eine Tabelle mit einem zusammengesetzten Primärschlüssel vor:
```
CREATE TABLE order_items (
order_id INT,
item_id INT,
quantity INT,
price NUMERIC,
PRIMARY KEY (order_id, item_id)
);
```
Ein Löschen dieser Tabelle erzeugt eine Nutzlast, wo`"before": {"order_id": 1001, "item_id": 42}`.
## Nutzlast aufzeichnen
Die Nutzlast verwendet das folgende JSON-Umschlagformat.
**INSERT-Beispiel**
Das folgende Beispiel zeigt einen CDC-Datensatz für einen Einfügevorgang:
```
{
"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
}
```
**Beispiel „UPDATE“**
Das folgende Beispiel zeigt, wie ein durch eine `UPDATE` Anweisung erzeugter CDC-Datensatz aussehen wird, nachdem Aurora DSQL mit der Ausgabe beginnt: `op: "u"`
**Wichtig**
Derzeit sendet Aurora DSQL sowohl `op: "c"` für Einfügungen als auch für Updates. Eine nachfolgende Version wird `op: "u"` für Updates und `op: "c"` für Inserts ausgegeben. Gestalten Sie Ihre App so `c``u`, dass sie handhabt, `d` damit Ihre Kunden während der Umstellung weiterarbeiten können.
```
{
"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
}
```
**Beispiel LÖSCHEN**
Bei Löschungen in Tabellen mit einem Primärschlüssel enthält das `before` Feld die Primärschlüsselwerte der gelöschten Zeile:
```
{
"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
}
```
## Payload-Felder
| Feld | Description |
| --- |--- |
| type | Der Datensatztyp. fullfür einen vollständigen Datensatz, der Inline before - und after Werte enthält. chunkedfür einen Hauptdatensatz, der auf Fragmentdatensätze für ein oder beide Bilder verweist. fragmentfür einen einzelnen Teil eines zusammengefügten Bilds. Details hierzu finden Sie unter [Umgang mit übergroßen Datensätzen](#cdc-oversized-records). |
| op | Art des Vorgangs. c= erstellen (einfügen), u = aktualisieren, d = löschen. Derzeit sendet Aurora DSQL sowohl c für Einfügungen als auch für Updates. Eine nachfolgende Version wird u für Updates und c für Inserts ausgegeben. Entwerfen Sie Ihre App so, dass sie alle drei Werte verarbeitet. |
| before | Enthält bei Löschungen in Tabellen mit einem Primärschlüssel die Primärschlüsselwerte der gelöschten Zeile. Aurora DSQL legt dieses Feld null für Einfügungen, Aktualisierungen und Löschungen in Tabellen ohne Primärschlüssel auf fest. |
| after | Der vollständige Zeilenstatus nach der Änderung, einschließlich aller Spalten. Aurora DSQL setzt dieses Feld auf null für Löschungen. |
| chunked | Nur vorhanden, wenn es type ist. chunked Enthält Metadaten zur Reassemblierung für das before Bild, das after Bild oder beides. Aurora DSQL lässt das abgeschnittene Bild aus der obersten Ebene before oder dem after Feld weg und platziert es stattdessen darunter. chunked Details hierzu finden Sie unter [Umgang mit übergroßen Datensätzen](#cdc-oversized-records). |
| source.version | Die Version des CDC-Quellmetadatenformats. Die aktuelle Version ist 1.0. |
| source.ts\_ms | Der Zeitstempel des Transaktions-Commits in Millisekunden seit der Unix-Epoche, Coordinated Universal Time (UTC). |
| source.ts\_ns | Zeitstempel des Transaktions-Commits in Nanosekunden, UTC. Der Zeitstempel mit der höchsten Genauigkeit, der verfügbar ist. Verwenden Sie dieses Feld, um eine Gesamtreihenfolge der Transaktionen festzulegen. |
| source.txId | Eine eindeutige Transaktions-ID, codiert als Base32. Alle Datensätze aus derselben Transaktion haben denselben txId Wert. Verwenden Sie dieses Feld, um Datensätze zu gruppieren, die zu derselben Transaktion gehören. |
| source.schema | Der PostgreSQL-Schemaname (zum Beispielpublic). |
| source.table | Der Name der Tabelle. |
| source.db | Der Datenbankname. Immer postgres für Aurora DSQL. |
| source.cluster | Die Aurora DSQL-Cluster-ID. |
| ts\_ms | Der Zeitpunkt, zu dem das CDC-System den Datensatz verarbeitet hat, in Millisekunden, UTC. Der Unterschied zwischen ts\_ms und source.ts\_ms ist ein Maß für die Verzögerung bei der Replikation. |
| ts\_ns | Die Zeit, zu der das CDC-System den Datensatz verarbeitet hat, in Nanosekunden, UTC. |
## Einzelheiten formatieren
Die folgenden Details beschreiben, wie Aurora DSQL CDC Datensätze formatiert. Entwerfen Sie Ihre App so, dass sie mit diesen Verhaltensweisen umgehen kann.
+ **Vollständiges Nachbild für Einfügungen und Updates.** Aurora DSQL enthält den vollständigen Zeilenstatus im `after` Feld für alle Schreibvorgänge. Das `before` Feld ist `null` für Einfügungen und Aktualisierungen vorgesehen. Derzeit werden sowohl Einfügungen als auch Updates verwendet`op: "c"`, aber eine nachfolgende Version wird `op: "u"` für Updates eine Ausgabe ausgeben. Entwerfen Sie Ihre App so, dass sie `source.ts_ns` pro Primärschlüssel für die Bestellung verwendet, anstatt sich auf das `op` Feld zu verlassen, um zwischen Einfügungen und Updates zu unterscheiden.
+ **Post-change Nur Zeilenstatus.** CDC-Datensätze enthalten den vollständigen Zeilenstatus nach jeder Änderung. Der Status der Zeile vor einer Aktualisierung ist nicht enthalten. Bei Löschungen in Tabellen mit einem Primärschlüssel enthält das `before` Feld die Primärschlüsselwerte.
+ **Numerische Typen, die als Zeichenketten serialisiert sind.** Aurora DSQL serialisiert `numeric` und `decimal` bewertet als JSON-Zeichenketten, um die exakte Präzision zu gewährleisten.
+ **Binärdaten, die als Base64 codiert sind.** Aurora DSQL kodiert `bytea` Werte als Base64-Zeichenketten.
+ **Spezielle Gleitkommawerte und numerische Werte.** Aurora SQL serialisiert NaN und ±Infinity als die Zeichenketten`"NaN"`, und. `"Infinity"` `"-Infinity"` Dies gilt für die Typen`real`, und`double precision`. `numeric`
+ **Als JSON-Zeichenketten serialisierte JSON-Spalten.** Aurora DSQL serialisiert `json` Spaltenwerte als JSON-Zeichenfolgen, die den in der Spalte gespeicherten JSON-Rohtext enthalten. Analysieren Sie den Zeichenkettenwert in Ihrer App (z. B. mit `JSON.parse` in JavaScript oder `json.loads` in Python), um auf den zugrunde liegenden JSON-Wert zuzugreifen.
+ **Überlaufwerte, die als Null ausgegeben werden.** Wenn ein Wert während der Serialisierung nicht im Ziel-JSON-Typ dargestellt werden kann, gibt Aurora DSQL JSON `null` für diese Spalte aus. Dies gilt für `interval` Werte, deren Gesamtmikrosekunden den 64-Bit-Ganzzahlbereich mit Vorzeichen überschreiten (±9.223.372.036.854.775.807 Mikrosekunden, ungefähr ±292.271 Jahre). Entwerfen Sie Ihre `null` App so, dass sie unerwartete Werte in Spalten verarbeitet, für die im Datenbankschema keine NULL-Werte zulässig sind.
+ **Übergroße Datensätze, die in Blöcke aufgeteilt sind.** Wenn ein Datensatz die Amazon Kinesis Kinesis-Datensatzgrößenbeschränkung überschreitet, teilt Aurora DSQL das betroffene `after` Bild `before` oder Bild in Fragmente auf und stellt sie als separate Kinesis-Datensätze bereit, sodass Sie die Änderung trotzdem erhalten. Entwerfen Sie Ihre App so, dass sie die Bilder wieder zusammensetzt. Details hierzu finden Sie unter [Umgang mit übergroßen Datensätzen](#cdc-oversized-records).
## Umgang mit übergroßen Datensätzen
Wenn das serialisierte JSON eines CDC-Datensatzes 9 MiB überschreitet, teilt Aurora DSQL die `before` and/or `after` Bilder auf und liefert mehrere Kinesis-Datensätze. Jeder Datensatz enthält ein `type` Feld der obersten Ebene, das seine Struktur angibt: `full` für einen vollständigen Datensatz, für einen Hauptdatensatz, der auf Fragmente verweist, und `chunked` `fragment` für einen einzelnen Teil eines abgeschnittenen Bildes. Die `ts_ns` Felder`op`, `source``ts_ms`, und in einem aufgeteilten Hauptdatensatz verhalten sich genauso wie in einem vollständigen Datensatz. Datensätze, die in einen einzelnen Kinesis-Datensatz passen, sind auf `type` eingestellt `full` und erfordern keine zusätzliche Bearbeitung.
A `chunk_id` ist bei Wiederholungsversuchen stabil. Wenn Aurora DSQL ein Fragment erneut zustellt, überträgt es dasselbe `chunk_id` wie die ursprüngliche Lieferung, sodass Ihre App unter derselben Kennung weiter puffern kann, ohne Teilsätze aus früheren Versuchen zu verarbeiten.
**Hauptdatensatz**
Ein aufgeteilter Hauptdatensatz ersetzt die oberste Ebene `before` oder das `after` Feld für das geteilte Bild durch ein `chunked` Objekt, das beschreibt, wie es wieder zusammengesetzt wird. Jeder Eintrag darunter `chunked` hat eine `chunk_id` (die Kennung, die Fragmente mit diesem Datensatz verknüpft), `total_fragments` (die Anzahl der Fragmente, aus denen das Bild besteht) und `crc32c` (eine CRC32C-Prüfsumme als Dezimalzeichenfolge über dem wieder zusammengesetzten Bildtext). Wenn ein Bild inline ist und das andere in Blöcke aufgeteilt ist, erscheint das Inline-Bild immer noch auf der obersten Ebene entweder als Wert oder. `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
}
```
**Datensatz fragmentieren**
Jedes Fragment ist ein eigener `type` Kinesis-Datensatz mit einer Einstellung `chunked.after.chunk_id` auf `fragment` und drei Feldern: `chunk_id` entspricht dem Wert im entsprechenden Datensatz `chunked.before.chunk_id` oder im Hauptdatensatz, `index` ist die nullbasierte Position des Fragments innerhalb des Bildes und `data` ist ein Segment des JSON-Textes des Bildes, das nach UTF-8 Zeichengrenzen aufgeteilt ist (der `data` Wert jedes Fragments ist für sich genommen eine gültige UTF-8 Zeichenfolge). Da Aurora DSQL CDC `UNORDERED` Modus- und randomisierte Partitionsschlüssel verwendet, können Fragmente und der Hauptdatensatz auf unterschiedlichen Shards und in beliebiger Reihenfolge ankommen. Um alle Fragmente zu lesen, verbrauchen Sie alle Shards im Kinesis-Datenstrom. Weitere Informationen zur Bestellung von Lieferungen finden Sie unter. [Bestellung](cdc-streams.md#cdc-ordering)
```
{
"type": "fragment",
"chunk_id": "{{chunk-id}}",
"index": 0,
"data": "{{partial-JSON-text}}"
}
```
Um ein übergroßes Bild wieder zusammenzusetzen, puffern Sie jeden Datensatz `type` `fragment` einzeln. `chunk_id` Wenn Sie einen Hauptdatensatz mit erhalten `type``chunked`, warten Sie, bis Sie `total_fragments` Fragmente für jeden Datensatz haben, auf den unter `chunked.before` oder `chunk_id` verwiesen wird`chunked.after`, sortieren Sie die Fragmente `index` aufsteigend und verketten Sie die Zeichenketten. `data` Das verkettete Ergebnis ist das Original `before` oder das `after` Objekt als JSON-Text. Analysieren Sie es, um auf die Spaltenwerte zuzugreifen. Um die Integrität der Lieferung zu überprüfen, berechnen Sie CRC32C anhand der verketteten Zeichenfolge und vergleichen Sie das Ergebnis mit oder. `chunked.before.crc32c` `chunked.after.crc32c`
## Serialisierung des Datentyps
In den folgenden Tabellen wird beschrieben, wie Aurora DSQL jeden PostgreSQL-Datentyp in CDC-Datensätzen serialisiert.
### Ganzzahl-Typen
| PostgreSQL-Typ | JSON-Darstellung | Beispiel |
| --- |--- |--- |
| smallint (int2) | JSON-Nummer | 42 |
| integer (int4) | JSON-Nummer | 1001 |
| bigint (int8) | JSON-Nummer | 9223372036854775807 |
| oid | JSON-Nummer (ohne Vorzeichen) | 16384 |
Werte `bigint` über ±2^53 können in Umgebungen an Genauigkeit verlieren. JavaScript Verwenden Sie in BigInt diesen Fällen Bibliotheken oder Bibliotheken mit beliebiger Genauigkeit.
### Floating-point Typen
| PostgreSQL-Typ | JSON-Darstellung | Beispiel | Hinweise |
| --- |--- |--- |--- |
| real (float4) | JSON-Nummer | 3.14159 | NaN und ±Infinity werden als Strings"NaN",, "Infinity" serialisiert. "-Infinity" |
| double precision (float8) | JSON-Nummer | 3.141592653589793 | Gleiche Behandlung von Sonderwerten wiereal. |
| numeric / decimal | JSON-Zeichenfolge | "123.45" | Immer eine Zeichenfolge, um die exakte Genauigkeit beizubehalten. NaN und ±Infinity werden als Strings"NaN",, "Infinity" serialisiert. "-Infinity" |
### Boolesch
| PostgreSQL-Typ | JSON-Darstellung | Beispiel |
| --- |--- |--- |
| boolean | Boolescher JSON-Wert | true oder false |
### Zeichentypen
| PostgreSQL-Typ | JSON-Darstellung | Beispiel |
| --- |--- |--- |
| varchar / text | JSON-Zeichenfolge | "Hello, world\!" |
| bpchar (char(n)) | JSON-Zeichenfolge | "ABC"(Leerzeichen am Ende entfernt) |
| name | JSON-Zeichenfolge | "pg\_class" |
| "char"(Einzelbyte) | JSON-Zeichenfolge | "A" |
### Binär
| PostgreSQL-Typ | JSON-Darstellung | Beispiel |
| --- |--- |--- |
| bytea | JSON-Zeichenfolge (Base64) | "SGVsbG8gV29ybGQh" |
### Typen für Datum und Uhrzeit
| PostgreSQL-Typ | JSON-Darstellung | Beispiel | Hinweise |
| --- |--- |--- |--- |
| date | JSON-Nummer (Tage seit der Unix-Epoche) | 19797 | \+infinityund -infinity werden als Tageszählungen für Wächter dargestellt, die aus der Epochenoffset-Arithmetik abgeleitet wurden. Diese Werte entsprechen keinen aussagekräftigen Kalenderdaten. |
| time | JSON-Nummer (Mikrosekunden seit Mitternacht) | 52200123456 | |
| timetz | JSON-Nummer (Mikrosekunden seit Mitternacht, UTC) | 52200123456 | Die Ortszeit wird an UTC angepasst, indem der gespeicherte Zeitzonen-Offset (Sekunden westlich von UTC) angewendet wird. Das Ergebnis wird in den Bereich [0, 86400000000) Mikrosekunden eingeschlossen. |
| timestamp | JSON-Nummer (Mikrosekunden seit der Unix-Epoche) | 1710510600123456 | ±Infinity ordnet Sentinel-Werte zu: für und für. 9223372036825200000 \+infinity -9223372036832400000 -infinity |
| timestamptz | JSON-Nummer (Mikrosekunden seit der Unix-Epoche) | 1710510600123456 | In UTC gespeichert und ausgegeben. Dieselben ±Infinity-Sentinel-Werte wie. timestamp |
| interval | JSON-Nummer (ungefähre Gesamtmikrosekunden) | 2802603000000 | Monate werden auf 30,4375 Tage (2.629.800 Sekunden) geschätzt. Die Summe wird berechnet als. (months × 2,629,800 \+ days × 86,400) × 1,000,000 \+ microseconds Wenn das Ergebnis den 64-Bit-Ganzzahlbereich mit Vorzeichen überschreitet (±9.223.372.036.854.775.807 Mikrosekunden, ungefähr ±292.271 Jahre), gibt Aurora DSQL JSON für die Spalte aus. null |
### Andere Typen
| PostgreSQL-Typ | JSON-Darstellung | Beispiel |
| --- |--- |--- |
| uuid | JSON-Zeichenfolge (Standard-Hexadezimalformat 8-4-4-12) | "550e8400-e29b-41d4-a716-446655440000" |
| oidvector | Leeres JSON-Array | [] |
| json | JSON-Zeichenfolge, die den rohen JSON-Text enthält | "{\\"key\\": \\"value\\"}" |
### NULL-Werte
Für jeden Datentyp werden `NULL` Spaltenwerte als JSON dargestellt`null`.
## Schemaentwicklung in CDC-Datensätzen
Wenn Sie das Schema einer Tabelle ändern, z. B. indem Sie eine Spalte hinzufügen, löschen oder umbenennen, spiegeln die CDC-Datensätze die Änderung ab der Transaktion wider, die die DDL-Änderung festgeschrieben hat. Datensätze von Transaktionen, die vor der DDL-Änderung festgeschrieben wurden, verwenden das vorherige Schema. Beispiel:
+ Wenn Sie eine Spalte hinzufügen, enthalten Datensätze aus früheren Transaktionen die neue Spalte nicht. Datensätze ab der hinzugefügten Transaktion enthalten die neue Spalte.
+ Wenn Sie eine Spalte löschen, enthalten die Datensätze ab der Löschtransaktion diese Spalte nicht mehr.
+ Wenn Sie eine Spalte umbenennen, verwenden Datensätze ab der Umbenennungstransaktion den neuen Spaltennamen.
Verfolgen Sie Schemaänderungen in Ihrem Downstream-Consumer, indem Sie die Spaltennamen überprüfen, die in den einzelnen Datensätzen und Feldern vorhanden sind`after`. `before` Das `source.version` Feld in jedem Datensatz identifiziert das CDC-Umschlagformat.