Ich werde die Kreuzreplikation zwischen PostgreSQL und MySQL sowie die Methoden zum Einrichten der Kreuzreplikation zwischen diesen beiden Datenbankservern skizzieren. In der Regel werden replikationsübergreifende Datenbanken als homogen bezeichnet. Dies ist eine bequeme Methode, um von einem relationalen Datenbankserver auf einen anderen zu wechseln.
PostgreSQL- und MySQL-Datenbanken gelten als relational, bieten jedoch mit zusätzlichen Erweiterungen NoSQL-Funktionen. Hier werden wir die Replikation zwischen PostgreSQL und MySQL im Hinblick auf relationales DBMS diskutieren.
Wir werden nicht die gesamte innere Küche beschreiben, sondern nur die Grundprinzipien, damit Sie eine Vorstellung davon bekommen, wie die Replikation zwischen Datenbankservern konfiguriert wird, welche Vorteile, Einschränkungen und Anwendungsfälle es gibt.
In der Regel wird die Replikation zwischen zwei identischen Datenbankservern entweder im Binärmodus oder über Anforderungen zwischen dem Masterknoten (Herausgeber, Master oder Aktiv) und dem Slave (Abonnent, anstehend oder passiv) durchgeführt. Der Zweck der Replikation besteht darin, eine Echtzeitkopie der Master-Datenbank auf der Slave-Seite bereitzustellen. In diesem Fall werden Daten vom Master zum Slave übertragen, dh von aktiv zu passiv, da die Replikation nur in eine Richtung erfolgt. Sie können jedoch die Replikation zwischen zwei Datenbanken in beide Richtungen konfigurieren, sodass in der Aktiv-Aktiv-Konfiguration Daten vom Slave zum Master übertragen werden. All dies, einschließlich der kaskadierenden Replikation, möglicherweise zwischen zwei oder mehr identischen Datenbankservern. Die Aktiv-Aktiv- oder Aktiv-Passiv-Konfiguration hängt von der Notwendigkeit, der Verfügbarkeit solcher Funktionen in der Erstkonfiguration oder der Verwendung externer Konfigurationslösungen und vorhandenen Kompromissen ab. .
Die beschriebene Konfiguration ist zwischen verschiedenen Datenbankservern möglich. Der Server kann so konfiguriert werden, dass er replizierte Daten von einem anderen Datenbankserver empfängt und dennoch Snapshots der replizierten Daten in Echtzeit speichert. MySQL und PostgreSQL bieten die meisten dieser Konfigurationen einzeln oder mit Erweiterungen von Drittanbietern an, einschließlich binärer Protokollmethoden, Festplattensperren sowie auf Anweisungen und Zeichenfolgen basierenden Methoden.
Für eine einzelne Migration von einem Datenbankserver auf einen anderen ist eine Kreuzreplikation zwischen MySQL und PostgreSQL erforderlich. Diese Datenbanken verwenden unterschiedliche Protokolle, sodass sie nicht direkt verbunden werden können. Um den Datenaustausch einzurichten, können Sie ein externes Open Source-Tool verwenden, z. B. pg_chameleon.
Was ist pg_chameleon?
pg_chameleon ist ein Replikationssystem von MySQL nach PostgreSQL in Python 3. Es verwendet die Open-Source-Bibliothek mysql-replication, ebenfalls in Python. Zeichenfolgenbilder werden aus MySQL-Tabellen extrahiert und als JSONB-Objekte in der PostgreSQL-Datenbank gespeichert. Anschließend werden sie mit der Funktion pl / pgsql entschlüsselt und in der PostgreSQL-Datenbank wiedergegeben.
Pg_chameleon-Funktionen
Mehrere MySQL-Schemas aus demselben Cluster können mit einer Eins-zu-Viele-Konfiguration auf dieselbe PostgreSQL-Zieldatenbank repliziert werden
Die Namen der Quell- und Zielschemata können nicht übereinstimmen.
Replikationsdaten können von einem kaskadierten MySQL-Replikat abgerufen werden.
Tabellen, die keine Fehler replizieren oder generieren können, werden ausgeschlossen.
Jede Replikationsfunktion wird von Dämonen gesteuert.
Steuerung über Parameter und Konfigurationsdateien basierend auf YAML.
Beispiel
Bereiten Sie zunächst alle erforderlichen Komponenten für die Installation von pg_chameleon vor. In diesem Beispiel wird Python 3.6.8 installiert, das eine virtuelle Umgebung erstellt und aktiviert.
$> wget https://www.python.org/ftp/python/3.6.8/Python-3.6.8.tar.xz $> tar -xJf Python-3.6.8.tar.xz $> cd Python-3.6.8 $> ./configure --enable-optimizations $> make altinstall
Nach der erfolgreichen Installation von Python3.6 müssen Sie die anderen Anforderungen erfüllen, z. B. eine virtuelle Umgebung erstellen und aktivieren. Darüber hinaus wird das Pip-Modul auf die neueste Version aktualisiert und zur Installation von pg_chameleon verwendet. In den folgenden Befehlen wird pg_chameleon 2.0.9 absichtlich installiert, obwohl die neueste Version 2.0.10 ist. Dies ist erforderlich, um neue Fehler in der aktualisierten Version zu vermeiden.
$> python3.6 -m venv venv $> source venv/bin/activate (venv) $> pip install pip --upgrade (venv) $> pip install pg_chameleon==2.0.9
Dann rufen wir pg_chameleon (Chameleon ist ein Befehl) mit dem Argument set_configuration_files auf, um pg_chameleon zu aktivieren und Standardverzeichnisse und Konfigurationsdateien zu erstellen.
(venv) $> chameleon set_configuration_files creating directory /root/.pg_chameleon creating directory /root/.pg_chameleon/configuration/ creating directory /root/.pg_chameleon/logs/ creating directory /root/.pg_chameleon/pid/ copying configuration example in /root/.pg_chameleon/configuration//config-example.yml
Jetzt erstellen wir eine Kopie von config-example.yml als default.yml, damit es zur Standardkonfigurationsdatei wird. Eine Beispielkonfigurationsdatei für dieses Beispiel ist unten dargestellt.
$> cat default.yml --- #global settings pid_dir: '~/.pg_chameleon/pid/' log_dir: '~/.pg_chameleon/logs/' log_dest: file log_level: info log_days_keep: 10 rollbar_key: '' rollbar_env: '' # type_override allows the user to override the default type conversion into a different one. type_override: "tinyint(1)": override_to: boolean override_tables: - "*" #postgres destination connection pg_conn: host: "192.168.56.106" port: "5433" user: "usr_replica" password: "pass123" database: "db_replica" charset: "utf8" sources: mysql: db_conn: host: "192.168.56.102" port: "3306" user: "usr_replica" password: "pass123" charset: 'utf8' connect_timeout: 10 schema_mappings: world_x: pgworld_x limit_tables: # - delphis_mediterranea.foo skip_tables: # - delphis_mediterranea.bar grant_select_to: - usr_readonly lock_timeout: "120s" my_server_id: 100 replica_batch_size: 10000 replay_max_rows: 10000 batch_retention: '1 day' copy_max_memory: "300M" copy_mode: 'file' out_dir: /tmp sleep_loop: 1 on_error_replay: continue on_error_read: continue auto_maintenance: "disabled" gtid_enable: No type: mysql skip_events: insert: - delphis_mediterranea.foo #skips inserts on the table delphis_mediterranea.foo delete: - delphis_mediterranea #skips deletes on schema delphis_mediterranea update:
Die Konfigurationsdatei in diesem Beispiel ist eine Beispieldatei mit pg_chameleon mit geringfügigen Änderungen je nach Quell- und Zielumgebung. Im Folgenden finden Sie eine Übersicht über die verschiedenen Abschnitte der Konfigurationsdatei.
In der Konfigurationsdatei default.yml gibt es einen Abschnitt mit globalen Einstellungen, in dem Sie Einstellungen wie den Speicherort der Sperrdatei, den Speicherort der Protokolle, den Speicherzeitraum der Protokolle usw. steuern können. Der nächste Abschnitt ist der Abschnitt zum Überschreiben von Typen, in dem der Satz angegeben wird Regeln zum Überschreiben von Typen während der Replikation. Das Standardbeispiel verwendet eine Typ-Neudefinitionsregel, die tinyint (1) in einen booleschen Wert konvertiert. Im nächsten Abschnitt geben wir die Details zum Herstellen einer Verbindung zur Zieldatenbank an. In unserem Fall ist dies eine PostgreSQL-Datenbank mit der Bezeichnung pg_conn. Im letzten Abschnitt geben wir die Quelldaten an, dh die Verbindungsparameter der Quellendatenbank, das Zuordnungsschema der Quell- und Zieldatenbanken, die zu überspringenden Tabellen, das Zeitlimit, den Speicher und die Paketgröße. Beachten Sie, dass "Quellen" im Plural angegeben ist. Das heißt, wir können mehrere Quellendatenbanken für dasselbe Ziel hinzufügen, um die Viele-zu-Eins-Konfiguration zu konfigurieren.
Die world_x-Datenbank im Beispiel enthält 4 Tabellen mit Zeilen, die die MySQL-Community für das Beispiel anbietet. Es kann hier heruntergeladen werden . Die Beispieldatenbank besteht aus tar und einem komprimierten Archiv mit Anweisungen zum Erstellen und Importieren von Zeichenfolgen.
In den MySQL- und PostgreSQL-Datenbanken mit dem gleichen Namen usr_replica wird ein spezieller Benutzer erstellt. In MySQL erhält er zusätzliche Rechte zum Lesen aller replizierten Tabellen.
mysql> CREATE USER usr_replica ; mysql> SET PASSWORD FOR usr_replica='pass123'; mysql> GRANT ALL ON world_x.* TO 'usr_replica'; mysql> GRANT RELOAD ON *.* to 'usr_replica'; mysql> GRANT REPLICATION CLIENT ON *.* to 'usr_replica'; mysql> GRANT REPLICATION SLAVE ON *.* to 'usr_replica'; mysql> FLUSH PRIVILEGES;
Auf der PostgreSQL-Seite wird die Datenbank db_replica erstellt, die Änderungen aus der MySQL-Datenbank akzeptiert. Der Benutzer usr_replica von PostgreSQL wird automatisch als Eigentümer von zwei Schemas pgworld_x und sch_chameleon konfiguriert, die tatsächlich replizierte Tabellen bzw. Tabellen mit Replikationsverzeichnissen enthalten. Das Argument create_replica_schema ist für die automatische Konfiguration verantwortlich, wie Sie unten sehen werden.
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123'; CREATE ROLE postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica; CREATE DATABASE
Die MySQL-Datenbank ist mit einigen Änderungen konfiguriert, um sie für die Replikation vorzubereiten, wie unten gezeigt. Sie müssen den Datenbankserver neu starten, damit die Änderungen wirksam werden.
$> vi /etc/my.cnf binlog_format= ROW binlog_row_image=FULL log-bin = mysql-bin server-id = 1
Jetzt ist es wichtig, die Verbindung zu beiden Datenbankservern zu überprüfen, damit beim Ausführen von pg_chameleon-Befehlen keine Probleme auftreten.
Auf dem PostgreSQL-Knoten:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x
Auf dem MySQL-Knoten:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica
Die folgenden drei Befehle pg_chameleon (Chameleon) bereiten die Umgebung vor, fügen die Quelle hinzu und initialisieren das Replikat. Das Argument create_replica_schema in pg_chameleon erstellt, wie bereits erwähnt, das Standardschema (sch_chameleon) und das Replikationsschema (pgworld_x) in der PostgreSQL-Datenbank. Das Argument add_source fügt der Konfiguration die ursprüngliche Datenbank hinzu, indem es die Konfigurationsdatei (default.yml) liest. In unserem Fall ist es mysql, und init_replica initialisiert die Konfiguration basierend auf den Parametern in der Konfigurationsdatei.
$> chameleon create_replica_schema --debug $> chameleon add_source --config default --source mysql --debug $> chameleon init_replica --config default --source mysql --debug
Die Ausgabe dieser drei Befehle zeigt offensichtlich ihre erfolgreiche Ausführung an. Alle Abstürze oder Syntaxfehler werden in einfachen und übersichtlichen Meldungen mit Tipps zur Fehlerbehebung angezeigt.
Starten Sie schließlich die Replikation mit start_replica und erhalten Sie eine Erfolgsmeldung.
$> chameleon start_replica --config default --source mysql output: Starting the replica process for source mysql
Der Replikationsstatus kann mit dem Argument show_status angefordert werden, und Fehler können mit dem Argument show_errors angezeigt werden.
Ergebnis.
Wie bereits erwähnt, wird jede Replikationsfunktion von Dämonen gesteuert. Um sie anzuzeigen, fragen wir die Prozesstabelle mit dem Linux-Befehl ps ab, wie unten gezeigt.
Ergebnis.
Die Replikation wird erst dann als konfiguriert betrachtet, wenn wir sie in Echtzeit testen (siehe unten). Wir erstellen eine Tabelle, fügen einige Datensätze in die MySQL-Datenbank ein und rufen das Argument sync_tables in pg_chameleon auf, um die Daemons zu aktualisieren und die Tabelle mit den Datensätzen in der PostgreSQL-Datenbank zu replizieren.
mysql> create table t1 (n1 int primary key, n2 varchar(10)); Query OK, 0 rows affected (0.01 sec) mysql> insert into t1 values (1,'one'); Query OK, 1 row affected (0.00 sec) mysql> insert into t1 values (2,'two'); Query OK, 1 row affected (0.00 sec)
$> chameleon sync_tables --tables world_x.t1 --config default --source mysql Sync tables process for source mysql started.
Um die Testergebnisse zu bestätigen, fragen wir die Tabelle aus der PostgreSQL-Datenbank ab und zeigen die Zeilen an.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1"; n1 | n2 ----+------- 1 | one 2 | two
Wenn wir die Migration durchführen, werden die folgenden pg_chameleon-Befehle beendet. Die Befehle müssen ausgeführt werden, nachdem sichergestellt wurde, dass die Zeilen aller Zieltabellen repliziert wurden. Das Ergebnis ist eine sauber migrierte PostgreSQL-Datenbank ohne Verweis auf die ursprüngliche Datenbank oder das Replikationsschema (sch_chameleon).
$> chameleon stop_replica --config default --source mysql $> chameleon detach_replica --config default --source mysql --debug
Falls gewünscht, können die folgenden Befehle das ursprüngliche Konfigurations- und Replikationsschema entfernen.
$> chameleon drop_source --config default --source mysql --debug $> chameleon drop_replica_schema --config default --source mysql --debug
Vorteile von pg_chameleon
Einfache Einrichtung und Konfiguration.
Bequeme Fehlerbehebung und Erkennung von Anomalien mit eindeutigen Fehlermeldungen.
Sie können der Replikation nach der Initialisierung zusätzliche spezielle Tabellen hinzufügen, ohne den Rest der Konfiguration zu ändern.
Sie können mehrere Quelldatenbanken für ein Ziel konfigurieren. Dies ist sehr praktisch, wenn Sie Daten aus einer oder mehreren MySQL-Datenbanken in einer PostgreSQL-Datenbank kombinieren.
Sie können ausgewählte Tabellen nicht replizieren.
Nachteile von pg_chameleon
Wird nur mit MySQL 5.5 und höher als Quelle und PostgreSQL 9.5 und höher als Zieldatenbank unterstützt.
Jede Tabelle muss einen Primär- oder eindeutigen Schlüssel haben, andernfalls werden die Tabellen im Prozess init_replica initialisiert, aber nicht repliziert.
Einwegreplikation - nur von MySQL nach PostgreSQL. Daher ist es nur für das Aktiv-Passiv-Schema geeignet.
Nur die MySQL-Datenbank kann die Quelle sein, und die Unterstützung für die PostgreSQL-Datenbank ist nur experimentell und mit Einschränkungen (weitere Informationen finden Sie hier ).
Pg_chameleon Ergebnisse
Die Replikationsmethode in pg_chameleon eignet sich hervorragend für die Migration einer Datenbank von MySQL nach PostgreSQL. Ein wesentliches Minus ist, dass die Replikation nur in eine Richtung erfolgt, sodass Datenbankexperten sie wahrscheinlich nicht für andere Zwecke als für die Migration verwenden möchten. Das Problem der Einwegreplikation kann jedoch durch ein anderes Open-Source-Tool gelöst werden - SymmetricDS.
Lesen Sie hier mehr in der offiziellen Dokumentation. Hilfe in der Kommandozeile finden Sie hier .
SymmetricDS-Übersicht
SymmetricDS ist ein Open Source-Tool, das jede Datenbank in eine andere gängige Datenbank repliziert: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird und andere Cloud-Datenbankinstanzen Redshift und Azure usw. Verfügbare Funktionen: Synchronisierung von Datenbanken und Dateien, Replikation mehrerer führender Datenbanken, gefilterte Synchronisierung, Konvertierung und andere. Dies ist ein Java-Tool und erfordert eine Standardversion von JRE oder JDK (Version 8.0 oder höher). Hier können Sie Datenänderungen an Triggern in der Quellendatenbank aufzeichnen und in Form von Paketen an die entsprechende Zieldatenbank senden.
SymmetricDS-Funktionen
Das Tool ist plattformunabhängig, dh zwei oder mehr verschiedene Datenbanken können Daten austauschen.
Relationale Datenbanken werden durch Schreiben von Datenänderungen synchronisiert, und dateisystembasierte Datenbanken verwenden die Dateisynchronisierung.
Zweiwege-Replikation mit den Push- und Pull-Methoden basierend auf einer Reihe von Regeln.
Die Datenübertragung ist über sichere Netzwerke und Netzwerke mit geringer Bandbreite möglich.
Automatische Wiederherstellung, wenn Knoten nach einem Fehler wieder aufgenommen werden, und automatische Konfliktlösung.
Cloud-kompatible und leistungsstarke Erweiterungs-APIs.
Beispiel
SymmetricDS kann auf zwei Arten konfiguriert werden:
Ein Masterknoten (Elternknoten), der die Datenreplikation zwischen zwei Slaveknoten (Kindknoten) zentral koordiniert, und der Datenaustausch zwischen Kindknoten wird nur über den Elternknoten ausgeführt.
Der aktive Knoten (Knoten 1) kann ohne Zwischenhändler Daten zur Replikation mit einem anderen aktiven Knoten (Knoten 2) austauschen.
In beiden Fällen werden Daten per Push und Pull ausgetauscht. In diesem Beispiel sehen wir uns die Aktiv-Aktiv-Konfiguration an. Beschreiben Sie die gesamte Architektur zu lange. Lesen Sie daher die Anleitung , um mehr über SymmetricDS zu erfahren.
Die Installation von SymmetricDS ist sehr einfach: Laden Sie die Open Source-Version der Zip-Datei von hier herunter und extrahieren Sie sie, wo immer Sie möchten. Die folgende Tabelle enthält Informationen zum Installationsort und zur Version von SymmetricDS in diesem Beispiel sowie zu Datenbankversionen, Linux-Versionen, IP-Adressen und Ports für beide Knoten.
Hier installieren wir SymmetricDS in /usr/local/symmetric-server-3.9.20, und verschiedene Unterverzeichnisse und Dateien werden genau dort gespeichert. Wir interessieren uns für die verschachtelten Verzeichnisse, Beispiele und Engines. Das Beispielverzeichnis enthält Beispielkonfigurationsdateien mit Host-Eigenschaften sowie Beispiel-SQL-Skripte, um die Demonstration schnell zu starten.
Im Beispielverzeichnis sehen wir drei Konfigurationsdateien mit Knoteneigenschaften - der Name zeigt die Art des Knotens in einem bestimmten Schema.
corp-000.properties store-001.properties store-002.properties
SymmetricDS verfügt über alle erforderlichen Konfigurationsdateien für ein 3-Knoten-Basisschema (Option 1), und dieselben Dateien können für ein 2-Knoten-Schema verwendet werden (Option 2). Kopieren Sie die gewünschte Konfigurationsdatei aus dem Beispielverzeichnis in die Engines auf dem VM1-Host. Es stellt sich so heraus:
$> cat engines/corp-000.properties engine.name=corp-000 db.driver=com.mysql.jdbc.Driver db.url=jdbc:mysql://192.168.1.107:3306/replica_db?autoReconnect=true&useSSL=false db.user=root db.password=admin123 registration.url= sync.url=http://192.168.1.107:31415/sync/corp-000 group.id=corp external.id=000
Dieser Knoten in der SymmetricDS-Konfiguration heißt corp-000, und die Datenbankverbindung wird vom mysql jdbc-Treiber verarbeitet, der die oben angegebene Verbindungszeichenfolge und die Anmeldeinformationen verwendet. Wir stellen eine Verbindung zur Datenbank replica_db her und Tabellen werden während der Erstellung des Schemas erstellt. sync.url zeigt den Ort der Kommunikation mit dem Knoten für die Synchronisation.
Knoten 2 auf dem VM2-Host ist als Speicher-001 konfiguriert, und der Rest ist in der folgenden Datei node.properties angegeben. Auf dem Knoten store-001 wird die PostgreSQL-Datenbank ausgeführt, und pgdb_replica ist die Datenbank für die Replikation. Mit register.url kann der vm2-Host den vm1-Host kontaktieren und Konfigurationsdetails von ihm abrufen.
$> cat engines/store-001.properties engine.name=store-001 db.driver=org.postgresql.Driver db.url=jdbc:postgresql://192.168.1.112:5832/pgdb_replica db.user=postgres db.password=admin123 registration.url=http://192.168.1.107:31415/sync/corp-000 group.id=store external.id=001
Das vorgefertigte Beispiel für SymmetricDS enthält Optionen zum Einrichten der bidirektionalen Replikation zwischen zwei Datenbankservern (zwei Knoten). Die folgenden Schritte werden auf dem vm1-Host (corp-000) ausgeführt, wodurch ein Beispielschema mit 4 Tabellen erstellt wird. Wenn Sie dann create-sym-tables mit dem Befehl symadmin ausführen, werden Verzeichnistabellen erstellt, in denen Regeln und Replikationsrichtung zwischen Knoten gespeichert werden. Schließlich werden Beispieldaten in die Tabellen geladen.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin vm1$> ./dbimport --engine corp-000 --format XML create_sample.xml vm1$> ./symadmin --engine corp-000 create-sym-tables vm1$> ./dbimport --engine corp-000 insert_sample.sql
In diesem Beispiel werden die Tabellen item und item_selling_price automatisch so konfiguriert, dass sie von corp-000 nach store-001 repliziert werden, und die Verkaufstabellen (sale_transaction und sale_return_line_item) werden automatisch so konfiguriert, dass sie von store-001 nach corp-000 repliziert werden. Erstellen Sie nun das Schema in der PostgreSQL-Datenbank auf dem vm2-Host (store-001), um es für den Empfang von Daten von corp-000 vorzubereiten.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin vm2$> ./dbimport --engine store-001 --format XML create_sample.xml
Stellen Sie sicher, dass die MySQL-Datenbank auf VM1 Beispieltabellen und SymmetricDS-Verzeichnistabellen enthält. Beachten Sie, dass die SymmetricDS-Systemtabellen (mit dem Präfix sym_) jetzt nur auf dem corp-000-Host verfügbar sind, da wir dort den Befehl create-sym-tables ausgeführt haben und die Replikation verwalten. Und in der Datenbank auf dem Store-001-Knoten gibt es nur 4 Beispieltabellen ohne Daten.
Das ist alles. Die Umgebung ist bereit, sym Server-Prozesse auf beiden Knoten auszuführen, wie unten gezeigt.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin vm1$> sym 2>&1 &
Protokolleinträge werden an die Hintergrundprotokolldatei (symmetric.log) im Protokollordner des Verzeichnisses, in dem SymmetricDS installiert ist, sowie an die Standardausgabe gesendet. Der Sym-Server kann jetzt auf dem Store-001-Knoten initiiert werden.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin vm2$> sym 2>&1 &
Wenn Sie den Sym-Server-Prozess auf dem VM2-Host ausführen, werden die SymmetricDS-Katalogtabellen auch in der PostgreSQL-Datenbank erstellt. Wenn Sie den Sym-Server-Prozess auf beiden Knoten ausführen, werden diese miteinander koordiniert, um Daten von corp-000 nach store-001 zu replizieren. Wenn wir nach einigen Sekunden alle 4 Tabellen auf beiden Seiten abfragen, sehen wir, dass die Replikation erfolgreich ist. Oder Sie können den Bootstrap mit dem folgenden Befehl von corp-000 an store-001 senden.
vm1$> ./symadmin --engine corp-000 reload-node 001
Zu diesem Zeitpunkt wird ein neuer Datensatz in die Elementtabelle in der MySQL-Datenbank auf Host corp-000 (Host: vm1) eingefügt, und Sie können seine Replikation in die PostgreSQL-Datenbank auf Host Store-001 (Host: vm2) überprüfen. Wir sehen eine Pull-Operation, um Daten von corp-000 nach store-001 zu verschieben.
mysql> insert into item values ('22000002','Jelly Bean'); Query OK, 1 row affected (0.00 sec)
vm2$> psql -p 5832 -U postgres pgdb_replica -c "select * from item" item_id | name ----------+----------- 11000001 | Yummy Gum 22000002 | Jelly Bean (2 rows)
Um eine Push-Operation zum Verschieben von Daten von store-001 nach corp-000 auszuführen, fügen Sie einen Datensatz in die Tabelle sale_transaction ein und überprüfen Sie, ob die Replikation abgeschlossen ist.
Ergebnis.
Wir sehen eine erfolgreiche Einrichtung der bidirektionalen Replikation von Beispieltabellen zwischen MySQL- und PostgreSQL-Datenbanken. Gehen Sie wie folgt vor, um die Replikation für neue Benutzertabellen zu konfigurieren: Wir erstellen die Tabelle t1 als Beispiel und konfigurieren die Regeln für ihre Replikation wie folgt. Daher konfigurieren wir nur die Replikation von corp-000 nach store-001.
mysql> create table t1 (no integer); Query OK, 0 rows affected (0.01 sec)
mysql> insert into sym_channel (channel_id,create_time,last_update_time) values ('t1',current_timestamp,current_timestamp); Query OK, 1 row affected (0.01 sec)
mysql> insert into sym_trigger (trigger_id, source_table_name,channel_id, last_update_time, create_time) values ('t1', 't1', 't1', current_timestamp, current_timestamp); Query OK, 1 row affected (0.01 sec)
mysql> insert into sym_trigger_router (trigger_id, router_id, Initial_load_order, create_time,last_update_time) values ('t1', 'corp-2-store-1', 1, current_timestamp,current_timestamp); Query OK, 1 row affected (0.01 sec)
Anschließend wird die Konfiguration über die Änderung des Schemas informiert, dh über das Hinzufügen einer neuen Tabelle mithilfe des Befehls symadmin mit dem Argument sync-triggers, mit dem die Trigger neu erstellt werden, damit sie mit den Tabellendefinitionen übereinstimmen. Das Sendeschema wird ausgeführt, um die Schemaänderungen an den Store-001-Knoten zu senden, und die t1-Tabellenreplikation wird konfiguriert.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers vm1$> ./symadmin send-schema -e corp-000 --node=001 t1
Vorteile von SymmetricDS
Einfache Installation und Konfiguration, einschließlich eines vorgefertigten Satzes von Dateien mit Parametern zum Erstellen einer Schaltung mit drei oder zwei Knoten.
Plattformübergreifende Datenbanken und Plattformunabhängigkeit, einschließlich Server, Laptops und Mobilgeräte.
Replizieren Sie eine Datenbank lokal, in einem WAN oder in der Cloud in eine andere Datenbank.
Die Fähigkeit, optimal mit ein paar Datenbanken oder mehreren Tausend zu arbeiten, um die Replikation zu vereinfachen.
Bezahlte Version mit grafischer Oberfläche und hervorragender Unterstützung.
SymmetricDS Nachteile
Es ist erforderlich, die Regeln und die Replikationsrichtung manuell über die SQL-Anweisungen in der Befehlszeile zu bestimmen, um Verzeichnistabellen zu laden, was unpraktisch ist.
Das Einrichten vieler Tabellen für die Replikation kann mühsam sein, wenn Sie keine Skripts zum Erstellen von SQL-Anweisungen verwenden, die die Regeln und die Richtung der Replikation definieren.
In die Protokolle werden zu viele Informationen eingegeben, und manchmal müssen Sie die Protokolldatei bereinigen, damit sie nicht zu viel Speicherplatz beansprucht.
SymmetricDS-Zusammenfassung
Mit SymmetricDS können Sie die bidirektionale Replikation zwischen zwei, drei oder sogar mehreren tausend Knoten konfigurieren, um Dateien zu replizieren und zu synchronisieren. Dies ist ein einzigartiges Tool, das unabhängig viele Aufgaben ausführt, z. B. automatische Datenwiederherstellung nach langen Ausfallzeiten auf einem Knoten, sicherer und effizienter Datenaustausch zwischen Knoten über HTTPS, automatisches Konfliktmanagement basierend auf einer Reihe von Regeln usw. SymmetricDS repliziert zwischen beliebigen Datenbanken. Daher kann es für eine Vielzahl von Szenarien verwendet werden, einschließlich Migration, Aktualisierung, Verteilung, Filterung und Datenkonvertierung über Plattformen hinweg.
Das Beispiel basiert auf der offiziellen SymmetricDS-Kurzanleitung. Im Benutzerhandbuch werden verschiedene Konzepte zum Konfigurieren der Replikation mit SymmetricDS beschrieben.