Kreuzreplikation zwischen PostgreSQL und MySQL

Ich werde kurz auf die Kreuzreplikation zwischen PostgreSQL und MySQL sowie auf Methoden zum Einrichten der Kreuzreplikation zwischen diesen beiden Datenbankservern eingehen. Übergreifend replizierte Datenbanken werden im Allgemeinen als homogene Datenbanken bezeichnet. Dies ist eine praktische Methode für die Migration von einem RDBMS-Server auf einen anderen.

PostgreSQL- und MySQL-Datenbanken gelten traditionell als relational, bieten aber mit zusätzlichen Erweiterungen NoSQL-Funktionen. Hier besprechen wir die Replikation zwischen PostgreSQL und MySQL aus der Perspektive der relationalen Datenbankverwaltung.

Wir werden nicht alle Interna beschreiben, sondern nur die Grundprinzipien, damit Sie eine Vorstellung vom Einrichten der Replikation zwischen Datenbankservern, Vorteilen, Einschränkungen und Anwendungsfällen bekommen.

Normalerweise erfolgt die Replikation zwischen zwei identischen Datenbankservern entweder im Binärmodus oder durch Abfragen zwischen einem Master (auch bekannt als Herausgeber, Master oder aktiv) und einem Slave (Abonnent, Standby oder passiv). Der Zweck der Replikation besteht darin, eine Echtzeitkopie der Masterdatenbank auf der Standby-Seite bereitzustellen. In diesem Fall erfolgt die Datenübertragung vom Master zum Slave, also vom aktiven zum passiven, da die Replikation nur in eine Richtung erfolgt. Sie können jedoch eine Replikation zwischen zwei Datenbanken in beide Richtungen einrichten, sodass die Daten vom Slave zum Master in einer Aktiv-Aktiv-Konfiguration übertragen werden. All dies, einschließlich der kaskadierenden Replikation, ist zwischen zwei oder mehr identischen Datenbankservern möglich. Die Aktiv-Aktiv- oder Aktiv-Passiv-Konfiguration hängt vom Bedarf, der Verfügbarkeit solcher Funktionen in der Erstkonfiguration oder der Verwendung externer Tuning-Lösungen und dem vorhandenen Handel ab -offs .

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 Echtzeit-Snapshots der replizierten Daten speichert. MySQL und PostgreSQL bieten die meisten dieser Konfigurationen nativ oder über Erweiterungen von Drittanbietern an, einschließlich binärer Protokollmethoden, Festplattensperren sowie anweisungs- und zeilenbasierter Methoden.

Für eine einmalige Migration von einem Datenbankserver auf einen anderen ist eine Kreuzreplikation zwischen MySQL und PostgreSQL erforderlich. Diese Datenbanken verwenden unterschiedliche Protokolle, sodass Sie sie nicht direkt verknüpfen können. Um den Datenaustausch zu erleichtern, können Sie ein externes Open-Source-Tool wie pg_chameleon verwenden.

Was ist pg_chameleon

pg_chameleon ist ein Replikationssystem von MySQL nach PostgreSQL in Python 3. Es nutzt die Open-Source-Bibliothek mysql-replication, ebenfalls in Python. Zeilenbilder werden aus MySQL-Tabellen abgerufen und als JSONB-Objekte in der PostgreSQL-Datenbank gespeichert und dann von der pl/pgsql-Funktion dekodiert und in der PostgreSQL-Datenbank wiedergegeben.

Funktionen von pg_chameleon

Mehrere MySQL-Schemata aus demselben Cluster können mit einer Eins-zu-viele-Konfiguration in eine einzelne PostgreSQL-Zieldatenbank repliziert werden
Die Namen des Quell- und Zielschemas dürfen nicht identisch sein.
Replikationsdaten können von einer MySQL-Kaskadenreplik abgerufen werden.
Tabellen, die nicht replizieren oder Fehler erzeugen können, sind ausgeschlossen.
Jede Replikationsfunktion wird von Daemons gesteuert.
Steuerung mit Parametern und Konfigurationsdateien auf Basis von YAML.

Beispiel

Gastgeber
vm1
vm2

OS Version
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Version des Datenbankservers
MySQL 5.7.26
PostgreSQL 10.5

DB-Port
3306
5433

IP-Adresse
192.168.56.102
192.168.56.106

Bereiten Sie zunächst alle notwendigen Komponenten für die Installation von pg_chameleon vor. In diesem Beispiel ist Python 3.6.8 installiert, wodurch eine virtuelle Umgebung erstellt und aktiviert wird.

$> 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

Sobald Python3.6 erfolgreich installiert wurde, müssen die restlichen Anforderungen erfüllt werden, beispielsweise das Erstellen und Aktivieren einer virtuellen Umgebung. Außerdem wird das Pip-Modul auf die neueste Version aktualisiert und zur Installation von pg_chameleon verwendet. Die folgenden Befehle installieren absichtlich pg_chameleon 2.0.9, obwohl die neueste Version 2.0.10 ist. Dies ist notwendig, 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

Anschließend rufen wir pg_chameleon (chameleon ist ein Befehl) mit dem Argument set_configuration_files auf, um pg_chameleon zu aktivieren und die Standardkonfigurationsverzeichnisse und -dateien 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

Wir erstellen nun eine Kopie von config-example.yml als default.yml, sodass es zur Standardkonfigurationsdatei wird. Eine Beispielkonfigurationsdatei für dieses Beispiel finden Sie unten.

$> 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 pg_chameleon-Beispieldatei mit geringfügigen Änderungen, um sie an die Quell- und Zielumgebung anzupassen. Nachfolgend finden Sie eine Übersicht über die verschiedenen Abschnitte der Konfigurationsdatei.

Die Konfigurationsdatei „default.yml“ verfügt über einen Abschnitt mit globalen Einstellungen (globale Einstellungen), in dem Sie Einstellungen wie den Speicherort der Sperrdatei, den Speicherort der Protokolle, den Speicherzeitraum für die Protokolle usw. steuern können. Als nächstes kommt die Typüberschreibung Abschnitt, in dem die Regeln zum Überschreiben von Typen während der Replikation festgelegt werden. Das Standardbeispiel verwendet eine Typüberschreibungsregel, die tinyint(1) in einen booleschen Wert konvertiert. Im nächsten Abschnitt legen wir die Details der Verbindung zur Zieldatenbank fest. In unserem Fall handelt es sich um eine PostgreSQL-Datenbank mit der Bezeichnung pg_conn. Im letzten Abschnitt geben wir die Quelldaten an, also die Verbindungsparameter der Quelldatenbank, das Zuordnungsschema der Quell- und Zieldatenbanken, zu überspringende Tabellen, Timeout, Speicher, Paketgröße. Beachten Sie, dass „Quellen“ im Plural steht, was bedeutet, dass wir mehrere Quelldatenbanken zum gleichen Ziel hinzufügen können, um eine Viele-zu-Eins-Konfiguration einzurichten.

Die Datenbank world_x im Beispiel enthält 4 Tabellen mit Zeilen, die von der MySQL-Community für das Beispiel vorgeschlagen werden. Es kann heruntergeladen werden hier. Die Beispieldatenbank wird als tar- und komprimiertes Archiv mit Anweisungen zum Erstellen und Importieren von Zeichenfolgen geliefert.

In den MySQL- und PostgreSQL-Datenbanken wird ein spezieller Benutzer mit dem gleichen Namen usr_replica erstellt. MySQL gewährt ihm zusätzlichen Lesezugriff auf alle 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 eine db_replica-Datenbank erstellt, die Änderungen aus der MySQL-Datenbank akzeptiert. Der Benutzer usr_replica in PostgreSQL wird automatisch als Eigentümer der beiden Schemas pgworld_x und sch_chameleon konfiguriert, die die tatsächlichen replizierten Tabellen bzw. Replikationskatalogtabellen enthalten. Das Argument create_replica_schema ist für die automatische Konfiguration verantwortlich, wie Sie weiter 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 wurde mit einigen Änderungen konfiguriert, um sie für die Replikation bereit zu machen, 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

Nun ist es wichtig, die Verbindung zu beiden Datenbankservern zu überprüfen, damit es bei der Ausführung der pg_chameleon-Befehle zu keinen Problemen kommt.

Auf dem PostgreSQL-Knoten:

$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x

Auf MySQL-Knoten:

$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica

Die nächsten drei pg_chameleon (chameleon)-Befehle bereiten die Umgebung vor, fügen die Quelle hinzu und initialisieren das Replikat. Das Argument create_replica_schema für pg_chameleon erstellt, wie gesagt, ein Standardschema (sch_chameleon) und ein Replikationsschema (pgworld_x) in der PostgreSQL-Datenbank. Das Argument add_source fügt der Konfiguration eine Quelldatenbank hinzu, indem es die Konfigurationsdatei (default.yml) liest, in unserem Fall mysql, und init_replica initialisiert die Konfiguration basierend auf den Einstellungen 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 deutlich ihren Erfolg. Alle Fehler oder Syntaxfehler werden in einfachen und verständlichen Meldungen mit Hinweisen zur Problembehebung angezeigt.

Abschließend starten wir die Replikation mit start_replica und erhalten 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 abgefragt werden und Fehler können mit dem Argument show_errors angezeigt werden.

Das Ergebnis.

Wie bereits erwähnt, verwalten Dämonen jede Replikationsfunktion. Um sie anzuzeigen, fragen Sie die Prozesstabelle mit dem Linux-Befehl ps ab, wie unten gezeigt.

Das Ergebnis.

Die Replikation gilt erst dann als konfiguriert, wenn wir sie in Echtzeit testen, wie unten gezeigt. Wir erstellen eine Tabelle, fügen ein paar 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 die 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 validieren, fragen wir die Tabelle aus der PostgreSQL-Datenbank ab und geben die Zeilen aus.

$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
 n1 |  n2
----+-------
  1 | one
  2 | two

Wenn wir migrieren, bilden die folgenden pg_chameleon-Befehle das Ende der Migration. Die Befehle sollten ausgeführt werden, nachdem wir überprüft haben, dass die Zeilen aller Zieltabellen repliziert wurden, was zu einer sauber migrierten PostgreSQL-Datenbank ohne Verweise auf die Quelldatenbank oder das Replikationsschema (sch_chameleon) führt.

$> chameleon stop_replica --config default --source mysql 
$> chameleon detach_replica --config default --source mysql --debug

Sie können optional das ursprüngliche Konfigurations- und Replikationsschema mit den folgenden Befehlen löschen.

$> 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 Anomalieerkennung mit klaren Fehlermeldungen.
Nach der Initialisierung können der Replikation weitere spezielle Tabellen hinzugefügt werden, ohne dass sich die restliche Konfiguration ändert.
Es ist möglich, mehrere Quelldatenbanken für eine Zieldatenbank einzurichten. Dies ist sehr praktisch, wenn Sie Daten aus einer oder mehreren MySQL-Datenbanken in einer PostgreSQL-Datenbank zusammenführen.
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ärschlüssel oder einen eindeutigen Schlüssel haben, andernfalls werden die Tabellen im init_replica-Prozess initialisiert, aber nicht repliziert.
Einwegreplikation – nur von MySQL zu PostgreSQL. Daher ist es nur für das Aktiv-Passiv-Schema geeignet.
Die Quelle kann nur eine MySQL-Datenbank sein und die Unterstützung für eine PostgreSQL-Datenbank als Quelle ist nur experimentell und begrenzt (weitere Informationen). hier)

Summen für pg_chameleon

Die Replikationsmethode in pg_chameleon eignet sich hervorragend für die Migration einer Datenbank von MySQL nach PostgreSQL. Der große Nachteil besteht darin, dass die Replikation nur in eine Richtung erfolgt, sodass Datenbankprofis sie wahrscheinlich nicht für andere Zwecke als die Migration verwenden möchten. Das Problem der unidirektionalen Replikation kann jedoch mit einem anderen Open-Source-Tool gelöst werden – SymmetricDS.

Lesen Sie mehr in der offiziellen Dokumentation hier. Es gibt Hilfe zur Befehlszeile hier.

Übersicht über SymmetricDS

SymmetricDS ist ein Open-Source-Tool, das jede Datenbank in jede andere gängige Datenbank repliziert: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird und andere Cloud-Datenbankinstanzen, zum Beispiel Redshift, und Azure usw. Verfügbare Funktionen: Datenbank- und Dateisynchronisierung, Multi-Master-Datenbankreplikation, gefilterte Synchronisierung, Transformation und andere. Dies ist ein Java-Tool und erfordert die Standardversion JRE oder JDK (Version 8.0 oder höher). Hier können Sie Datenänderungen an Triggern in der Quelldatenbank aufzeichnen und diese stapelweise an die entsprechende Zieldatenbank senden.

SymmetricDS-Funktionen

Das Tool ist plattformunabhängig, d. h. zwei oder mehr verschiedene Datenbanken können Daten austauschen.
Relationale Datenbanken werden durch Aufzeichnen von Datenänderungen synchronisiert, und auf Dateisystemen basierende Datenbanken verwenden die Dateisynchronisierung.
Bidirektionale Replikation mit Push- und Pull-Methoden basierend auf einem Regelwerk.
Die Datenübertragung ist über sichere Netzwerke und Netzwerke mit geringer Bandbreite möglich.
Automatische Wiederherstellung, wenn Knoten nach einem Ausfall wieder aufgenommen werden, und automatische Konfliktlösung.
Cloud-kompatible und effiziente Erweiterungs-APIs.

Beispiel

SymmetricDS kann auf zwei Arten konfiguriert werden:
Ein Master-Knoten (übergeordneter Knoten), der die Datenreplikation zwischen zwei Slave-Knoten (untergeordneten Knoten) zentral koordiniert. Der Datenaustausch zwischen untergeordneten Knoten erfolgt nur über den übergeordneten Knoten.
Ein aktiver Knoten (Knoten 1) kann zur Replikation ohne Zwischenhändler mit einem anderen aktiven Knoten (Knoten 2) kommunizieren.

Bei beiden Varianten erfolgt der Datenaustausch per Push und Pull. In diesem Beispiel betrachten wir die Aktiv-Aktiv-Konfiguration. Es ist zu lang, die gesamte Architektur zu beschreiben, also studieren Sie es руководствоum mehr über die SymmetricDS-Appliance zu erfahren.

Die Installation von SymmetricDS ist einfach: Laden Sie die Open-Source-ZIP-Datei herunter daher und extrahieren Sie es, wo immer Sie wollen. In der folgenden Tabelle sind der Installationsort und die Version von SymmetricDS in diesem Beispiel sowie Datenbankversionen, Linux-Versionen, IP-Adressen und Ports für beide Knoten aufgeführt.

Gastgeber
vm1
vm2

OS Version
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Version des Datenbankservers
MySQL 5.7.26
PostgreSQL 10.5

DB-Port
3306
5832

IP-Adresse
192.168.1.107
192.168.1.112

SymmetricDS-Version
SymmetricDS 3.9
SymmetricDS 3.9

SymmetricDS-Installationspfad
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

SymmetricDS-Hostname
corp-000
Laden-001

Hier installieren wir SymmetricDS in /usr/local/symmetric-server-3.9.20 und verschiedene Unterverzeichnisse und Dateien werden dort gespeichert. Uns interessieren die Unterverzeichnisse Samples und Engines. Das Beispielverzeichnis enthält Beispielkonfigurationsdateien mit Knoteneigenschaften sowie Beispiel-SQL-Skripts zum schnellen Starten der Demo.

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 notwendigen Konfigurationsdateien für ein einfaches 3-Knoten-Schema (Option 1) und dieselben Dateien können für ein 2-Knoten-Schema (Option 2) verwendet werden. Kopieren Sie die erforderliche 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 heißt in der SymmetricDS-Konfiguration corp-000 und die Datenbankverbindung wird vom MySQL-JDBC-Treiber verwaltet, der die obige Verbindungszeichenfolge und Anmeldeinformationen verwendet. Wir stellen eine Verbindung zur Datenbank „replica_db“ her und Tabellen werden während der Schemaerstellung erstellt. sync.url zeigt den Link zum zu synchronisierenden Knoten.

Knoten 2 auf Host vm2 ist als „store-001“ konfiguriert und der Rest ist in der folgenden Datei „node.properties“ angegeben. Der Knoten „store-001“ führt die PostgreSQL-Datenbank aus und pgdb_replica ist die zu replizierende Datenbank. Registration.URL ermöglicht es dem VM2-Host, den VM1-Host zu kontaktieren und Konfigurationsdetails von ihm abzurufen.

$> 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 fertige SymmetricDS-Beispiel enthält Optionen zum Einrichten einer bidirektionalen Replikation zwischen zwei Datenbankservern (zwei Knoten). Die folgenden Schritte werden auf Host vm1 (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 die Regeln und die Richtung der Replikation zwischen Knoten gespeichert werden. Abschließend werden die 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

Im Beispiel werden die Tabellen „item“ und „item_selling_price“ automatisch für die Replikation von „corp-000“ nach „store-001“ konfiguriert, und die Verkaufstabellen (sale_transaction und sale_return_line_item) werden automatisch für eine Replikation von „store-001“ nach „corp-000“ konfiguriert. Wir erstellen nun ein Schema in der PostgreSQL-Datenbank auf Host vm2 (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 über Beispieltabellen und eine SymmetricDS-Katalogtabelle verfügt. Beachten Sie, dass die SymmetricDS-Systemtabellen (mit dem Präfix sym_) derzeit nur auf dem Knoten corp-000 verfügbar sind, da wir dort den Befehl create-sym-tables ausgeführt haben und die Replikation verwalten werden. Und in der Datenbank am Knoten „store-001“ gibt es nur 4 Beispieltabellen ohne Daten.

Alle. 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 im Verzeichnis, in dem SymmetricDS installiert ist, sowie an die Standardausgabe gesendet. Der Sym-Server kann nun auf dem Knoten „store-001“ 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 auch die SymmetricDS-Katalogtabellen in der PostgreSQL-Datenbank erstellt. Wenn Sie den Sym-Server-Prozess auf beiden Knoten ausführen, koordinieren sie sich gegenseitig, um Daten von Corp-000 nach Store-001 zu replizieren. Wenn wir nach ein paar Sekunden alle 4 Tabellen auf beiden Seiten abfragen, sehen wir, dass die Replikation erfolgreich war. Oder Sie können den Bootstrap mit dem folgenden Befehl von corp-001 an store-000 senden.

vm1$> ./symadmin --engine corp-000 reload-node 001

Zu diesem Zeitpunkt wird ein neuer Datensatz in die Artikeltabelle in der MySQL-Datenbank auf dem Knoten corp-000 (Host: vm1) eingefügt und kann auf Replikation in die PostgreSQL-Datenbank auf dem Knoten store-001 (Host: vm2) überprüft werden. Wir sehen eine Pull-Operation zum Verschieben von Daten von Corp-000 nach Store-001.

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 einen Push-Vorgang zum Verschieben von Daten von „store-001“ nach „corp-000“ durchzuführen, fügen wir einen Datensatz in die Tabelle „sale_transaction“ ein und überprüfen, ob die Replikation abgeschlossen wurde.

Das Ergebnis.

Wir sehen eine erfolgreiche Einrichtung der bidirektionalen Replikation der Beispieltabellen zwischen den MySQL- und PostgreSQL-Datenbanken. Führen Sie die folgenden Schritte aus, um die Replikation für neue Benutzertabellen einzurichten. Wir erstellen beispielsweise die Tabelle t1 und richten ihre Replikationsregeln wie folgt ein. Deshalb haben wir nur die Replikation von Corp-000 nach Store-001 eingerichtet.

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)

Die Konfiguration wird dann über die Schemaänderung, d. h. das Hinzufügen einer neuen Tabelle, benachrichtigt, indem der Befehl symadmin mit dem Argument sync-triggers verwendet wird, wodurch die Trigger neu erstellt werden, damit sie mit den Tabellendefinitionen übereinstimmen. „Send-schema“ wird ausgeführt, um Schemaänderungen an „store-001“ zu senden, und Tabelle t1 wird repliziert.

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 Dateisatzes mit Parametern zum Erstellen eines Schemas mit drei oder zwei Knoten.
Plattformübergreifende Datenbanken und Plattformunabhängigkeit, einschließlich Servern, Laptops und Mobilgeräten.
Replizieren Sie jede Datenbank lokal, im WAN oder in der Cloud in jede andere Datenbank.
Möglichkeit, für eine einfache Replikation optimal mit einigen oder mehreren Tausend Datenbanken zu arbeiten.
Bezahlversion mit GUI und hervorragendem Support.

Nachteile von SymmetricDS

Sie müssen die Regeln und die Richtung der Replikation manuell über SQL-Anweisungen in der Befehlszeile definieren, um die Katalogtabellen zu laden, was unpraktisch sein kann.
Das Einrichten vieler Tabellen für die Replikation kann mühsam sein, es sei denn, Sie verwenden Skripts zum Erstellen von SQL-Anweisungen, die die Regeln und die Richtung der Replikation definieren.
Die Protokolle enthalten zu viele Informationen und manchmal müssen Sie die Protokolldatei bereinigen, damit sie nicht zu viel Platz beansprucht.

Zusammenfassung von SymmetricDS

Mit SymmetricDS können Sie eine bidirektionale Replikation zwischen zwei, drei oder sogar mehreren tausend Knoten einrichten, um Dateien zu replizieren und zu synchronisieren. Es handelt sich um ein einzigartiges Tool, das viele Aufgaben selbstständig ausführt, wie z. B. die automatische Wiederherstellung von Daten nach einer langen Ausfallzeit auf einem Knoten, sichere und effiziente Kommunikation zwischen Knoten über HTTPS, automatisches Konfliktmanagement basierend auf einem Regelwerk usw. SymmetricDS repliziert zwischen beliebigen Datenbanken und kann daher für eine Vielzahl von Szenarien verwendet werden, einschließlich Migration, Upgrade, Verteilung, Filterung und Datentransformation über Plattformen hinweg.

Das Beispiel basiert auf dem offiziellen Kurzanleitung von SymmetricDS. IN Bedienungsanleitung Beschreibt ausführlich die verschiedenen Konzepte beim Einrichten der Replikation mit SymmetricDS.

Source: habr.com