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.
# Streams überwachen
**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.md).
Wenn Aurora DSQL bei der Übermittlung eines CDC-Datensatzes auf einen Fehler stößt, wechselt der Stream in den `IMPAIRED` Status. Ein beeinträchtigter Stream verarbeitet und übermittelt weiterhin andere Datensätze — Aurora DSQL versucht nur den fehlgeschlagenen Datensatz erneut. Aurora DSQL misst die Replikationsverzögerung ab dem ältesten nicht zugestellten Datensatz, und die Verzögerung nimmt zu, bis Sie das Problem behoben haben. Aurora DSQL bewahrt nicht zugestellte Änderungen intern für eine Woche auf.
Wenn Sie das zugrundeliegende Problem in diesem Fenster lösen, ist der nächste Versuch erfolgreich, der Fehlerstatus wird gelöscht und der Stream wechselt zurück zu. `ACTIVE` Korrigieren Sie das externe Problem (IAM-Richtlinie, AWS KMS Schlüssel, Amazon Kinesis Kinesis-Kapazität usw.) und Aurora DSQL versucht es automatisch erneut.
Wenn die Replikationsverzögerung den Fehlerschwellenwert überschreitet, wechselt der Stream zu. `FAILED`
**Wichtig**
Ein ausgefallener Stream kann nicht wiederhergestellt werden. Sie müssen den fehlgeschlagenen Stream löschen und einen neuen erstellen.
## Stream-Lebenszyklus
Ein Stream durchläuft während seines Lebenszyklus die folgenden Status:
+ **`CREATING`**— Aurora DSQL richtet den Stream ein. Aurora DSQL liefert noch keine CDC-Datensätze.
+ **`ACTIVE`**— Der Stream ist betriebsbereit und liefert CDC-Datensätze an das Ziel.
+ **`IMPAIRED`**— Im Stream ist ein Problem aufgetreten, das Ihr Eingreifen erfordert. Aurora DSQL versucht den fehlgeschlagenen Datensatz mit exponentiellem Backoff erneut, obwohl andere Datensätze weiterhin liefern können. Aurora DSQL misst die Replikationsverzögerung ab dem ältesten nicht zugestellten Datensatz, und die Verzögerung nimmt zu, bis Sie das Problem behoben haben. Aurora DSQL speichert nicht zugestellte Änderungen intern für eine Woche. Siehe [Fehlercodereferenz](#cdc-failure-reasons).
+ **`FAILED`**— Im Stream ist ein anhaltender Fehler aufgetreten und er liefert keine CDC-Datensätze mehr. Ein fehlgeschlagener Stream kann nicht wiederhergestellt werden und Sie müssen ihn löschen. Informationen [Fehlercodereferenz](#cdc-failure-reasons) zu den Bedingungen, die dazu führen, dass ein Stream in diesen Zustand übergeht, finden Sie unter.
+ **`DELETING`**— Aurora DSQL entfernt Stream-Ressourcen.
+ **`DELETED`**— Aurora DSQL hat den Stream gelöscht. Gibt nach Abschluss des Löschvorgangs a `GetStream` `ResourceNotFoundException` zurück.
Rufen Sie jederzeit `GetStream` an, um den Stream-Status einzusehen. Wenn der Stream `IMPAIRED` oder ist`FAILED`, enthält die Antwort ein `statusReason` Objekt mit dem Fehlercode und dem Zeitstempel. Weitere Informationen zu den `GetStream` Antwortfeldern finden Sie [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)in der Amazon Aurora DSQL API-Referenz.
## Fehlerbehebung bei einem beeinträchtigten oder ausgefallenen Stream
Gehen Sie wie folgt vor, wenn ein CDC-Stream beeinträchtigt wird oder ausfällt. Wenn es sich bei dem Stream um einen Stream handelt`FAILED`, können Sie ihn nicht wiederherstellen. Löschen Sie den Stream, beheben Sie das zugrundeliegende Problem und erstellen Sie einen neuen.
1. **Rufen Sie den Stream-Status ab.** Rufen Sie an `GetStream` und überprüfen Sie das `status` Feld. Wenn der Status lautet`ACTIVE`, ist der Stream fehlerfrei.
```
aws dsql get-stream \
--cluster-identifier {{cluster-id}} \
--stream-identifier {{stream-id}} \
--region {{region}}
```
1. **Lesen Sie den Fehlercode.** Wenn der Status `IMPAIRED` oder lautet`FAILED`, enthält die Antwort ein `statusReason` Objekt. Das `error` Feld enthält den Fehlercode.
```
{
"status": "IMPAIRED",
"statusReason": {
"error": "KINESIS_THROUGHPUT_EXCEEDED",
"updatedAt": "2025-01-15T14:30:00Z"
}
}
```
1. **Folgen Sie der Behebung.** Wenn es sich bei dem Stream um den Fehlercode handelt`IMPAIRED`, suchen Sie in der folgenden Tabelle nach dem Fehlercode und wenden Sie die empfohlene Lösung an. Aurora DSQL versucht es automatisch erneut, nachdem Sie das zugrunde liegende Problem behoben haben. Wenn es sich bei dem Stream um einen Stream handelt`FAILED`, löschen Sie ihn, beheben Sie das Problem und erstellen Sie einen neuen Stream.
## Fehlercodereferenz
In der folgenden Tabelle werden die einzelnen Fehlercodes, ihre Ursache, die Frage, ob der Stream wiederhergestellt werden kann, und die Schritte zu seiner Behebung beschrieben.
| Fehlercode | Ursache | Wiederherstellbar? | Wie löst man |
| --- |--- |--- |--- |
| KINESIS\_THROUGHPUT\_EXCEEDED | Ihr Kinesis-Datenstrom hat sein Durchsatzlimit überschritten oder die Verschlüsselungsvorgänge im Kinesis-Datenstrom AWS KMS gedrosselt, und die Replikationsverzögerung hat zugenommen. | Ja | Erhöhen Sie die Anzahl der Shards in Ihrem Kinesis-Datenstream oder wechseln Sie in den On-Demand-Kapazitätsmodus. Wenn der Kinesis-Datenstream einen vom AWS KMS Kunden verwalteten Schlüssel verwendet, stellen Sie sicher, dass das Anforderungskontingent des Schlüssels groß genug ist. Nachdem Sie die Kapazität erhöht haben, versucht Aurora DSQL es automatisch erneut. |
| KINESIS\_STREAM\_NOT\_FOUND | Der Kinesis-Zieldatenstream ist nicht mehr vorhanden. | Nein | Der Stream geht direkt zu FAILED über. Löschen Sie den CDC-Stream und erstellen Sie einen neuen, der auf einen gültigen Kinesis-Datenstream verweist. |
| ROLE\_ACCESS\_DENIED | Aurora DSQL kann die in der Zieldefinition angegebene IAM-Rolle nicht annehmen. Der AWS STS AssumeRole Anruf wurde zurückgegeben. AccessDenied | Ja | Stellen Sie sicher, dass die Vertrauensrichtlinie der Rolle es dem Aurora DSQL-Service Principal (dsql.amazonaws.com) ermöglicht, sie anzunehmen. Stellen Sie sicher, dass die aws:SourceAccount aws:SourceArn Bedingungen mit Ihrem Cluster übereinstimmen. Details hierzu finden Sie unter [Vertrauensrichtlinie für die Servicerolle](cdc-iam.md#cdc-iam-trust-policy). Nachdem Sie die Vertrauensrichtlinie korrigiert haben, versucht Aurora DSQL es automatisch erneut. |
| KINESIS\_ACCESS\_DENIED | Die angenommene Rolle hat keine Schreibberechtigung in den Kinesis-Datenstrom. Kinesis ist zurückgekehrtAccessDeniedException. | Ja | Fügen Sie kinesis:PutRecord der Rollenrichtlinie für den Kinesis-Zieldatenstream Amazon Resource Name (ARN) kinesis:PutRecords Berechtigungen hinzu. Nachdem Sie die Richtlinie korrigiert haben, versucht Aurora DSQL es automatisch erneut. |
| KINESIS\_KMS\_ACCESS\_DENIED | Die angenommene Rolle ist nicht berechtigt, den AWS KMS Schlüssel zu verwenden, der den Kinesis-Datenstrom verschlüsselt. Dieser Fehler bezieht sich AWS KMS auf Zugriffsverweigerung und ungültige Schlüsselstatus. | Ja | Stellen Sie sicher, dass die Rolle über kms:GenerateDataKey Berechtigungen für den AWS KMS Schlüssel verfügt, den der Kinesis-Datenstream verwendet. Stellen Sie außerdem sicher, dass der AWS KMS Schlüssel aktiviert und gültig ist. Dieser Schlüssel ist der Verschlüsselungsschlüssel für den Kinesis-Datenstream, nicht der AWS KMS Schlüssel des Clusters. Details hierzu finden Sie unter [Richtlinie für Berechtigungen für Servicerollen](cdc-iam.md#cdc-iam-permissions-policy). Nachdem Sie die Berechtigungen oder den Schlüsselstatus korrigiert haben, versucht Aurora DSQL es automatisch erneut. |
| KINESIS\_OVERSIZE\_RECORD | Ein CDC-Datensatz hat die für den Kinesis-Datenstrom konfigurierte maximale Datensatzgröße überschritten. | Ja | Erhöhen MaxRecordSizeInKiB Sie den Kinesis-Datenstrom auf 10240 (10 MiB). Sie können diese Einstellung für einen vorhandenen Kinesis-Datenstream aktualisieren, ohne ihn zu löschen. Nachdem Sie das Limit erhöht haben, versucht Aurora DSQL den übergroßen Datensatz automatisch erneut und der Stream wechselt zurück zu. ACTIVE |
| CLUSTER\_CMK\_INACCESSIBLE | Auf den vom AWS KMS Kunden verwalteten Schlüssel, der den Aurora DSQL-Cluster verschlüsselt, kann nicht zugegriffen werden. | Ja | Überprüfen Sie die AWS KMS Schlüsselrichtlinie und den Schlüsselstatus. Re-enable oder stellen Sie den Zugriff auf den Schlüssel wieder her. Nachdem der Schlüssel wieder zugänglich ist, wechselt der Stream zurück zuACTIVE. |
In der obigen Tabelle sind alle `StreamFailureErrorCode` Werte aufgeführt. Einzelheiten zum `statusReason` Antwortfeld finden Sie [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)in der [Amazon Aurora DSQL API-Referenz.](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_api_reference.html)
## Wiederherstellung eines beeinträchtigten Streams
Bei den meisten Fehlern wird der Stream zuerst auf umgestellt`IMPAIRED`. Ein beeinträchtigter Stream verarbeitet weiterhin andere Datensätze und wiederholt den fehlerhaften Datensatz automatisch. Ein `FAILED` Stream kann nicht wiederhergestellt werden. Sie müssen ihn löschen und einen neuen erstellen.
+ **Bei behebbaren Fehlern:** Beheben Sie das externe Problem (IAM-Richtlinie, AWS KMS Schlüssel, Kinesis-Kapazität oder Größenbeschränkung für Kinesis-Datensätze). Bei der nächsten erfolgreichen Wiederholung wird der Fehlerstatus gelöscht und der Stream wird wieder in den Zustand versetzt. `ACTIVE`
+ **Für`KINESIS_STREAM_NOT_FOUND`:** Der Stream geht direkt zu. `FAILED` Löschen Sie den fehlgeschlagenen Stream und erstellen Sie einen neuen, der auf einen gültigen Kinesis-Datenstream verweist.
Bei allen anderen Fehlercodes gilt: Wenn die Replikationsverzögerung den Fehlerschwellenwert überschreitet, bevor Sie das Problem behoben haben, wird der Stream von `IMPAIRED` zu `FAILED` gewechselt. Ein fehlgeschlagener Stream kann nicht zurück zu wechseln`ACTIVE`. Löschen Sie den fehlerhaften Stream, beheben Sie das zugrunde liegende Problem und erstellen Sie einen neuen.
## Den Zustand des Streams überwachen
Verwenden Sie CloudWatch Metriken und die `GetStream` API, um den Zustand des Streams zu überwachen. CloudWatchMetriken bieten einen kontinuierlichen Einblick in die Leistung der CDC-Pipeline und `GetStream` geben den spezifischen Fehlercode an, wenn ein Stream beeinträchtigt ist oder ausfällt.
Eine vollständige Liste der CDC-Metriken, einschließlich, und `IsImpaired` `BehindSourceLag` `PublishedBytes``PublishedRecords`, finden Sie unter. [CloudWatch Metriken für CDC-Streams](#cdc-cloudwatch-metrics) Weitere Informationen zu den `GetStream` Antwortfeldern finden Sie [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)in der Amazon Aurora DSQL API-Referenz.
## CloudWatch Metriken für CDC-Streams
Verwenden Sie die folgenden CloudWatch Metriken, um den Zustand und den Durchsatz jedes CDC-Streams zu überwachen. Aurora DSQL veröffentlicht diese Metriken im `AWS/AuroraDSQL` Namespace mit den Dimensionen `ClusterId` und. `StreamId` Die letzte Metrik ist eine standardmäßige Amazon Kinesis Kinesis-Metrik im `AWS/Kinesis` Namespace, die die Verzögerung beim Lesen im Downstream misst.
**Anmerkung**
Aurora DSQL veröffentlicht auch die `StreamDPU` Metriken `BytesStreamed` und im `AWS/AuroraDSQL` Namespace für die Nutzungs- und Abrechnungsverfolgung. Beschreibungen finden Sie unter. [CDC-Stream-Metriken](cloudwatch-monitoring.md#cdc-stream-metrics)
| Metrikname | Nützliche Statistik | Description |
| --- |--- |--- |
| IsImpaired | Maximum | Zeigt an, ob der Stream beeinträchtigt ist. Der Wert gibt an1, wann sich der Stream im IMPAIRED Status befindet und 0 ob der Stream fehlerfrei ist. Aurora DSQL gibt diese Metrik kontinuierlich für jeden aktiven oder beeinträchtigten Stream aus. Verwenden Sie diese Metrik, um einen CloudWatch Alarm zu erstellen, der Sie benachrichtigt, wenn ein Stream beeinträchtigt wird. |
| BehindSourceLag | Durchschnitt | Die Verzögerung in Millisekunden zwischen dem Commit einer Transaktion in Aurora DSQL und der Verarbeitung des resultierenden Datensatzes durch das CDC-System. Ein steigender Wert weist darauf hin, dass die CDC-Pipeline dem Schreib-Workload hinterherhinkt. |
| PublishedBytes | Summe | Die Gesamtzahl der Byte der CDC-Datensätze, die Aurora DSQL während des Zeitraums in das Ziel geschrieben hat. Verwenden Sie diese Metrik zusammen mit der Anzahl Kinesis Kinesis-Shards, um festzustellen, ob Sie genügend Schreibkapazität bereitgestellt haben. |
| PublishedRecords | Summe | Die Gesamtzahl der CDC-Datensätze, die Aurora DSQL während des Zeitraums in das Ziel geschrieben hat. Jede festgeschriebene Zeilenänderung erzeugt einen Datensatz. |
| GetRecords.IteratorAgeMilliseconds (AWS/Kinesis) | Durchschnitt | Eine Kinesis-Standardmetrik, die das Alter des letzten Datensatzes, der von Ihrer Downstream-App aus dem Kinesis-Datenstream gelesen wurde, in Millisekunden angibt. Verwenden Sie die Dimension. StreamName Ein steigender Wert bedeutet, dass Ihre Downstream-App nicht mit der Geschwindigkeit Schritt halten kann, mit der Aurora DSQL CDC-Datensätze in Kinesis schreibt. |
Auf der Registerkarte **Überwachung** der Aurora DSQL-Konsole wird ein **durchschnittlicher End-to-End-Latenzwert** angezeigt, der `BehindSourceLag` (CDC-Quelllatenz) und `GetRecords.IteratorAgeMilliseconds` (Kinesis-Leserverzögerung) kombiniert wird. Dieser kombinierte Wert stellt die Gesamtverzögerung vom Datenbank-Commit bis zum Downstream-Read dar.
## Überwachung bewährter Verfahren
Verwenden Sie die folgenden Methoden, um Probleme mit der CDC-Pipeline zu erkennen und zu lösen, bevor sie sich auf Ihre nachgelagerten Systeme auswirken.
**Schalten Sie Alarme ein `BehindSourceLag`**
Erstellen Sie einen CloudWatch Alarm, der ausgelöst wird, wenn `BehindSourceLag` ein für Ihre Arbeitslast relevanter Schwellenwert überschritten wird. Legen Sie beispielsweise 60 Sekunden für ein Latenzziel von einer Minute fest. Ein anhaltender Anstieg dieser Kennzahl bedeutet, dass die CDC-Pipeline ins Hintertreffen gerät. Wenn die Verzögerung den Ausfallschwellenwert erreicht, geht der Stream in den Status FAILED über. Wenn Sie den Trend erkennen, haben Sie Zeit, die Kinesis-Kapazität zu erhöhen oder Durchsatzengpässe zu untersuchen, bevor der Stream nachlässt.
**Monitor `GetRecords.IteratorAgeMilliseconds`auf der Kinesis-Seite**
Selbst wenn Aurora DSQL Datensätze pünktlich liefert, kann Ihre Downstream-App ins Hintertreffen geraten. Erstellen Sie einen CloudWatch Alarm für `GetRecords.IteratorAgeMilliseconds` (im `AWS/Kinesis` Namespace, Dimension`StreamName`), um Verzögerungen im Downstream-Bereich unabhängig zu erkennen. Wenn diese Metrik steigt und unverändert `BehindSourceLag` bleibt, liegt der Engpass in Ihrer Downstream-App, nicht in Aurora DSQL.
**Verfolge `PublishedBytes`die Kapazität von Kinesis-Shards**
Jeder Kinesis-Shard unterstützt bis zu 1 MiB pro Sekunde für Schreibvorgänge. Vergleichen Sie die `PublishedBytes` Summe pro Minute mit Ihrer gesamten Shard-Schreibkapazität (Anzahl der Shards × 60 MiB pro Minute). Wenn sich die Auslastung 80 Prozent nähert, fügen Sie Shards hinzu oder wechseln Sie in den On-Demand-Kapazitätsmodus, bevor die Drosselung ausgelöst wird. `KINESIS_THROUGHPUT_EXCEEDED`
**Alarm aktiviert zur sofortigen Erkennung von `IsImpaired`Beeinträchtigungen**
Erstellen Sie einen CloudWatch Alarm, der ausgelöst wird, wenn `IsImpaired` Maximum `1` für einen Testzeitraum größer oder gleich ist. Dadurch erhalten Sie ein direktes Signal, wenn ein Stream den `IMPAIRED` Status erreicht, ohne die API abfragen zu müssen. Rufen Sie nach dem Auslösen des Alarms an, `GetStream` um das `statusReason.error` Feld zu lesen und die Schritte zur Problembehebung unter zu befolgen. [Fehlerbehebung bei einem beeinträchtigten oder ausgefallenen Stream](#cdc-troubleshooting)
**Umfrage `GetStream`zum detaillierten Status**
Die `IsImpaired` Metrik gibt an, dass ein Stream beeinträchtigt ist, aber die `GetStream` API stellt den spezifischen Fehlercode und den Zeitstempel bereit. Fragen `GetStream` Sie nach einem Zeitplan ab (z. B. alle fünf Minuten) oder als Reaktion auf einen `IsImpaired` Alarm. Das `statusReason.error` Feld zeigt Ihnen, was schief gelaufen ist. Kombinieren Sie dies mit den Schritten zur Fehlerbehebung, um [Fehlerbehebung bei einem beeinträchtigten oder ausgefallenen Stream](#cdc-troubleshooting) eine schnelle Lösung zu erhalten.
**Verwenden Sie Dashboards, um Kennzahlen zu korrelieren**
Erstellen Sie ein CloudWatch Dashboard, in dem `IsImpaired``BehindSourceLag`, `PublishedRecords``PublishedBytes`, und `GetRecords.IteratorAgeMilliseconds` nebeneinander angezeigt werden. Durch die Korrelation dieser Kennzahlen können Sie zwischen einem CDC-Pipeline-Problem (steigend`BehindSourceLag`) und einem Downstream-Reading-Problem (steigend `IteratorAge` bei stabil`BehindSourceLag`) unterscheiden.