In der Produktionspraxis haben viele Studenten aus bestimmten Gründen Sicherungs-, Datensynchronisierungs- oder Datenmigrationsvorgänge für die MySQL-Datenbank oder Datentabelle über den Befehl mysqldump durchgeführt. Tatsächlich gibt es viele Synchronisationsszenarien, die eine Datenbankmigration beinhalten, wie zum Beispiel die folgenden Diese Szenarien :

Höhere Gewalt, der Server, auf dem sich die Datenbank befindet, wird recycelt oder die Serverfestplatte ist beschädigt, die Datenbank muss migriert werden?

Der Lese- und Schreibdruck der Einzelpunktdatenbank nimmt zu. Müssen Sie einen oder mehrere Knoten erweitern, um den Lese- und Schreibdruck zu teilen?

Die Datenmenge in einer einzelnen Tabelle ist zu groß. Was soll ich tun, wenn sie horizontal oder vertikal aufgeteilt werden muss?

Die Datenbank muss von MySQL auf andere Datenbanken wie PG, OB usw. migriert werden.

Für viele Studenten hängen die oben genannten Szenarien möglicherweise mehr oder weniger mit dem Geschäft zusammen, in dem sie tätig sind. Es ist in Ordnung, wenn sie noch nicht darauf gestoßen sind. Wenn solche Probleme auftreten, wie geht man damit um? In diesem Artikel wird ein gewisser Raum für eine ausführliche Diskussion in Kombination mit Erfahrungen aus der Produktionspraxis verwendet.

2. Datenmigrationsszenario

Im Allgemeinen haben verschiedene Geschäftsszenarien unterschiedliche Modi und Anforderungen für die Datenmigration. Einige erfordern eine Migration der gesamten Datenbank auf Serverebene, andere müssen nur Tabellendaten migrieren und einige migrieren möglicherweise nur die Datenbank Folgende Zusammenfassung mehrerer Szenarien der Datenmigration basierend auf praktischen Erfahrungen in der Produktion.

2.1 Migration der gesamten Datenbank

Die Hauptgründe für die Notwendigkeit, die gesamte Datenbank zu migrieren, sind:

Der Server wird recycelt;
Unzureichender Speicherplatz;
Festplattenbeschädigung;
Die Microservice-Transformation des Projekts erfordert eine Aufteilung der Datenbank ...

Eine vollständige Datenbankmigration ist üblich, wenn die Datenbank auf einer physischen Maschine bereitgestellt wird. Die physische Maschine kann jedoch aus bestimmten Gründen recycelt werden oder die Festplatte kann beschädigt sein, sodass die Datenbank auf der physischen Maschine als Ganzes migriert werden muss.

In einigen Szenarien kann es zur Wiederherstellung des Produktionsproblemszenarios, aber wenn die Entwicklungs- oder Testumgebung nicht reproduziert werden kann, auch zur Migration der gesamten Datenbankdaten kommen, und es ist erforderlich, eine Kopie der Produktionsdaten auf eine zu migrieren selbstgebaute Maschine.

2.2 Tabellendatenmigration

Ich weiß nicht, ob Sie auf die folgenden Szenarien gestoßen sind:

Die Struktur der Produktionstabelle hat sich geändert, z. B. durch das Hinzufügen neuer Felder, aber Sie möchten die Aktualisierung nicht stoppen.
Die Datenmenge in einer bestimmten Tabelle ist zu groß, was zu einem Leistungsengpass des Systems geworden ist und die Daten in der Datentabelle horizontal oder vertikal aufgeteilt werden müssen.
Wenn sich das Projekt ändert, müssen die Daten einer bestimmten Tabelle in einer bestimmten Datenbank vollständig in eine andere Datenbank migriert werden.

Die Migration von Tabellendaten erfolgt normalerweise, wenn das Datenvolumen einer einzelnen Tabelle segmentiert werden muss. Zu diesem Zeitpunkt sind bestimmte Mittel erforderlich, bei denen es sich um Tools, SQL-Skripte, gespeicherte Prozeduren oder sogar externe Programme handeln kann.

2.3 MySQL-Versionsänderung

In der bisherigen Erfahrung des Editors wurde MySQL in der Produktionsumgebung von 5.7 auf 8.X aktualisiert. Aufgrund der großen Unterschiede in der Zeichensatzcodierung und anderen Aspekten von Datenbanken verschiedener Versionen werden die Daten der niedrigeren Version direkt verwendet als höhere Version. Um es zu verwenden, habe ich viele Wendungen erlebt. Nach einigen Fallstricken habe ich es endlich fertiggestellt. Wenn es darum geht, Versionen von MySQL oder anderen relationalen Datenbanken zu aktualisieren, ist die Wahrscheinlichkeit einer Datenmigration hoch wird beteiligt sein.

2.4 Migrieren Sie MySQL-Daten auf andere Speichermedien

Wenn beispielsweise die Struktur des Produkts angepasst wird, werden die Geschäftsdaten vor der Anpassung in einer relationalen Datenbank wie MySQL gespeichert. Nach der Anpassung der Struktur müssen die Daten doppelt geschrieben werden, z. B. in es, Mongo , hbase und andere Speichermedien. Um das neu hinzugefügte Speichermedium so schnell wie möglich nutzen zu können, müssen die MySQL-Daten an das neue Speichermedium angepasst werden, was eine Datenmigration beinhaltet. Dies ist ein häufiges Szenario in der tatsächlichen Produktion.

2.5 Selbst erstellte Daten in die Cloud-Umgebung

In den ersten Jahren vor der vollständigen Einführung der Public Cloud kauften viele Unternehmen ihre eigenen Server, um ihre eigenen Datenbanken aufzubauen, oder Unternehmen einer bestimmten Größe bauten ihre eigenen Computerräume und Rechenzentren. Mit dem Aufstieg und der weiten Verbreitung öffentlicher Clouds Sobald sich der Dienst in der Cloud befindet, muss er unweigerlich mit der Datenmigration selbst erstellter Daten in die Cloud-Umgebung konfrontiert werden.

2.6 MySQL-Daten an andere inländische Datenbanken

In den letzten Jahren haben viele Internetunternehmen aufgrund des Einflusses der externen Umgebung Sicherheitsprobleme aufgeworfen, und viele inländische Datenbanken wie GAUSS, Dameng usw. sind auf dem Vormarsch. Für die Systeme, die in Produktion genommen wurden, in Ordnung Um mit inländischen Datenbanken kompatibel zu sein, müssen Sie zwangsläufig MySQL-Daten in diese lokalisierten Datenbanken migrieren.

3. Implementierungsplan für die physische Datenbankmigration

Oben werden einige gängige Szenarien, in denen es zu einer Datenmigration kommen kann, detaillierter zusammengefasst. Für verschiedene Szenarien unterscheiden sich auch die Strategien zur Bewältigung spezifischer Datenmigrationen, und es ist schwierig, in der Branche eine Reihe allgemeiner Strategien zu haben In Kombination mit tatsächlicher Produktionserfahrung finden Sie hier einige relativ realisierbare Lösungen und Ideen als Referenz.

3.1 Überblick über die physische Datenbankmigration

Die physische Migration eignet sich für die Gesamtmigration großer Datenmengen. Sie können die Originaldatendateien direkt kopieren oder das Navicat-Client-Tool für die Backup-Migration verwenden. Die physische Migration zwischen verschiedenen Servern erfordert die Beibehaltung der gleichen Version, Konfiguration und Berechtigungen des MySQL-Servers auf beiden Servern.

Der Vorteil dieser Art der physischen Migration besteht darin, dass sie schnell geht, der Nachteil besteht jedoch darin, dass die Konfiguration des neuen Servers genau mit der des ursprünglichen Servers übereinstimmen muss. Dennoch können einige unbekannte Fehler auftreten.

3.1.1 Anwendbare Szenarien für physische Migration

Es eignet sich für die Gesamtmigration großer Datenmengen, beispielsweise für die Datenmigration zum vollständigen Serveraustausch.

3.1.2 Körperliche Vor- und Nachteile

Vorteil

Die Migrationsgeschwindigkeit ist relativ hoch, ohne dass die Details der Daten berücksichtigt werden müssen

Mangel

Um die Datenkonsistenz vor und nach der Migration sicherzustellen, sind möglicherweise Ausfallzeiten erforderlich, die nicht flexibel genug sind und unbekannte Fehler schwer vorherzusagen sind

Anschließend werden anhand eines Falles die vollständigen Schritte der physischen Migration demonstriert.

3.2 Kopieren Sie Datendateien für die physische Migration

Vorbereitung

1. Zwei Server, jeweils IP1 und IP2;

2. Bereiten Sie im Voraus die MySQL-Umgebung auf den beiden Servern vor, die schnell mit Docker erstellt werden kann.

3.2.1 Übersicht über die Datendateireplikation

Schüler, die die MySQL-Datenbank verwendet haben, sollten mit MySQL-Datenspeicherdateien vertraut sein. Am Beispiel von 5.7 werden für eine bestimmte Datenbank viele Dateiverzeichnisse für diese Datenbank im MySQL-Datenverzeichnis erstellt, z. B. ibd zum Aufzeichnen von Tabellendatendateien , FRM-Dateien, die Tabelleninformationen usw. beschreiben.

Um eine Datenmigration durch Kopieren von Datendateien zu erreichen, müssen Sie daher theoretisch nur eine vollständige Kopie der Datenverzeichnisdatei der Datenbank erstellen und das MySQL-Datenverzeichnis und die Struktur des Zielcomputers beibehalten.

3.2.2 Erstellen Sie eine Datenbank auf der ersten Maschine

Erstellen Sie eine Datenbank db_emp auf dem IP1-Computer, erstellen Sie eine Tabelle t_user unter der Datenbank und fügen Sie Daten für die Tabelle t_user ein.

An dieser Stelle können Sie unter dem MySQL-Datenverzeichnis ein Datenverzeichnis über die Bibliothek sehen

3.2.3 Kopieren Sie die Dateien auf den ersten zu kopierenden Computer

Es ist zu beachten, dass zur Minimierung anderer Probleme, die während des Datenkopie-Migrationsprozesses verursacht werden, versucht werden sollte, die MySQL-Version auf den beiden Computern konsistent zu halten, und der Speicherort des MySQL-Datenverzeichnisses sollte konsistent sein. Wenn es von Docker erstellt wird , die gemounteten Daten Die Verzeichniseinstellungen sind konsistent;

Das Dateiverzeichnis, das kopiert werden muss, lautet wie folgt (einige Schüler sagten, dass es nicht notwendig sei, das MySQL-Verzeichnis zu kopieren, aber ich habe es hier versucht und es scheint zu funktionieren)

Kopieren Sie dann die oben genannten Verzeichnisse an denselben Speicherort auf dem IP2-Computer. Stellen Sie vor dem Kopieren sicher, dass sich keine solche Datei im IP-Verzeichnis befindet

Um die Datendatei zu kopieren, können Sie das FTP-Tool oder direkt scp verwenden und sie nach Abschluss des Kopiervorgangs dekomprimieren (beachten Sie, dass Sie das vorherige Datenverzeichnis sichern sollten).

Dekomprimieren Sie die Datei nach Abschluss des Kopiervorgangs. Starten Sie nach Abschluss der Dekomprimierung den MySQL-Dienst neu und verwenden Sie dann den Client, um eine Verbindung herzustellen. Wenn kein Unfall vorliegt, können Sie dieselben Datenbank- und Tabellendaten sehen.

3.3 Tool-Migration für physische Migration

Aufgrund der oben genannten Vorgänge ist der Prozess der direkten Verwendung der Kopie des Datenverzeichnisses immer noch sehr umständlich, und wenn die Größe der zu migrierenden Datenbankdatei groß ist, kann der Prozess sehr langwierig sein. Darüber hinaus ist die Datenübertragung der Prozess Auch externe Umgebungsfaktoren wie das Netzwerk können leicht beeinträchtigt werden. Wenn in der Produktionspraxis die Verwendung von Client-Tools zulässig ist, können Sie natürlich die Verwendung von Client-Tools in Betracht ziehen, um bei der Migration der gesamten Datenbankdaten zusammenzuarbeiten. Nehmen wir zur Veranschaulichung immer noch die obige Datenbank als Beispiel und schauen wir uns den spezifischen Betriebsprozess an.

3.3.1 Löschen Sie die Datenbank auf IP2

Um den Demonstrationseffekt sicherzustellen, löschen Sie zunächst die Datenbank auf IP2

3.3.2 Exportieren Sie die Datenbank auf IP1

Verwenden Sie das Navicat-Tool, um eine Verbindung zum MySQL-Dienst von IP1 herzustellen und die Datenbank von db_emp als SQL-Datei zu exportieren

Der Export erfolgt aufgrund des geringen Datenvolumens schnell

3.3.3 Importieren Sie die SQL-Datei in IP2

Führen Sie die SQL-Datei aus und importieren Sie die oben exportierte SQL über Navicat. Dieser Vorgang muss von vielen Schülern zu normalen Zeiten ausgeführt werden, daher werde ich nicht auf Details eingehen.

4. Implementierungsplan für die Migration der Datenbanklogik

Obwohl die physische Migration einfach und schwierig erscheint, ist die physische Migration in der Produktionspraxis, insbesondere in Umgebungen mit vielen Mikrodiensten und großen Datenbanken, keine übliche Lösung. Warum sagen Sie das?

4.1 Nachteile der physischen Migration

nicht flexibel genug

Um die Konsistenz der Daten vor und nach der Migration sicherzustellen, kann es erforderlich sein, die online laufenden Dienste herunterzufahren und erneut zu migrieren, was nicht flexibel genug ist

Daten zu groß

In der tatsächlichen Produktionsumgebung ist die Dateigröße der Datenbank in G klein und in T dynamisch. Eine solche maschinenübergreifende Kopiergeschwindigkeit und Anforderungen an das Netzwerk sind unvorstellbar.

Backup-Probleme

Wenn Sie die vorherigen Datendateien sichern, müssen Sie viel Speicherplatz auf der Festplatte beanspruchen. Wenn viele Dateien vorhanden sind und die Dateigröße zu groß ist, nimmt die Sicherung viel Zeit in Anspruch.

In der Umgebung ist es schwierig, Konsistenz zu gewährleisten

Tatsächlich ist es, wie oben erwähnt, schwierig, die Konsistenz des Datenverzeichnisses und anderer Umgebungen verschiedener Maschinen vor und nach der Datenreplikation sicherzustellen. In der Realität werden viele unkontrollierbare Schwierigkeiten häufig durch Serverumgebungsfaktoren verursacht. Aus diesem Grund sind viele Entwicklungsingenieure und ein Kopfzerbrechen für Betriebs- und Wartungsingenieure

Im tatsächlichen Betrieb ist die physische Migration aufgrund unvorhersehbarerer Faktoren nicht die bevorzugte Datenmigrationslösung. Daher bevorzugen DBAs oder Betriebs- und Wartungspersonal in den meisten Fällen die logische Migration.

Nehmen Sie zur Veranschaulichung immer noch das obige db_emp als Beispiel und schauen wir uns die spezifischen Betriebsschritte an.

4.2 Merkmale der logischen Migration

Im Vergleich zur physischen Migration bietet die logische Datenbankmigration offensichtlichere Vorteile und kann auf verschiedene Szenarien angewendet werden, insbesondere:

4.2.1 Vor- und Nachteile der logischen Migration

Vorteil

Hohe Kompatibilität, flexibel und bequem, versionübergreifend, relativ kleine Dateiübertragung

Mangel

Die Migrationszeit kann sehr lang sein. Das Prinzip der logischen Migration besteht darin, die Daten- und Tabellenstruktur in der MySQL-Datenbank in SQL-Dateien zu konvertieren. Wenn die Backup-SQL-Datei besonders groß ist, dauert der Analyse- und Konvertierungsprozess lange

4.2.2 Angelegenheiten, die bei der Logikmigration beachtet werden müssen

1. Überprüfen Sie die Bibliotheken oder Datentabellen, die nicht migriert werden müssen.

2. Separate Verarbeitung für große Tabellen;

3. Überprüfen Sie die Daten, sobald die Migration abgeschlossen ist

4.3 Sicherung und Wiederherstellung der Datenbanklogik

Die logische Sicherung der Datentabelle der MySQL-Datenbank wird hier nicht näher erläutert. Sie steht nicht im Mittelpunkt dieses Artikels. Interessierte Schüler können sich auf diesen Artikel beziehen: Sicherung und Wiederherstellung von MySQL-Daten. Einfach ausgedrückt besteht der Kern der logischen Sicherung in der Verwendung von Der Befehl mysqldump sichert die Datenbankdatentabelle und führt eine Datenwiederherstellung oder -migration basierend auf dieser Datei durch.

4.3.1 Datenbanksicherungsbefehl ausführen

Führen Sie den folgenden Datenbanksicherungsbefehl aus, um die Datenbank db_emp zu sichern

mysqldump -uroot -p Ihr Passwort --databases db_emp > /var/lib/mysql/db_emp.sql

Nachdem die Ausführung abgeschlossen ist, können Sie sehen, dass eine SQL-Datei in das aktuelle Verzeichnis exportiert wird.

4.3.2 SQL-Datei kopieren

Kopieren Sie die oben gesicherte Datenbankdatei in dasselbe Verzeichnis auf dem zweiten Computer

4.3.3 Wiederherstellen von Sicherungsdaten

Melden Sie sich beim MySQL-Dienst von IP2 an und löschen Sie die vorherige db_emp-Datenbank

Führen Sie den folgenden Befehl aus, um Daten wiederherzustellen

mysql -uroot -Ihr Passwort < /var/lib/mysql/db_emp.sql

Überprüfen Sie nach Abschluss der Ausführung erneut die MySQL von IP2. Sie können sehen, dass die Daten migriert wurden.

5. Implementierungsplan für die Anwendungsmigration

Im realen Geschäftsleben können folgende Szenarien existieren (abgeleitet von realen Geschäftsanforderungen):

Am Projektstandort gibt es kein professionelles Implementierungspersonal oder Personal, das mit der Datenbank vertraut ist.
Einige Geschäftstabellen in der Datenbank können von Zeit zu Zeit Felder vergrößern oder verkleinern;
Eine hohe Off-Site-Verfügbarkeit erfordert Datensicherung, inkrementelle oder vollständige Sicherung;
Sie müssen nur die Daten bestimmter Änderungsereignisse einiger Tabellen sichern, z. B. das Hinzufügen, Löschen und Ändern von Daten.
Es ist notwendig, neue Tabellen für einige Tabellendaten für andere geschäftliche Zwecke heterogen zu synthetisieren ...

Zusammenfassend lässt sich sagen, dass eines der Merkmale der oben genannten Szenarien darin besteht, dass die Datenszenarien, die migriert werden müssen, bestimmte Besonderheiten oder personalisierte Szenarien aufweisen. In diesem Fall ist es schwierig, mit einer festen Methode damit umzugehen. Es ist ein gute Wahl, es durch das Programm zu lösen.

Wie setzt man es in der Praxis um? In Kombination mit mehreren gängigen Szenarien sind unten mehrere häufig verwendete Verarbeitungslösungen aufgeführt.

5.1 Business Case Anforderungen und Umsetzung 1

Es gibt eine Tabelle in der Datenbank einer Anwendung A, und nun ist es notwendig, einige Felddaten der Daten in Tabelle A in einer anderen Datenbank zu speichern und gleichzeitig Statistiken zu sammeln und die Ergebnisse eines bestimmten Indikators zu aggregieren Anwendung B für Großbildanzeige

Bedarfsanalyse

Aus der obigen Anforderungsbeschreibung können die folgenden Kernpunkte extrahiert werden:

Bei der Operation handelt es sich um eine bestimmte Tabelle in der Datenbank.
Was migriert werden muss, ist ein Teil der Daten in der Tabelle;
Statistische Berechnungen müssen anhand vorhandener Tabellendaten durchgeführt werden;

In Kombination mit den oben genannten ursprünglichen Anforderungen und der Analyse der Anforderungen ist es schwierig, diese Anforderung direkt durch die SQL-Migration zu erreichen. Hier sind einige häufig verwendete Implementierungslösungen:

Durch die gespeicherte Prozedur von MySQL;
Durch logische Migration werden die Berechnungsergebnisse nach Abschluss der Migration manuell korrigiert, berechnet und ausgefüllt.
durch das Programm zu vervollständigen;

Offensichtlich ist die Implementierung der ersten und zweiten Methode nicht flexibel genug und kann zu Ausfallzeiten führen. Um diese Angelegenheit abzuschließen, kann ein Zwischenprogramm in Betracht gezogen werden. Hier empfehlen wir zur Implementierung den Open-Source-Middleware-Kanal von Ali.

5.1.1 Verwenden Sie den Kanal, um die Datenmigration abzuschließen

Canal ist ein von Ali bereitgestelltes Open-Source-Tool zur Synchronisierung von MySQL-Datenbanken. Sein Hauptzweck besteht darin, inkrementelle Datenabonnements und -nutzung basierend auf der inkrementellen Protokollanalyse der MySQL-Datenbank bereitzustellen. Kanal-Git-Adresse

Das Prinzip der Kanalimplementierung ist in der folgenden Abbildung dargestellt

è¿éæå¥å¾çæè¿°

Wie kann Canal also spezifisch für das Anwendungsprogramm die oben genannten Anforderungen erfüllen? Tatsächlich ist es einfach zu verstehen, dass Canal nach der Verwendung von Canal einem Listener entspricht, der verschiedene Ereignisänderungen in der Zieldatentabelle überwachen kann. Nachdem er verschiedene Datenänderungsereignisse abgehört hat, kann er die geänderten Protokolle analysieren und verarbeiten. Canal kann Direkte Installation, Bereitstellung, einfache Konfiguration und Verwendung auf dem Server stellen auch ein clientseitiges SDK für das Programm bereit. Basierend auf dem SDK kann es zum Einstiegspunkt für die oben erwähnte Geschäftsrealisierung werden.

Abgebildet auf die oben genannten Anforderungen lautet die vollständige Implementierungsidee wie folgt:

Konfigurieren Sie den Serverkanal im Voraus;
Der Kunde stellt das SDK des Kanals vor;
Die Anwendung lauscht auf das angegebene Datenänderungsereignis und schreibt die Daten in die neue Tabelle;
Die Anwendungsstatistik aggregiert die Ergebnisse in der neuen Tabelle (dieser Schritt kann auch an anderer Stelle durchgeführt werden);

5.1.2 Beispielcode für die Kanalimplementierung

Beispielcode für ein Zwischenprogramm (die vollständige Implementierung finden Sie im offiziellen Demo-Fall)

import com.alibaba.fastjson.JSONObject;
import com.alibaba.otter.canal.client.CanalConnector;
import com.alibaba.otter.canal.client.CanalConnectors;
import com.alibaba.otter.canal.protocol.CanalEntry;
import com.alibaba.otter.canal.protocol.Message;
import com.google.protobuf.ByteString;

import java.net.InetSocketAddress;
import java.util.List;

public class CanalClient {

    public static void main(String[] args) throws Exception{

        //1.获取 canal 连接对象
        CanalConnector canalConnector =
                CanalConnectors.newSingleConnector(new
                        InetSocketAddress("canal所在服务器IP", 11111), "example", "", "");

        System.out.println("canal启动并开始监听数据 ...... ");

        while (true){
            canalConnector.connect();
            //订阅表
            canalConnector.subscribe("shop001.*");

            //获取数据
            Message message = canalConnector.get(100);

            //解析message
            List<CanalEntry.Entry> entries = message.getEntries();
            if(entries.size() <=0){
                System.out.println("未检测到数据");
                Thread.sleep(1000);
            }

            for(CanalEntry.Entry entry : entries){
                //1、获取表名
                String tableName = entry.getHeader().getTableName();

                //2、获取类型
                CanalEntry.EntryType entryType = entry.getEntryType();

                //3、获取序列化后的数据
                ByteString storeValue = entry.getStoreValue();

                //判断是否rowdata类型数据
                if(CanalEntry.EntryType.ROWDATA.equals(entryType)){
                    //对第三步中的数据进行解析
                    CanalEntry.RowChange rowChange = CanalEntry.RowChange.parseFrom(storeValue);
                    //获取当前事件的操作类型
                    CanalEntry.EventType eventType = rowChange.getEventType();

                    //获取数据集
                    List<CanalEntry.RowData> rowDatasList = rowChange.getRowDatasList();

                    //便利数据
                    for(CanalEntry.RowData rowData : rowDatasList){

                        //数据变更之前的内容
                        JSONObject beforeData = new JSONObject();
                        List<CanalEntry.Column> beforeColumnsList = rowData.getAfterColumnsList();
                        for(CanalEntry.Column column : beforeColumnsList){
                            beforeData.put(column.getName(),column.getValue());
                        }

                        //数据变更之后的内容
                        List<CanalEntry.Column> afterColumnsList = rowData.getAfterColumnsList();
                        JSONObject afterData = new JSONObject();
                        for(CanalEntry.Column column : afterColumnsList){
                            afterData.put(column.getName(),column.getValue());
                        }

                        System.out.println("Table ：" + tableName +
                                ",eventType :" + eventType +
                                ",beforeData :" + beforeData +
                                ",afterData : " + afterData);

                    }
                }else {
                    System.out.println("当前操作类型为：" + entryType);
                }
            }
        }
    }
}

5.2 Business Case Anforderungen und Umsetzung 2

Beschreibung der Anforderung

Das Geschäftssystem stößt häufig auf die Notwendigkeit, die Daten einer bestimmten Tabelle in mehreren Speichern zu aktualisieren, was ein Upgrade der oben genannten Anforderungen darstellt. Beispielsweise müssen die Daten einer bestimmten Tabelle in MySQL aktualisiert werden, nachdem sie sich geändert haben synchron in eine andere Datenbank übertragen und auch synchron auf es, redis, mongo und anderen Speicher aktualisiert

In einem solchen Nachfrageszenario gibt es eine bessere Wahl, nämlich die Implementierung von flink-cdc.

5.2.1 Flink-cdc-Implementierungsprinzipien und -ideen

Die folgende Abbildung ist ein Geschäftsflussdiagramm zur Flink-CDC-Implementierung auf der offiziellen Website. Es ist nicht schwer zu verstehen, dass dies dem Implementierungsprinzip von Canal sehr ähnlich ist

è¿éæå¥å¾çæè¿°

Wenn Sie flink cdc verwenden, um diese Anforderung zu erfüllen, können Sie dies grob gemäß den folgenden Ideen tun

1. MySQL-Konfigurations-Binlog;

2. Das Programm führt SDK-Abhängigkeiten ein;

3. Schreiben Sie ein Programm, überwachen Sie das Datenänderungsereignis der Zieltabelle und schreiben Sie Daten in die Zieltabelle.

5.2.2 flink-cdc implementiert Schlüsselcodes

Der mit flink-cdc implementierte Beispielcode ist unten aufgeführt. Interessierte Studenten können ihn eingehend studieren

import org.apache.flink.api.java.tuple.Tuple2;
import org.apache.flink.streaming.api.datastream.DataStream;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.table.api.Table;
import org.apache.flink.table.api.bridge.java.StreamTableEnvironment;
import org.apache.flink.types.Row;

public class CdcTest2 {

    public static void main(String[] args) throws Exception{

        //1.创建执行环境
        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

        env.setParallelism(1);
        StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);

        //2.创建 Flink-MySQL-CDC 的 Source
        tableEnv.executeSql("CREATE TABLE user_info1 (" +
                " id STRING NOT NULL," +
                " name STRING NOT NULL," +
                " version INTEGER NOT NULL" +
                ") WITH (" +
                " 'connector' = 'mysql-cdc'," +
                " 'hostname' = 'IP'," +
                " 'port' = '3306'," +
                " 'username' = 'root'," +
                " '连接密码' = '连接密码'," +
                " 'database-name' = 'bank1'," +
                " 'table-name' = 'record'" +
                ")");

        //tableEnv.executeSql("select * from user_info1").print();

        Table table = tableEnv.sqlQuery("select * from user_info1");
        DataStream<Tuple2<Boolean, Row>> retractStream = tableEnv.toRetractStream(table, Row.class);

        //结果打印输出
        retractStream.print();

        env.execute("flinkCdcSql");

    }

}

6. Middleware realisiert die Offline-Datenmigration

Mit der steigenden Nachfrage nach Datenmigration sind einige einfach zu verwendende Open-Source-Middleware auf den Markt gekommen, um die Migration von Datenbankdatentabellen abzuschließen. Hier sind einige häufig verwendete und relativ stabile Middleware für die Datensynchronisierung.

Der 6.1-Kanal realisiert die Datenmigration oder -synchronisierung

Oben habe ich kurz die Funktion des Kanals und den Prozess der Datensynchronisierung in Kombination mit dem Programm vorgestellt. Tatsächlich ist die Funktion des Kanals immer noch sehr leistungsfähig. Er kann Daten synchronisieren und auch MySQL-Daten in andere importieren Speichern und sogar mit Anwendungen zusammenarbeiten. Programm, um einige komplizierte und spezielle Szenenrealisierungen durchzuführen.

6.1.1 Verwenden Sie den Kanal, um die Datenmigration oder -synchronisierung zu realisieren

Um den Kanal zur Datenmigration oder -synchronisierung zu verwenden, befolgen Sie im Allgemeinen die folgenden Schritte

1. Installieren Sie den Kanalserver;

2. Fügen Sie eine Konfigurationsdatei hinzu, konfigurieren Sie die Quelldatenbank und die Datentabellenadresse, konfigurieren Sie die Zieldatenbank und die Datentabellenadresse.

3. Basierend auf dem zweiten Schritt können detailliertere Einstellungen vorgenommen werden, z. B. nur die Änderungsdaten bestimmter Ereignisse in der Tabelle synchronisieren und je nach Bedarf eine inkrementelle oder vollständige Synchronisierung festlegen;

4. Starten Sie den Dienst, nachdem die Konfigurationsdatei fertiggestellt ist.

5. Wenn das Problem nicht direkt durch Konfiguration gelöst werden kann, können komplexere Vorgänge mit Anwendungscode abgeschlossen werden.

6.2 datax implementiert die Datenmigration

6.2.1 Einführung in datax

DataX ist ein in Ali weit verbreitetes Offline-Datensynchronisierungstool/-plattform, das eine effiziente Datensynchronisierung zwischen verschiedenen heterogenen Datenquellen wie MySQL, Oracle, HDFS, Hive, OceanBase, HBase, OTS, ODPS usw. realisieren kann. DataX übernimmt das Framework + Plug Der -in-Modus ist derzeit Open Source und der Code wird auf Github, Datax-Git-Adresse, gehostet

6.2.2 Datax-Funktionen

Als Datensynchronisierungs-Framework abstrahiert DataX die Synchronisierung verschiedener Datenquellen in ein Reader-Plug-in, das Daten aus der Quelldatenquelle liest, und ein Writer-Plug-in, das Daten auf das Zielende schreibt. Theoretisch kann das DataX-Framework dies Unterstützt die Datensynchronisierung aller Datenquellentypen. Gleichzeitig dient das DataX-Plugin-System als Ökosystem: Jedes Mal, wenn eine neue Datenquelle angeschlossen wird, kann die neu hinzugefügte Datenquelle mit der bestehenden Datenquelle kommunizieren.

6.2.3 Anwendbare Szenarien

Wenn der Dienst angehalten wird, werden in der Regel innerhalb kurzer Zeit Daten von einer Datenbank in eine andere oder in andere Datenbanktypen migriert.

6.2.4 datax implementiert den Datenmigrationsprozess

Der allgemeine Prozess der Datenmigration mit datax ist ungefähr wie folgt:

1. Laden Sie das Installationspaket herunter und dekomprimieren Sie es.

2. Schreiben Sie eine Konfigurationsdatei, um die ursprüngliche Datenbank, Tabelle, Verbindung und andere zu synchronisierende Informationen zu konfigurieren.

3. Konfigurieren Sie die Informationen der Zieldatenbank, Datenbank, Tabelle usw.;

4. Für datax müssen die Namen der Quelltabelle und der Zieltabelle nicht identisch sein, und selbst die Felder müssen nicht vollständig konsistent sein, solange der Datentyp korrekt ist.

5. Führen Sie Befehle für die Konfigurationsdatei aus, um die Offline-Migration der Daten abzuschließen.

6.2.5 Simulationskonfiguration der Datax-Datenmigration

Im Folgenden finden Sie Konfigurationsinformationen für die Datenmigration mit datax. Weitere Einzelheiten finden Sie in den offiziellen Informationen.

{
    "job": {
        "setting": {
            "speed": {
                 "channel": 3
            },
            "errorLimit": {
                "record": 0,
                "percentage": 0.02
            }
        },
        "content": [
            {
                "reader": {
                    "name": "mysqlreader",
                    "parameter": {
                        "username": "连接用户名",
                        "password": "连接密码",
                        "column": [
                            "id",
                            "name"
                        ],
                        "connection": [
                            {
                                "table": [
                                    "user_info"    #表名
                                ],
                                "jdbcUrl": [
     "jdbc:mysql://IP1:3306/shop001"			#源地址
                                ]
                            }
                        ]
                    }
                },
               "writer": {
                    "name": "streamwriter",
                    "parameter": {
                        "print":true,	#开启任务运行过程中的打印
	       "column": [
                        "id","name"		#待同步的字段
	         ], 
	    "connection": [
                            {
                                "jdbcUrl": "jdbc:mysql://IP2:3306/shop001", 		#目标地址
                                "table": ["user_info_copy"]		#目标表
                            }
                        ], 
                        "password": "连接密码", 
                        "username": "连接用户名"
                    }
                }
            }
        ]
    }
}

7. Offline-Datenmigration von Client-Tools

Bei der täglichen Arbeit, wenn die Echtzeitanforderungen nicht hoch sind und die Datenmenge nicht besonders groß ist, können Sie auch einige Client-Tools verwenden, um die Datenmigrationsarbeit abzuschließen. Im Folgenden werden einige häufig verwendete Client-Tools zur Unterstützung der Daten vorgestellt Migrationsarbeit.

7.1 Navicat

Navicat ist ein Client-Tool, mit dem meiner Meinung nach jeder vertraut ist. Es wird bei der täglichen Entwicklung sowie im Betrieb und bei der Wartung angetroffen. Dieses Client-Tool kann nicht nur die tägliche Verbindung und Nutzung vieler Datenbanken wie MySQL, PG, OB usw. erfüllen. , sondern helfen auch bei der Durchführung einiger routinemäßiger Datenmigrationsarbeiten. Beispielsweise kann der Prozess der Migration der MySQL-Datenbank nach Postgresql problemlos über den Navicat-Client abgeschlossen werden. Schauen wir uns die spezifischen Betriebsschritte an.

7.2 Navicat migriert MySQL-Daten nach Postgresql

7.2.1 Vorbereitung

Bevor Sie Daten migrieren, müssen Sie eine neue MySQL- und PostgreSQL-Verbindung erstellen und bestätigen, dass das Verbindungskonto über alle Berechtigungen zum Migrieren der Datenbank verfügt

7.2.2 Konfiguration migrieren

Klicken Sie auf das Menü Extras>>Übertragen. Das folgende Fenster wird angezeigt. Wählen Sie die Quell-MySQL und die Ziel-PostgreSQL-Datenbank aus

7.2.3 Tabellen für die Migration auswählen

Wählen Sie alle Tabellen unter der Datenbank aus

7.2.4 Aktivieren Sie „Fortfahren“, wenn Fehler auftreten

Der Grund dafür ist, dass der Index in MySQL in der Tabelle eindeutig ist, der Indexname in PostgreSQL jedoch global eindeutig ist. Wenn bei der Synchronisierung entsprechende Fehler auftreten, werden später SQL-Ergänzungen bereitgestellt

Gemäß den oben genannten Arbeitsschritten kann die Datenmigration von MySQL nach PG abgeschlossen werden.

7,3 Wasserkocher

7.3.1 Übersicht über den Wasserkocher

Der chinesische Name von Kettle ist Kettle. Der Hauptprogrammierer dieses Projekts hofft, alle Arten von Daten in einen Topf zu geben und dann in einem bestimmten Format herauszufließen. Kettle wird für die Datenmigration verwendet, also für die Übertragung aller Daten Eine Datenbank. Eine andere Datenbank importieren.

KettleEs handelt sich um ein fremdes Open-Source- ETLTool, rein Javageschrieben, grün ohne Installation, effiziente und stabile Datenextraktion (Datenmigrationstool).

7.3.2 Kettle-Datenmigrationsprozess

Kettle wird häufig in Big-Data-ETL verwendet. Nach dem Öffnen können Sie verschiedene Vorgänge direkt über den Client mit einer Navicat-ähnlichen Schnittstelle konfigurieren. Die allgemeine Idee ähnelt der von Navicat oben.

Kettle kann nicht nur für die Offline-Migration von Daten zwischen MySQL-Datenbanken verwendet werden, sondern kann auch die Migration zwischen verschiedenen Datenbanktypen realisieren, z. B. MySQL zu Mogo.

Acht, geschrieben am Ende des Textes

Dieser Artikel fasst die gängigen Verarbeitungsschemata der MySQL-Datenmigration oder -synchronisierung im Detail und in einem großen Raum zusammen. Tatsächlich ist die Situation in der Produktionsumgebung weitaus komplizierter als diese. Beispielsweise im Master-Slave-Modus von MySQL, neuer Slave Knoten müssen erweitert werden. Hier sind einige relativ allgemeine Knoten. Die Lösungsideen können zu Rate gezogen werden, wenn in späteren Arbeiten auf ähnliche Szenarien gestoßen wird. Dies ist das Ende dieses Artikels. Vielen Dank fürs Zuschauen.

Zusammenfassung gängiger Lösungen für die Migration und Synchronisierung von MySQL-Daten

I. Einleitung