Checkpointing, Recovery und Delivery Semantics
Erfahren Sie mehr über den Checkpoint, das Recovery und die Bereitstellung von Datenstreams.
Der öffentliche Auftrag pos
Jeder Nicht-Metadaten-DML- oder DDL-Datensatz enthält standardmäßig ein undurchsichtiges pos-Token. Intern enthält das Token genügend GoldenGate-Positionierungsinformationen, um einen Datensatz zu identifizieren, einschließlich Commit- oder Sequenzinformationen, Transaktionsidentität und Datensatzsequenzierung. Die Codierung ist kein öffentliches Quellkoordinatenformat und kann je nach Quelltyp und Release variieren.
| Ja | Nicht |
|---|---|
| Speichern Sie die genaue Zeichenfolge nach erfolgreicher Verarbeitung. | Parsen Sie sie, um eine Oracle SCN, PostgreSQL LSN, MySQL-Binlogkoordinate, SQL Server LSN oder einen anderen quellspezifischen Offset abzurufen. |
| Umfang für den Datenstream, den Quelltrailvertrag und den Consumer. | Vergleichen Sie Positionen lexikalisch oder numerisch, um die Reihenfolge zu bestimmen. |
Codieren Sie sie in Prozent, wenn Sie sie als begin in einer URL verwenden. |
Trimmen, normalisieren, verketten, entschlüsseln oder neu schreiben. |
Verwenden Sie separate Felder csn, xid, opSeqno und transInd für Diagnosen oder Transaktionsanalysen. |
Stellen aus einem anderen Stream, einem anderen Filtervertrag oder einer anderen Umgebung wiederverwenden |
Quellportabilität: Der Client-Recovery-Algorithmus ist absichtlich für Oracle, PostgreSQL, MySQL, SQL Server und andere unterstützte Quellen identisch: persistieren Sie das undurchsichtige pos, und geben Sie es unverändert zurück. Quellspezifisches Koordinatenparsing ist weder erforderlich noch wird es vom Data Streams-Clientvertrag unterstützt.
Ein Checkpoint muss den letzten Datensatz darstellen, dessen Geschäftseffekt dauerhaft ist. Das Speichern vor dem Schreiben des Unternehmens kann nach einem Absturz Daten verlieren. Das Speichern nach einem nicht-idempotentem Schreiben in einer separaten Transaktion kann nach einem Absturz ein Duplikat erzeugen.
End-to-End-Exact-Once-Muster
| Muster | Funktionsweise | Verwenden wenn |
|---|---|---|
| Atomare Sink- und Checkpoint-Transaktion | Schreiben Sie den Geschäftsdatensatz und die neue pos in dieselbe Datenbanktransaktion. |
Die Sink und der Checkpoint können einen Transaktionsdatenspeicher gemeinsam nutzen. |
| Idempotenzschlüssel | Verwenden Sie pos oder einen Geschäftsschlüssel plus Vorgangsidentität als eindeutigen Schlüssel. Die Wiederholung desselben Datensatzes wird zum No-op. |
Die Spüle unterstützt Eindeutigkeit oder bedingte Schreibvorgänge. |
| Dauerhaftes Staging-Log | Hängen Sie den Datensatz und pos atomar an ein dauerhaftes Log an, und verarbeiten Sie das Log dann unabhängig. |
Die Geschäftsverarbeitung ist langsam, mehrstufig oder umfasst Systeme. |
| Mindestens einmal mit Versöhnung | Akzeptieren Sie Duplikate, deduplizieren Sie regelmäßig, und stimmen Sie Zählungen oder Prüfsummen ab. | Der Anwendungsfall toleriert eine eventuelle Korrektur. |
HINWEIS: Data Stream exactlyOnce beschreibt die serviceseitige Unterdrückung von Duplikaten und die Recovery-Antwort. Es macht keine willkürliche nachgelagerte Nebenwirkung genau einmal, weil das WebSocket-Protokoll keine Transaktionsbestätigung pro Datensatz mit dem Client hat.
Quality of Service
Lesen Sie die Quality of Service-Richtlinien aus der folgenden Tabelle:
| Modus | Duplikat | Gespeicherte Position nicht verfügbar | Empfohlene Nutzung |
|---|---|---|---|
exactlyOnce |
Unterdrückt Duplikate, die während der Wiederherstellung und der Verarbeitung von Neustart/Abend des Quelltrails erkannt wurden. | Verbindung mit einem Fehler nicht erfolgreich. | Standard für dauerhafte Geschäftsverarbeitung. Pair mit atomarer oder idempotenter Consumer-Logik. |
atLeastOnce |
Unterdrückt keine Duplikate während der Wiederherstellung und der Verarbeitung von Neustart/Abend des Quelltrails. | Verbindung mit einem Fehler nicht erfolgreich. | Wird verwendet, wenn die Wiedergabe bevorzugt wird und der Consumer deduplizieren soll. |
atMostOnce |
Unterdrückt erkannte Duplikate. | Service sucht den nächsten verfügbaren Datensatz und fährt fort, wodurch Daten übersprungen werden können. | Nur verwenden, wenn Datenverlust explizit akzeptabel ist und Weiterleitungsfortschritt wichtiger ist als Vollständigkeit. |
Transaktionsmetadaten und -reihenfolge
Informationen zu Transaktionsmetadaten und Anforderungen an die Reihenfolge finden Sie in der folgenden Tabelle:
| Feld | Zweck | Einschränkungen |
|---|---|---|
xid |
Gruppiert Datensätze, die einer Quelltransaktion zugeordnet sind. | Das Format ist quellabhängig und sollte als Zeichenfolge behandelt werden. |
csn |
Gibt die Quell-Commit-Folgenummer bei der Konfiguration an. | Bedeutung und Format sind quellabhängig; nicht als Neustarttoken verwenden. |
opSeqno |
Datensatzfolgenummer innerhalb der Transaktion. | Aktivieren und optional explizit umbenennen. |
transInd |
B zuerst, M Middle, E last oder W Ganz-/Einzelvorgangstransaktion. |
Durch Filtern können Datensätze entfernt und die beobachtete Sequenz unvollständig gemacht werden. Eine koordinierte Verarbeitung kann auch den Nutzen verringern. |
pos |
Eindeutige Wiederherstellungsposition für den Datensatz. | Undurchsichtig; sortieren oder leiten Sie keine Transaktionsgrenzen aus ihrem Text ab. |
Gehen Sie nicht davon aus, dass eine Verbindung immer an einer Transaktionsgrenze beginnt. Eine Zeitstempelsuche oder eine beibehaltene Trailgrenze kann beginnen, nachdem frühere Vorgänge nicht mehr verfügbar sind. Wenn die Anwendung vollständige Quelltransaktionen erfordert, entwerfen Sie einen Transaktionspuffer, definieren Sie Limits für große Transaktionen, und geben Sie an, was zu tun ist, wenn der Beginn einer Transaktion nicht verfügbar ist.
Wenn eine gespeicherte Position nicht verfügbar ist
Um eine gespeicherte Position zu überprüfen, die nicht mehr verfügbar ist, gehen Sie wie folgt vor:
-
Vergewissern Sie sich, dass der Checkpoint zum selben Data Stream-, Quelltrail- und Filter-/Ausgabevertrag gehört.
-
Bestätigen Sie, dass der Wert in Prozent kodiert wurde, ohne geändert zu werden.
-
Vergewissern Sie sich, dass das Trailsegment, das die Position enthält, nicht gelöscht wurde.
-
Behandeln Sie den Fehler mit
exactlyOnceoderatLeastOnceals Recovery-Vorfall. Stellen Sie die Trailhistorie wieder her, wählen Sie einen genehmigten Zeitstempel oder die früheste Position, und stimmen Sie den nachgelagerten Status ab, bevor Sie fortfahren. -
Mit
atMostOncekann der Service beim nächsten verfügbaren Datensatz fortgesetzt werden. Erfassen Sie die daraus resultierende Datenlücke, und führen Sie die vom Unternehmen genehmigte Abstimmungsprozedur aus.
Trailaufbewahrungsplanung
Legen Sie die Trailaufbewahrung fest, um das Recovery Point Objective sowie die Betriebserkennung und Reaktionszeit zu überschreiten. Beispiel: Ein Consumer, der 24 Stunden offline sein kann und 12 Stunden für die Reaktion auf Vorfälle benötigt, benötigt mehr als 36 Stunden verfügbaren Trail, mit zusätzlicher Marge für große Backlogs und Wartung. bufferSize erweitert die Trailaufbewahrung nicht.