Openflow Connector for MySQL: Verwaltung¶
Bemerkung
Dieser Connector unterliegt den `Nutzungsbedingungen für Snowflake Connector<https://www.snowflake.com/legal/snowflake-connector-terms/>`_.
Unter diesem Thema werden wichtige Hinweise zur Wartung und bewährte Verfahren für die Openflow Connector for MySQL-Wartung bereitgestellt, wie z. B. die Neuinstallation des Konnektors oder das Festlegen der Startposition für das binäre Protokoll zum Laden.
Diese Operationen werden oft in Verbindung mit Inkrementeller Replikation mit Snapshots verwendet.
Konnektor erneut installieren¶
In diesem Abschnitt finden Sie eine Anleitung, wie Sie den Konnektor neu installieren und weiterhin Daten für dieselben Tabellen replizieren können, ohne erneut Snapshots erstellen zu müssen. Dies deckt Situationen ab, in denen der neue Konnektor in derselben Laufzeitumgebung installiert wird oder wenn er in eine neue Laufzeitumgebung verschoben wird.
Warnung
Damit der Konnektor weiterhin von derselben CDC Stream-Position replizieren kann, an der er vor der Neuinstallation angehalten wurde, muss die Quelldatenbank das Binärprotokoll lange genug beibehalten, um die Zeit zwischen dem Anhalten des vorherigen Konnektors und dem Starten des neuen Konnektors abzudecken. Stellen Sie sicher, dass der Parameter binlog_expire_logs_seconds des MySQL-Servers hoch genug ist, und beschränken Sie die Neuinstallationszeit auf ein Minimum.
Der Wert von binlog_expire_logs_seconds muss länger sein als die für die Neuinstallation des Konnektors erwartete Zeit. Normalerweise sind 86.400 s (ein Tag in Sekunden) ausreichend, jedoch können auch längere Zeitvorgaben für eine Neuinstallation angemessen sein.
Voraussetzungen¶
Überprüfen und notieren Sie die Kontextwerte der Konnektorparameter. Wenn Sie den Konnektor in derselben Laufzeit neu installieren, können Sie den vorhandenen Kontext wiederverwenden. Wenn sich die neue Instanz in einer anderen Laufzeitumgebung befindet, müssen Sie alle Parameter neu eingeben.
Schließen Sie die Verarbeitung aller in Übertragung befindlichen FlowFiles im bestehenden Konnektor ab und stoppen Sie dann den Konnektor.
Melden Sie sich bei Snowsight an.
Wählen Sie im Navigationsmenü die Option Ingestion » Openflow aus.
Wählen Sie im Bereich Openflow die Registerkarte Runtimes aus.
Wählen Sie die Laufzeitumgebung aus, die den Konnektor enthält.
Wählen Sie den Konnektor aus.
Stoppen Sie den obersten Prozessor Set Tables for Replication in der Gruppe Snapshot Load.
Stoppen Sie den obersten Prozessor Read MySQL CDC Stream in der Gruppe Incremental Load.
Wenn Sie den Wert des Parameters Merge Task Schedule CRON geändert haben, geben Sie ihn an
* * * * * ?zurück, andernfalls werden die Warteschlangen erst bei der nächsten geplanten Ausführung geleert.Warten Sie, bis alle FlowFiles im Konnektor verarbeitet wurden und alle Warteschlangen leer sind. Wenn alle FlowFiles verarbeitet wurden, wird der Wert Queued für die Prozessorgruppe des Konnektors zu Null. Wenn sich noch Elemente in den Warteschlangen des ursprünglichen Konnektors befinden, kann es beim Starten des neuen Konnektors zu Datenlücken kommen.
Stoppen Sie alle Prozessoren und Controller-Dienste im Konnektor.
Vorsicht
Der bestehende Konnektor kann in der Laufzeit verbleiben und beeinträchtigt die neue Instanz nicht, solange sie angehalten bleibt.
Erstellen Sie eine neue Instanz des Konnektors. Wenn Sie dieselbe Laufzeitumgebung wie der ursprüngliche Konnektor verwenden, können Sie die vorhandenen Parameterkontexte beibehalten und die Einstellungen wiederverwenden.
Wenn Sie in eine andere Laufzeitumgebung installieren oder die vorherigen Parameterkontexte gelöscht haben, geben Sie die Konfigurationseinstellungen in die neuen Parameterkontexte ein, einschließlich der Tabellennamen und Muster, wie unter Einrichten von Openflow Connector for MySQL beschrieben.
Navigieren Sie zum
MySQL Ingestion Parameters-Kontext, und legen Sie die folgenden Parameter fest:Setzen Sie den Parameter
Ingestion Typeaufincremental. Weitere Informationen zu den Problemen finden Sie unter Aktivieren der inkrementellen Replikation ohne Snapshots.Setzen Sie den Parameter
Starting Binlog PositionaufEarliest. Weitere Informationen und mögliche Bedenken finden Sie unter Angeben der Position des Binärprotokolls für den Ladevorgang.
Starten Sie den neuen Konnektor.
Nutzungshinweise¶
Der neue Konnektor verwendet die vorhandenen Zieltabellen, die vom ursprünglichen Konnektor erstellt wurden, erstellt jedoch neue Journaltabellen.
Angeben der Position des Binärprotokolls für den Ladevorgang¶
Mit dem Openflow Connector for MySQL-Konnektor können Sie die Startposition auswählen, ab der MySQL-Binärprotokolle gelesen werden. Standardmäßig beginnt der Konnektor den Lesevorgang an der letzten verfügbaren Position. Alternativ können Sie auch die früheste verfügbare Position in der Quellinstanz auswählen. Bei der Neuinstallation des Konnektors ist es üblich, an der frühesten Position zu beginnen. Dadurch kann die neue Instanz bestehende Tabellen auffinden und weiter replizieren, ohne jeweils einen erneuten Snapshot erstellen zu müssen.
Beachten Sie, dass das Umschalten eines aktiven Konnektors von der letzten zur frühesten Position dazu führt, dass das gesamte verfügbare Binärprotokoll neu gelesen, neu verarbeitet und erneut auf die Zieltabelle angewendet wird.
Warnung
Während das Binärprotokoll neu gelesen wird, können die Spalten und Daten in den betroffenen Zieltabellen nicht mehr mit ihren Quellen synchronisiert werden, bis alle Ereignisse neu verarbeitet und zusammengeführt wurden.
Die folgenden Parameter steuern das Laden von Snapshots und sind im Ingestion Parameters-Kontext verfügbar:
Parameter |
Beschreibung |
|---|---|
Startposition für Binlog |
|
Erneutes Lesen von Tabellen im Status |
|
So stellen Sie fest, ob der Konnektor das erneute Lesen des Binärprotokolls beendet hat:
Navigieren Sie zur Openflow-Arbeitsoberfläche.
Öffnen Sie die Prozessgruppe Incremental Load.
Klicken Sie mit der rechten Maustaste auf den obersten Prozessor namens Read MySQL CDC Stream. Wählen Sie anschließend View state aus.
Vergleichen Sie die Statuseinträge:
binlog.position.rewind: die letzte Position, die der Prozessor vor dem erneuten Lesen des Binärprotokolls gelesen hat.
binlog.position.dml: die aktuell letzte vom Prozessor gelesene Position. Solange dieser Wert niedriger ist als der obige Rücklaufwert, befindet sich der Prozessor noch beim erneuten Lesen des Binärprotokolls.
Nutzungshinweise¶
Nachdem ein aktiver Konnektor auf das Lesen von der frühesten Position umgestellt wurde und gestartet wird, kann der Prozess nicht mehr neu konfiguriert oder abgebrochen werden und wird fortgesetzt, bis der aktuelle Lesevorgang die Position von vor dem Start erreicht hat.
Wenn Sie zur frühesten Position eines aktiven Konnektors wechseln, werden für alle Tabellen, die erneut verarbeitet werden, die vorhandenen Journale beendet und neue Journaltabellen erstellt.
Wenn das Binärprotokoll Ereignisse aus einer früheren Tabelle enthält, die gelöscht und in der Quelldatenbank neu erstellt wurde, werden beim erneuten Lesen des Streams alle Ereignisse im aktuellen Ziel erneut verarbeitet. Der Konnektor kann nicht zwischen einer früheren und einer aktuellen Quelltabelle unterscheiden, wenn sie denselben Namen aufweisen.