Yugabyte: Unterstützte Objekte und Vorgänge

In der folgenden Liste werden die unterstützten Objekte und Vorgänge für Oracle GoldenGate für Yugabyte beschrieben:

• Oracle GoldenGate Extract unterstützt das Plug-in yboutput.

• Die Replikatidentität CHANGE ist die native Einstellung für Yugabyte und wird empfohlen, wenn das Plug-in yboutput verwendet wird, da es im Vergleich zu anderen Replikatidentitätstypen eine bessere Performance bietet.

• Bidirektionale Replikation wird mit dem Plug-in yboutput unterstützt. Wenn Sie das Plug-in yboutput für die bidirektionale Replikation verwenden, muss die Oracle GoldenGate-Checkpoint-Tabelle erstellt und in die Veröffentlichungsliste aufgenommen werden, bevor Sie den CDC-Extraktionsprozess starten.

  Darüber hinaus sollte der Replikations-Slot erst erstellt werden, nachdem die Checkpoint-Tabelle erstellt und der Publikation hinzugefügt wurde.

• Bidirektionale Replikation wird mit dem Plug-in test_decoding unterstützt. Alle Tabellen einschließlich der Checkpoint-Tabellen müssen erstellt werden, bevor Extract registriert wird, wenn das Plug-in test_decoding verwendet wird. Bei PGOUTPUT-Plug-in muss die Checkpoint-Tabelle zusammen mit allen anderen interessierten Tabellen vor der Extract-Registrierung in die Publikation aufgenommen werden.

Hinweis: Löschen Sie keine Tabelle, einschließlich Checkpoint-Tabellen.

• Mehrere Truncate-Vorgänge werden nur im Plug-in pgoutput/yboutput unterstützt.

• Registrieren Sie den Befehl mit der Option pgplugintype:

  • Die Option pgplugintype ist sowohl in der Weboberfläche als auch im Admin-Client unter dem Befehl REGISTER EXTRACT verfügbar. Mit dieser Option können Sie entweder test_decoding oder pgoutput als logisches Decodierungs-Plug-in auswählen.

  • Wenn Sie pgplugintype pgoutput angeben, verwendet das zugrunde liegende Modul automatisch das Plug-in yboutput, um den Extract-Prozess zu registrieren.

  • Wenn Sie keine pgplugintype angeben, registriert sich der CDC-Extrakt standardmäßig mit dem Plug-in test_decoding.

  • Um sich explizit beim Plug-in yboutput in Yugabyte zu registrieren, müssen Sie den Plug-in-Typ pgoutput angeben.

  Syntax:

    <pre class="copy"><code>REGISTER EXTRACT *group_name* PGPLUGINTYPE *plugin_option*;</code></pre>
  

  Beispiel:

    <pre class="copy"><code>REGISTER EXTRACT ext_yb PGPLUGINTYPE pgoutput;</code></pre>
  

• Der Parameter STREAMINGOPTIONS wurde unter TRANLOGOPTIONS eingeführt. Mit diesem Parameter können Sie die publication_name für den Replikationsstartbefehl angeben.

  Beispiel:

  TRANLOGOPTIONS STREAMINGOPTIONS (publication_names="my*123,my_publication2,123 pub,my_publication";)

  Bei der Verwendung dieses Parameters müssen die folgenden Richtlinien und Einschränkungen beachtet werden:

  • Die Publikation(en) muss(n) erstellt werden, bevor der Extract-Prozess registriert wird.

  Veröffentlichungsnamen dürfen keine Sonderzeichen enthalten, einschließlich Komma (,) Einfaches Anführungszeichen (') Doppeltes Anführungszeichen (").

  • Mehrere Publikationsnamen können in publication_names als durch Komma getrennte Liste angegeben werden. Beispiel:

    TRANLOGOPTIONS STREAMINGOPTIONS (publication_names="my*123,my_publication2,123 pub,my_publication";)

  Der endgültige Veröffentlichungsname in der Liste muss mit einem Semikolon (;) enden

Einschränkungen bei Yugabyte

Beachten Sie die folgenden Einschränkungen für die Yugabyte-Datenbank, während Sie sie für die Erfassung und Bereitstellung einrichten:

• Fehlende große LOB-Transaktionen: Wenn ein LOB (Large Object) eine Größe zwischen 200 MB und 400 MB hat, fehlt möglicherweise die gesamte Transaktion, unabhängig davon, ob INSERT oder UPDATE, im CDC-Stream.

• Nicht übereinstimmende Daten im Downstream aufgrund mehrerer Aktualisierungen in derselben Transaktion: Wenn mehrere Aktualisierungen innerhalb derselben Transaktion stattfinden, kann das Modul CDCSDK in Yugabyte möglicherweise das korrekte AFTER-Image nicht senden, wenn die Replikatidentität der Tabelle auf FULL oder DEFAULT gesetzt ist. Dies kann zu Datenabweichungen für das AFTER-Image im Downstream-System führen.

• Replikationsverbindung wird beendet, nachdem DDL in replizierten Tabellen (test_decoding-Plug-in) beendet wurde: Wenn Sie das Plug-in test_decoding verwenden, werden standardmäßig alle Tabellen in der Datenbank automatisch in die Polling-Liste aufgenommen. Wenn ein DDL-Vorgang (wie ein Tabellenlöschvorgang) für eine beliebige Tabelle in dieser Liste ausgeführt wird, beendet der Server die Replikationsverbindung. Das Löschen von Tabellen, die Teil der Polling-Liste sind, wird jedoch nicht mit dem Plug-in test_decoding unterstützt. Wenn Sie diese Flexibilität benötigen, müssen Sie zum Plug-in yboutput wechseln.

  Hinweis: Stellen Sie vor dem Löschen einer Tabelle sicher, dass sie nicht Bestandteil einer Publikation ist, um Replikationsfehler oder Verbindungsunterbrechungen zu vermeiden. Ebenso sollten Sie die Oracle GoldenGate-Checkpoint-Tabelle nicht löschen, da dies ebenfalls zu demselben Fehler führt.

• Ablauf von Replikationseinschubfächern aufgrund erweiterter Inaktivität: Replikationseinschubfächer behalten bestimmte Ressourcen bei, um die Garbage Collection von WAL-(Write-Ahead-Log-)Datensätzen zu verhindern, die für die Replikation erforderlich sind. Wenn ein Slot über einen längeren Zeitraum inaktiv bleibt, wird er als abgelaufen markiert, und die beibehaltenen Ressourcen werden freigegeben. Nach Ablauf wird der Replikations-Slot unbrauchbar und muss neu erstellt werden.

  Standardaufbewahrungsfenster:

  • 8 Stunden ab Version 2024.2.1

  • 4 Stunden in Versionen vor 2024.2.1

  Dies ist ein bekanntes Problem, wie auf der Yugabyte-Website erwähnt:

  https://github.com/yugabyte/yugabyte-db/issues/27766

  Empfohlene Maßnahmen zur Verhinderung des Ablaufs:

  • Aktivieren Sie die Heartbeat-Funktionalität, um eine kontinuierliche WAL-Aktivität sicherzustellen und lange Leerlaufzeiten zu vermeiden.

  • Konfigurieren Sie die Optionen autostart oder autorestart für den CDC-Prozess, sodass er automatisch eine neue Verbindung zum Modul CDCSDK herstellt, Ausfallzeiten minimiert und den Ablauf von Einschubfächern verhindert.

• BatchSQL funktioniert nicht ordnungsgemäß, wenn BatchMechanism 3 mit dem Progress-DDD-Treiber festgelegt ist. Dies ist der Standard für den Replicat-Prozess für Yugabyte. Wenn Sie also BatchSQL verwenden müssen, müssen Sie die Einstellung DBOPTIONS _BatchMechanism 2 in der Replicat-Parameterdatei für die korrekte Funktionalität konfigurieren. Diese Workaround kann für den Replicat-Prozess in Oracle GoldenGate 23.10 und höher für Yugabyte angewendet werden.

• Nur Tabellen, die veröffentlicht werden können: Persistente Basistabellen und partitionierte Tabellen können in einer Publikation enthalten sein. Die folgenden Objekttypen können nicht Teil einer Publikation sein:

  • Temporäre Tabellen

  • Nicht protokollierte Tabellen

  • Fremdtabellen

  • Materialized Views

  • Reguläre Ansichten

• Auswirkung auf das Löschen von Veröffentlichungen auf CDC Extract: Wenn eine Veröffentlichung gelöscht wird, während der CDC Extract noch ausgeführt wird, besteht das Risiko einer Beschädigung des Replikationseinschubfachs, sodass sie nicht mehr funktioniert. In solchen Fällen wird der betroffene Replikations-Slot unbrauchbar, und die einfache Neuerstellung derselben Publikation löst das Problem nicht. Für den vorhandenen Stream gibt es keine Lösung, und nur eine neue Publikation erstellen und mit einem neuen Replikations-Slot verknüpfen.

• Einschränkungen mit Zeitzone (TZ): Der WAL-Senderprozess überträgt festgeschriebene Zeitstempel immer in UTC. Wenn die Zeitzone der Oracle GoldenGate-Session von UTC abweicht, können bei der Positionierung nach Zeitstempel im CDC-Extraktionsprozess Abweichungen auftreten. Um dieses Problem zu vermeiden, müssen Sie die Umgebungsvariable TZ=UTC auf der Deployment-Schicht festlegen. Diese Einschränkung gilt speziell für das Plug-in yboutput.

• pgoutput-Plug-in wird für Yugabyte nicht unterstützt.

• Globalisierung wird mit dem Plug-in yboutput nicht unterstützt

• Primärschlüssel in Tabelle: Nur Tabellen mit einem Primärschlüssel werden für CDC-Streaming in Yugabyte unterstützt. Die Tabelle, die nicht über den Primärschlüssel verfügt, wird nicht von Oracle GoldenGate CDC Extract erfasst.

• Primärschlüsselaktualisierungen in Yugabyte: Ein PK-UPDATE in Yugabyte wird als DELETE gefolgt von INSERT protokolliert. Oracle GoldenGate Extract zeigt nur die Statistiken für ein PK UPDATE als DELETE und INSERT an. Die Statistiken werden zwar nicht als Aktualisierungsvorgang in den Extract-Statistiken angezeigt, es gibt jedoch keine Diskrepanzen in den Daten auf Quelle und Ziel.

• Replikatidentitätsverhalten: Die Replikatidentität von Tabellen, die zum Zeitpunkt der Sloterstellung vorhanden sind, kann nicht geändert werden, nachdem der Slot erstellt wurde. Die Replikatidentität aller neuen Tabellen, die nach der Sloterstellung erstellt wurden, kann jedoch mit dem Flag ysql_yb_default_replica_identity, cdcsdk_publication_list_refresh_interval_secs und csdk_enable_dynamic_table_support tserver festgelegt werden. Diese Flags müssen im Master und t-server festgelegt werden, bevor neue Tabellen erstellt werden.

  Standardmäßig ist cdcsdk_publication_list_refresh_interval_secs auf 900 Sek. (15 Minuten) gesetzt. Sie müssen dies gemäß Ihrer Anforderung festlegen. Wenn der Wert verringert wird, wird die neu erstellte Tabelle, die im CDCSDK-Modul aktualisiert werden soll, schnell reduziert. Dadurch kann Oracle GoldenGate alle Datensätze für diese neuen Tabellen erfassen. Das folgende Beispiel zeigt die Flags, die für dynamisch erstellte Tabellen festgelegt werden, nachdem das SLOT erstellt wurde:

  ysql_yb_default_replica_identity=FULL,cdcsdk_publication_list_refresh_interval_secs=120,cdcsdk_enable_dynamic_table_support=true

• Positionierung nach Ende des Logs (EOL) oder Ende der Datei (EOF) wird nicht unterstützt: Anstelle von EOL/EOF können Sie die Slotposition nach aktuellem Zeitstempel ändern, wodurch die vorhandenen Datensätze gefiltert werden.

• Truncate-Vorgang: Parameter wie GETTRUNCATES/IGNORETRUNCATES werden nicht unterstützt, da der Benutzer die Tabelle nicht abschneiden kann, wenn sie für das Change Data Capture aktiviert sind.

• WAL-Aufbewahrung: Yugabyte löscht normalerweise WAL-Segmente nach einem bestimmten Zeitraum. Das bedeutet, dass Oracle GoldenGate die WAL-Logdaten verlieren kann, wenn die Logs abgeschnitten werden, wenn der Extract länger heruntergefahren ist. Die WAL-Aufbewahrung wird in Yugabyte erst garantiert, wenn einige Parameter wie cdc_intent_retention_ms und cdc_wal_retention_time_secs so angepasst wurden, dass die WAL-Logs länger beibehalten werden. Dies muss auf allen Knoten oder Clustern angepasst werden, auf denen der Oracle GoldenGate Extract-Prozess ausgeführt wird.

  Folgende Werte werden empfohlen:

  cdc_wal_retention_time_secs=86400

  cdc_intent_retention_ms = 86400000

• UNREGISTER EXTRACT-Befehl: Oracle GoldenGate verwendet den Befehl UNREGISTER EXTRACT, um den Replikationsslot zu löschen. Ein Replikations-Slot kann nur gelöscht werden, nachdem der Client, der davon konsumiert wird, mindestens für die Dauer von ysql_cdc_active_replication_slot_window_ms gestoppt wurde. Der Standardwert des Flags ist 5 Minuten. Das bedeutet, dass Sie auf das maximale Zeitfenster warten müssen, für das ein Replikations-Slot inaktiv bleiben kann, bevor er als veraltet betrachtet wird.

  Bei einem Cluster-Setup muss dieser Parameter in allen Knoten mit demselben Wert angepasst werden.

• BLOB/CLOB-Einschränkungen: Der Datentyp wie Text/Bild hat die Beschränkung, nur 200 MB Daten zu erfassen. Die Zeilengröße darf die 32 MB nicht überschreiten, und jede Spalte mit den LOB-Daten sollte bis zu 2 MB beibehalten werden.

  https://docs.yugabyte.com/stable/develop/best-practices-ysql/#row-size-limit

• Einschränkungen mit SAVEPOINT und Rollback in DML-Vorgängen: Oracle GoldenGate CDC Extract unterstützt die Rollback-Vorgänge SAVEPOINT nicht. Das CDC-Plug-in test_decoding berücksichtigt keine ROLLBACK TO SAVEPOINT-Befehle. Infolgedessen werden Datensätze, die aufgrund eines Rollbacks ausgeschlossen werden sollten, weiterhin vom Extract erfasst und verarbeitet.

  Dieses Verhalten ist eine bekannte Einschränkung des Yugabyte CDC SDK-Moduls. Weitere Informationen finden Sie unter den folgenden Links:

  https://yugabyte.atlassian.net/browse/DB-11714

  https://docs.yugabyte.com/stable/develop/change-data-capture/using-logical-replication/#limitations

• Begrenzung beim Löschen der Tabelle: Nachdem ein Slot erstellt wurde, darf der Benutzer keine Tabelle aus der Datenbank löschen, bis der Slot gelöscht wurde. Wenn der Slot aktiv ist und der Benutzer versucht, eine Tabelle aus der Datenbank zu löschen, kann CDC Extract keine Datensätze aus anderen CDC-Tabellen erfassen, die Teil der Replikation sind. Außerdem wird empfohlen, dass beim Ausführen von CDC-Extraktion auch der Benutzer keine Tabelle in der Datenbank löschen darf, in der der Slot erstellt wird. Wenn Sie dies nicht tun, wird CDC Extract mit dem Trennungsfehler wie folgt beendet:

  Error: The server has ended the streaming connection.

• Einschränkung auf statement_timeout: Der Yugabyte-Parameter statement_timeout darf nicht auf Benutzer- oder Datenbankebene geändert werden und sollte standardmäßig beibehalten werden. Wenn dieser Wert auf einen niedrigeren Wert gesetzt ist, kann der CDC-Extrakt die Datensätze nicht aus der WAL lesen. Falls erforderlich, sollte die Einstellung immer nur auf Session-Ebene erfolgen.

• Das Erstellen eines Einschubfachs im Replikatknoten mit schreibgeschütztem Modus wird nicht unterstützt: Der CDC-Extrakt kann die Datensätze nicht vom Replikatknoten erfassen. Dies liegt daran, dass die von uns unterstützte Version wie 2024.2.1.0 oder 2024.2.2.0 auf PostgreSQL 11.2 basiert, was die Erstellung des Slots im Replikatknoten nicht unterstützt.