Allgemeine Informationen zu Openflow Connector for PostgreSQL¶

Wie Tabellen repliziert werden¶

1. Schema-Introspektion: Der Konnektor ermittelt die Spalten in der Quelltabelle, ihre Namen und Typen und validiert sie dann anhand der Beschränkungen von Snowflake und des Konnektors. Wenn die Validierung fehlschlägt, schlägt dieser Schritt fehl, und der Zyklus ist abgeschlossen. Nach erfolgreichem Abschluss der Schema-Introspektion erstellt der Konnektor eine leere Zieltabelle.

2. Laden des Snapshots: Der Konnektor kopiert alle in der Quelltabelle verfügbaren Daten in die Zieltabelle. Wenn dieser Schritt fehlschlägt, ist der Zyklus beendet und es werden keine weiteren Daten repliziert. Nach erfolgreichem Abschluss ist der gesamte Datensatz aus der Quelltabelle in der Zieltabelle verfügbar.

3. Inkrementelles Laden: Der Konnektor verfolgt die Änderungen in der Quelltabelle und kopiert sie in die Zieltabelle. Dies geschieht so lange, bis die Tabelle aus der Replikation entfernt wird. Bei einem Fehler in diesem Schritt wird die Replikation der Quelltabelle dauerhaft gestoppt, bis das Problem behoben ist.

   Bemerkung

   Dieser Konnektor kann so konfiguriert werden, dass er sofort mit der Replikation inkrementeller Änderungen für neu hinzugefügte Tabellen beginnt und damit die Phase des Ladens von Snapshots umgeht. Diese Option ist oft nützlich, wenn Sie den Konnektor in einem Konto erneut installieren, in dem zuvor replizierte Daten vorhanden sind, und Sie die Replikation fortsetzen möchten, ohne Tabellen neu erstellen zu müssen.

   Weitere Informationen zum Umgehen des Snapshot-Ladens und zur Verwendung des inkrementellen Ladeprozesses finden Sie unter Inkrementelle Replikation.

Unterstützung von TOASTed-Werten¶

Der Konnektor unterstützt das Replizieren von Tabellen mit TOAST-Werten für Spalten der Typen: array, bytea, json, jsonb, text, varchar, xml.

Immer, wenn der Konnektor auf einen TOASTed-Wert im CDC-Stream stößt, ersetzt er den Standardplatzhalter von __previous_value_unchanged, formatiert für den angegebenen Spaltentyp, und speichert ihn in der Journaltabelle. Die MERGE-Abfrage berücksichtigt dann Platzhalterwerte, sodass die Zieltabelle immer den letzten Nicht-TOASTed-Wert enthält.

Unterstützung von Werten außerhalb des Bereichs¶

Der Konnektor unterstützt das Replizieren von Tabellen mit Spalten des Typs date, timestamp``und ``timestamptz, die Werte außerhalb des Bereichs enthalten. Wenn der Konnektor im CDC-Stream auf einen Wert außerhalb des Bereichs stößt, ersetzt er einen Standardplatzhalter basierend auf dem Typ der Spalte.

Status der Tabellenreplikation¶

Zwischenzeitliche Fehler, wie z. B. Verbindungsfehler, verhindern nicht, dass Tabellen repliziert werden. Permanente Fehler, z. B. nicht unterstützte Datentypen, verhindern jedoch die Replikation von Tabellen.

Um Replikationsprobleme zu beheben oder sicherzustellen, dass eine Tabelle erfolgreich aus dem Replikationsablauf entfernt wurde, überprüfen Sie den Table State Store:

1. Klicken Sie in der Openflow-Laufzeitoberfläche mit der rechten Maustaste auf eine Prozessorgruppe und wählen Sie Controller Services. Es wird eine Tabelle mit den Controllerndiensten angezeigt.

2. Suchen Sie die Zeile mit der Bezeichnung Table State Store, klicken Sie rechts neben der Zeile auf die Schaltfläche More und wählen Sie View State.

Eine Liste der Tabellen und ihrer aktuellen Statusangaben wird angezeigt. Geben Sie einen Namen in das Suchfeld ein, um die Liste nach Tabellennamen zu filtern. Die möglichen Statusangaben sind:

• NEW: Die Replikation der Tabelle ist geplant, aber die Replikation wurde noch nicht gestartet.

• SNAPSHOT_REPLICATION: Der Konnektor kopiert vorhandene Daten. Dieser Status wird so lange angezeigt, bis alle Datensätze in der Zieltabelle gespeichert sind.

• INCREMENTAL_REPLICATION: Der Konnektor repliziert aktiv Änderungen. Dieser Status wird nach dem Ende der Snapshot-Replikation angezeigt und so lange, bis eine Tabelle entweder aus der Replikation entfernt wird oder die Replikation fehlschlägt.

• FAILED: Die Replikation wurde aufgrund eines Fehlers dauerhaft gestoppt.

Replication state for table <database_name>.<schema_name>.<table_name> changed from <old_state> to <new_state>

Wenn ein permanenter Fehler die Replikation der Tabelle verhindert, entfernen Sie die Tabelle aus der Replikation. Nachdem Sie das Problem behoben haben, das den Fehler verursacht hat, können Sie die Tabelle wieder zur Replikation hinzufügen. Weitere Informationen dazu finden Sie unter Replikation der Tabellen neu starten.

Metadatenspalten der Zieltabelle¶

Jede Zieltabelle enthält die folgenden Metadatenspalten, in denen Replikationsinformationen verfolgt werden:

Vorläufig gelöschte Zeilen¶

Wenn eine Zeile aus der Quelltabelle gelöscht wird, entfernt der Konnektor sie nicht physisch aus der Zieltabelle. Stattdessen wird die Zeile durch Festlegen der Metadatenspalte _SNOWFLAKE_DELETED auf true als gelöscht markiert.

Dieser Ansatz ermöglicht Folgendes:

• Aufbewahrung historischer Daten für Auditing- oder Compliance-Zwecke.

• Abfragen gelöschter Datensätze bei Bedarf.

• Anhand Ihrer Anforderungen entscheiden, wann und wie Daten dauerhaft entfernt werden sollen.

Um nur aktive (nicht gelöschte) Zeilen abzufragen, filtern Sie die Spalte _SNOWFLAKE_DELETED:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = FALSE;

So fragen Sie gelöschte Zeilen ab:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = TRUE;

Gelöschte Spalten¶

Wenn eine Spalte aus der Quelltabelle gelöscht wird, löscht der Konnektor die entsprechende Spalte nicht aus der Zieltabelle. Stattdessen wird die Spalte durch Anhängen des Suffix``__SNOWFLAKE_DELETED`` umbenannt, um historische Werte zu erhalten.

Wenn beispielsweise eine Spalte mit dem Namen``EMAIL`` aus der Quelltabelle gelöscht wird, wird sie in EMAIL__SNOWFLAKE_DELETED in der Zieltabelle umbenannt. Zeilen, die vor dem Löschen der Spalte vorhanden waren, behalten ihre ursprünglichen Werte, während Zeilen, die nach dem Löschen hinzugefügt wurden, den Wert NULL in dieser Spalte haben.

Sie können weiterhin historische Werte aus der umbenannten Spalte abfragen:

SELECT EMAIL__SNOWFLAKE_DELETED FROM my_table;

Umbenannte Spalten¶

Aufgrund von Einschränkungen desCDC (Change Data Capture)-Mechanismus kann der Konnektor nicht zwischen einer Spalte unterscheiden, die umbenannt wurde, und einer Spalte, die gelöscht wurde, gefolgt von einer neu hinzugefügten Spalte. Wenn Sie eine Spalte in der Quelltabelle umbenennen, behandelt der Konnektor dies daher als zwei separate Vorgänge: Löschen der ursprünglichen Spalte und Hinzufügen einer neuen Spalte mit dem neuen Namen.

Wenn Sie z. B. in der Quelltabelle eine Spalte von A in B umbenennen, enthält die Zieltabelle Folgendes:

• A__SNOWFLAKE_DELETED: Enthält Werte, wie sie vor dem Umbenennen vorhanden waren. Zeilen, die nach dem Umbenennen hinzugefügt werden, haben in dieser Spalte den Wert NULL.

• B: Enthält Werte, wie sie nach dem Umbenennen vorhanden sind. Zeilen, die vor dem Umbenennen vorhanden waren, haben in dieser Spalte den Wert NULL.

SELECT
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

SELECT
    CASE
        WHEN B IS NOT NULL THEN B
        ELSE A__SNOWFLAKE_DELETED
    END AS A_RENAMED_TO_B
FROM my_table;

CREATE VIEW my_table_unified AS
SELECT
    *,
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

Journaltabellen¶

Bei der inkrementellen Replikation werden Änderungen aus der Quelldatenbank zunächst in Journaltabellen geschrieben, bevor sie in den Zieltabellen zusammengeführt werden. Der Konnektor entfernt nicht automatisch Daten aus Journaltabellen, da diese Daten für Auditing-, Debugging- oder Wiederverarbeitungszwecke nützlich sein können.

Journaltabellen werden im gleichen Schema wie ihre entsprechenden Zieltabellen erstellt und folgen dieser Namenskonvention:

<TABLE_NAME>_JOURNAL_<timestamp>_<number>

Wobei:

• <TABLE_NAME> ist der Name der Zieldatenbank.

• <timestamp> ist der Zeitstempel der Erstellung im Unix-Epochenformat (Sekunden seit dem 1. Januar 1970), der die Eindeutigkeit gewährleistet.

• <number> beginnt bei 1 und wird immer dann erhöht, wenn sich das Schema der Zieltabelle ändert, entweder aufgrund von Schemaänderungen in der Quelltabelle oder aufgrund von Änderungen an den Spaltenfiltern.

Wenn Ihre Zieltabelle beispielsweise SALES.ORDERS ist, könnte die Journaltabelle SALES.ORDERS_JOURNAL_1705320000_1 heißen.