Allgemeine Informationen zu Openflow Connector for SQL Server¶

Datenreplikation¶

Der Konnektor unterstützt das Replizieren von Tabellen aus mehreren SQL-Serverdatenbanken in einer einzigen SQL-Serverinstanz. Der Konnektor erstellt replizierte Tabellen aus verschiedenen Datenbanken in separaten Schemas innerhalb der Snowflake-Zieldatenbank.

Referenziert replizierte Tabellen, indem der Name der Quelldatenbank, der Name des Quellschemas und der Tabellennamen im folgenden Format kombiniert werden:

<database_name>.<schema_name>.<table_name>

Für jedes Schema in jeder zu replizierenden Quelldatenbank erstellt der Konnektor ein separates Schema in der Snowflake-Zieldatenbank. Der Name des Zielschemas ist eine Kombination aus dem Namen der Quelldatenbank und dem Namen des Quellschemas, getrennt durch einen Unterstrich (_), wie im folgenden Beispiel gezeigt:

<source_database_name>_<source_schema_name>

Der Konnektor erstellt im Zielschema Tabellen mit demselben Namen wie der Name der Quelltabelle, wie im folgenden Beispiel gezeigt:

<destination_database>_<destination_schema_name>.<source_table_name>

Replizieren von Tabellen¶

Der Konnektor repliziert Tabellen in den folgenden Phasen:

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

2. Laden von Snapshots: Der Konnektor kopiert alle in der Quelltabelle verfügbaren Daten in die Zieltabelle. Wenn diese Phase fehlschlägt, beendet der Konnektor die Replikation der Daten. Nach erfolgreichem Abschluss sind die Daten aus der Quelltabelle in der Zieltabelle verfügbar.

3. Inkrementelles Laden: Der Konnektor verfolgt Änderungen in der Quelltabelle und wendet diese Änderungen auf die Zieltabelle an. Dieser Vorgang wird fortgesetzt, 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.

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

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.