Ein Überblick über die PostgreSQL- und MySQL-Kreuzreplikation

Dieser Blog soll einen Überblick über die Kreuzreplikation zwischen PostgreSQL und MySQL geben und die Methoden zur Konfiguration der Kreuzreplikation zwischen den beiden Datenbankservern weiter diskutieren. Traditionell werden die Datenbanken, die an einem Cross-Replication-Setup beteiligt sind, als heterogene Datenbanken bezeichnet, was ein guter Ansatz ist, um von einem RDBMS-Server zu einem anderen zu wechseln.

Sowohl PostgreSQL- als auch MySQL-Datenbanken sind herkömmliche RDBMS-Datenbanken, bieten aber auch NoSQL-Funktionen mit zusätzlichen Erweiterungen, um das Beste aus beiden Welten zu haben. Dieser Artikel konzentriert sich auf die Diskussion der Replikation zwischen PostgreSQL und MySQL aus einer RDBMS-Perspektive.

Eine erschöpfende Erläuterung der Interna der Replikation liegt nicht im Aufgabenbereich dieses Blogs, jedoch sollen einige grundlegende Elemente diskutiert werden, um dem Publikum ein Verständnis dafür zu vermitteln, wie die Replikation zwischen Datenbankservern konfiguriert ist, Vorteile, Einschränkungen und vielleicht einige bekannte Anwendungsfälle.

Im Allgemeinen wird die Replikation zwischen zwei identischen Datenbankservern entweder im Binärmodus oder im Abfragemodus zwischen einem Master-Knoten (auch Publisher, primär oder aktiv genannt) und einem Slave-Knoten (Subscriber, Standby oder Passiv) erreicht. Das Ziel der Replikation besteht darin, eine Echtzeitkopie der Master-Datenbank auf der Slave-Seite bereitzustellen, wo die Daten vom Master zum Slave übertragen werden, wodurch ein Aktiv-Passiv-Setup gebildet wird, da die Replikation nur so konfiguriert ist, dass sie in eine Richtung erfolgt. Andererseits kann die Replikation zwischen zwei Datenbanken in beide Richtungen konfiguriert werden, sodass die Daten auch vom Slave zurück zum Master übertragen werden können, wodurch eine Aktiv-Aktiv-Konfiguration eingerichtet wird. All dies kann zwischen zwei oder mehreren identischen Datenbankservern konfiguriert werden, die auch eine kaskadierende Replikation beinhalten können. Die Konfiguration von aktiv-aktiv oder aktiv-passiv hängt wirklich von den geschäftlichen Anforderungen, der Verfügbarkeit solcher Funktionen innerhalb der nativen Konfiguration oder der Verwendung externer Lösungen zur Konfiguration und anwendbaren Kompromissen ab.

Die oben erwähnte Konfiguration kann mit diversen Datenbankservern ausgeführt werden, wobei ein Datenbankserver so konfiguriert werden kann, dass er replizierte Daten von einem anderen, völlig unterschiedlichen Datenbankserver akzeptiert und dennoch einen Echtzeit-Snapshot der replizierten Daten aufrechterhält. Sowohl MySQL- als auch PostgreSQL-Datenbankserver bieten die meisten der oben besprochenen Konfigurationen entweder in ihrem eigenen Ursprung oder mit Hilfe von Erweiterungen von Drittanbietern, einschließlich binärer Protokollmethode, Festplattenblockmethode, anweisungsbasierter und zeilenbasierter Methoden.

Die Anforderung, eine Kreuzreplikation zwischen MySQL und PostgreSQL zu konfigurieren, ergibt sich eigentlich aus einem einmaligen Migrationsaufwand, um von einem Datenbankserver zu einem anderen zu wechseln. Da beide Datenbanken unterschiedliche Protokolle verwenden, können sie nicht direkt miteinander kommunizieren. Um diesen Kommunikationsfluss zu erreichen, gibt es ein externes Open-Source-Tool wie pg_chameleon.

Hintergrund von pg_chamäleon

pg_chameleon ist ein in Python 3 entwickeltes MySQL-zu-PostgreSQL-Replikationssystem. Es verwendet eine Open-Source-Bibliothek namens mysql-replication, die ebenfalls mit Python entwickelt wurde. Die Funktionalität umfasst das Abrufen von Zeilenbildern von MySQL-Tabellen und das Speichern dieser als JSONB-Objekte in einer PostgreSQL-Datenbank, die von einer pl/pgsql-Funktion weiter dekodiert wird, und das Wiedergeben dieser Änderungen in der PostgreSQL-Datenbank.

Funktionen von pg_chamäleon

• Mehrere MySQL-Schemas aus demselben Cluster können auf eine einzelne PostgreSQL-Zieldatenbank repliziert werden, wodurch eine Viele-zu-Eins-Replikationskonfiguration entsteht
• Die Quell- und Zielschemanamen können nicht identisch sein
• Replizierungsdaten können aus der kaskadierenden MySQL-Replikation abgerufen werden
• Tabellen, die nicht repliziert werden oder Fehler generieren, sind ausgeschlossen
• Jede Replikationsfunktion wird mit Hilfe von Daemons verwaltet
• Steuerung mit Hilfe von Parametern und Konfigurationsdateien basierend auf YAML-Konstrukt

Demo

Bereiten Sie zunächst das Setup mit allen Voraussetzungen vor, die für die Installation von pg_chamäleon erforderlich sind. In dieser Demo wird Python 3.6.8 installiert, eine virtuelle Umgebung erstellt und zur Verwendung 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 erfolgreicher Installation von Python 3.6 sind weitere Zusatzvoraussetzungen wie das Erstellen und Aktivieren einer virtuellen Umgebung erfüllt. Darüber hinaus wird das pip-Modul auf die neueste Version aktualisiert und zur Installation von pg_chamäleon verwendet. In den folgenden Befehlen wurde pg_chamäleon 2.0.9 absichtlich installiert, während die neueste Version 2.0.10 ist. Dies geschieht, um neu eingeführte 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

Der nächste Schritt besteht darin, pg_chameleon (Chamäleon ist der Befehl) mit dem Argument set_configuration_files aufzurufen, damit pg_chameleon Standardverzeichnisse und Konfigurationsdateien erstellen kann.

(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

Erstellen Sie nun eine Kopie von config-example.yml als default.yml, um sie zur Standardkonfigurationsdatei zu machen. Eine Beispielkonfigurationsdatei, die für diese Demo verwendet wird, 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 in dieser Demo verwendete Konfigurationsdatei ist die Beispieldatei, die mit pg_chameleon geliefert wird, mit geringfügigen Änderungen, um sie an die Quell- und Zielumgebung anzupassen, und es folgt eine Zusammenfassung verschiedener Abschnitte der Konfigurationsdatei.

Die Konfigurationsdatei default.yml hat einen Abschnitt „Globale Einstellungen“, der Details wie Speicherort der Sperrdatei, Protokollierungsspeicherorte und Aufbewahrungszeitraum usw. steuert. Der nächste Abschnitt ist der Abschnitt „Typüberschreibung“, der eine Reihe von Regeln enthält, die außer Kraft gesetzt werden müssen Typen während der Replikation. Standardmäßig wird eine Mustertyp-Überschreibungsregel verwendet, die ein tinyint(1) in einen booleschen Wert umwandelt. Der nächste Abschnitt ist der Abschnitt mit den Verbindungsdetails der Zieldatenbank, bei dem es sich in unserem Fall um eine PostgreSQL-Datenbank handelt, die mit „pg_conn“ gekennzeichnet ist. Der letzte Abschnitt ist der Quellabschnitt, der alle Details zu den Verbindungseinstellungen der Quelldatenbank, Schemazuordnung zwischen Quelle und Ziel, alle zu überspringenden Tabellen enthält, einschließlich Einstellungen für Zeitüberschreitung, Arbeitsspeicher und Stapelgröße. Beachten Sie die „Quellen“, die darauf hinweisen, dass es mehrere Quellen zu einem einzelnen Ziel geben kann, um eine Viele-zu-Eins-Replikationseinrichtung zu bilden.

In dieser Demo wird eine „world_x“-Datenbank verwendet, eine Beispieldatenbank mit 4 Tabellen, die Beispielzeilen enthalten, die die MySQL-Community zu Demozwecken anbietet und die hier heruntergeladen werden kann. Die Beispieldatenbank wird als tar- und komprimiertes Archiv zusammen mit Anweisungen zum Erstellen und Importieren von Zeilen darin geliefert.

Sowohl in der MySQL- als auch in der PostgreSQL-Datenbank wird ein dedizierter Benutzer mit demselben Namen wie usr_replica erstellt, dem außerdem zusätzliche Berechtigungen für MySQL gewährt werden, um Lesezugriff auf alle zu replizierenden Tabellen zu haben.

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 Datenbank erstellt, die Änderungen von der MySQL-Datenbank mit dem Namen „db_replica“ akzeptiert. Der Benutzer „usr_replica“ in PostgreSQL wird automatisch als Eigentümer von zwei Schemas wie „pgworld_x“ und „sch_chameleon“ konfiguriert, die die tatsächlichen replizierten Tabellen bzw. Katalogtabellen der Replikation enthalten. Diese automatische Konfiguration erfolgt durch das weiter unten angegebene Argument create_replica_schema.

postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASE

Die MySQL-Datenbank wird mit einigen Parameteränderungen konfiguriert, um sie für die Replikation vorzubereiten, wie unten gezeigt, und sie erfordert einen Neustart des Datenbankservers, damit die Änderungen wirksam werden.

$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1

An diesem Punkt ist es wichtig, die Konnektivität zu beiden Datenbankservern zu testen, um sicherzustellen, dass es keine Probleme gibt, wenn pg_chameleon-Befehle ausgeführt werden.

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

Mit den nächsten drei Befehlen von pg_chameleon (Chamäleon) richtet es die Umgebung ein, fügt eine Quelle hinzu und initialisiert ein Replikat. Das „create_replica_schema“-Argument von pg_chameleon erstellt das Standardschema (sch_chameleon) und das Replikationsschema (pgworld_x) in der PostgreSQL-Datenbank, wie bereits besprochen wurde. Das Argument „add_source“ fügt die Quelldatenbank zur Konfiguration hinzu, indem es die Konfigurationsdatei (default.yml) liest, die in diesem Fall „mysql“ ist, während das Argument „init_replica“ die Konfiguration basierend auf den Einstellungen der Konfigurationsdatei initialisiert.

$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debug

Die Ausgabe der drei obigen Befehle ist selbsterklärend und zeigt den Erfolg jedes Befehls mit einer offensichtlichen Ausgabemeldung an. Alle Fehler oder Syntaxfehler werden in einfachen und einfachen Meldungen deutlich erwähnt, wodurch Korrekturmaßnahmen vorgeschlagen und veranlasst werden.

Der letzte Schritt besteht darin, die Replikation mit „start_replica“ zu starten, dessen Erfolg wie unten gezeigt durch einen Ausgabehinweis angezeigt wird.

$> chameleon start_replica --config default --source mysql 
output: Starting the replica process for source mysql

Der Status der Replikation kann mit dem Argument „show_status“ abgefragt werden, während Fehler mit dem Argument „show_errors“ angezeigt werden können.

$> chameleon show_status --source mysql  
OUTPUT: 
  Source id  Source name    Type    Status    Consistent    Read lag    Last read    Replay lag    Last replay
-----------  -------------  ------  --------  ------------  ----------  -----------  ------------  -------------
          1  mysql          mysql   running   No            N/A                      N/A

== Schema mappings ==
Origin schema    Destination schema
---------------  --------------------
world_x          pgworld_x

== Replica status ==
---------------------  ---
Tables not replicated  0
Tables replicated      4
All tables             4
Last maintenance       N/A
Next maintenance       N/A
Replayed rows
Replayed DDL
Skipped rows
---------------------  ---
$> chameleon show_errors --config default 
output: There are no errors in the log

Wie bereits erwähnt, wird jede der Replikationsfunktionen mit Hilfe von Daemons verwaltet, die durch Abfragen der Prozesstabelle mit dem unten gezeigten Linux-Befehl „ps“ angezeigt werden können.

$>  ps -ef|grep chameleon
root       763     1  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       764   763  0 19:20 ?        00:00:01 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       765   763  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql

Keine Replikationseinrichtung ist abgeschlossen, bis sie dem „Echtzeitanwendungstest“ unterzogen wird, der wie unten simuliert wurde. Es beinhaltet das Erstellen einer Tabelle und das Einfügen einiger Datensätze in die MySQL-Datenbank. Anschließend wird das „sync_tables“-Argument von pg_chameleon aufgerufen, um die Daemons zu aktualisieren, um die Tabelle zusammen mit ihren 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.

Der Test wird bestätigt, indem die Tabelle aus der PostgreSQL-Datenbank abgefragt wird, um die Zeilen widerzuspiegeln.

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

Wenn es sich um ein Migrationsprojekt handelt, markieren die folgenden pg_chameleon-Befehle das Ende des Migrationsaufwands. Die Befehle sollten ausgeführt werden, nachdem bestätigt wurde, dass Zeilen aller Zieltabellen repliziert wurden und das Ergebnis eine sauber migrierte PostgreSQL-Datenbank ohne Verweise auf die Quelldatenbank oder das Replikationsschema (sch_chameleon) sein wird.

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

Optional löschen die folgenden Befehle die Quellkonfiguration und das Replikationsschema.

$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debug

Vorteile der Verwendung von pg_chamäleon

• Einfache Einrichtung und weniger komplizierte Konfiguration
• Schmerzlose Fehlerbehebung und Erkennung von Anomalien mit leicht verständlicher Fehlerausgabe
• Zusätzliche Ad-hoc-Tabellen können der Replikation nach der Initialisierung hinzugefügt werden, ohne andere Konfigurationen zu ändern
• Mehrere Quellen können für eine einzige Zieldatenbank konfiguriert werden, was bei Konsolidierungsprojekten nützlich ist, um Daten aus einer oder mehreren MySQL-Datenbanken in einer einzigen PostgreSQL-Datenbank zusammenzuführen
• Ausgewählte Tabellen können von der Replikation übersprungen werden

Nachteile der Verwendung von pg_chamäleon

• Nur unterstützt ab MySQL 5.5 als Ursprungsdatenbank und ab PostgreSQL 9.5 als Zieldatenbank
• Erfordert, dass jede Tabelle einen Primärschlüssel oder einen eindeutigen Schlüssel hat, andernfalls werden die Tabellen während des init_replica-Prozesses initialisiert, aber sie werden nicht repliziert
• Replikation in eine Richtung, d. h. MySQL zu PostgreSQL. Dadurch wird die Verwendung auf nur eine Aktiv-Passiv-Konfiguration beschränkt
• Die Quelldatenbank kann nur eine MySQL-Datenbank sein, während die Unterstützung für die PostgreSQL-Datenbank als Quelle mit weiteren Einschränkungen experimentell ist (klicken Sie hier, um mehr zu erfahren)

pg_chamäleon Zusammenfassung

Der von pg_chameleon angebotene Replikationsansatz ist günstig für eine Datenbankmigration von MySQL nach PostgreSQL. Eine der erheblichen Einschränkungen der unidirektionalen Replikation kann jedoch Datenbankexperten davon abhalten, sie für etwas anderes als die Migration einzusetzen. Dieser Nachteil der unidirektionalen Replikation kann mit einem weiteren Open-Source-Tool namens SymmetricDS behoben werden.

Um das Dienstprogramm genauer zu studieren, lesen Sie bitte die offizielle Dokumentation hier. Die Befehlszeilenreferenz erhalten Sie hier.

Ein Überblick über SymmetricDS

SymmetricDS ist ein Open-Source-Tool, das in der Lage ist, jede Datenbank in jede andere Datenbank aus der beliebten Liste von Datenbankservern wie Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird und andere Cloud-basierte Datenbankinstanzen wie Redshift und Azure usw. Einige der Angebote umfassen Datenbank- und Dateisynchronisierung, Multi-Master-Replikation, gefilterte Synchronisierung und Transformation. Das Tool wird mit Java entwickelt und erfordert eine Standard Edition (Version 8.0 oder höher) von JRE oder JDK. Die Funktionalität umfasst Datenänderungen, die von Triggern in der Quelldatenbank erfasst und als ausgehende Batches an eine teilnehmende Zieldatenbank weitergeleitet werden

Funktionen von SymmetricDS

• Plattformunabhängig, was bedeutet, dass zwei oder mehr unterschiedliche Datenbanken miteinander kommunizieren können, jede Datenbank mit jeder anderen Datenbank
• Relationale Datenbanken erzielen die Synchronisierung durch Änderungsdatenerfassung, während dateisystembasierte Systeme die Dateisynchronisierung verwenden
• Bidirektionale Replikation mit Push- und Pull-Methode, die auf der Grundlage festgelegter Regeln durchgeführt wird
• Die Datenübertragung kann auch über sichere Netzwerke mit geringer Bandbreite erfolgen
• Automatische Wiederherstellung während der Wiederaufnahme eines abgestürzten Knotens und automatische Konfliktlösung
• Cloud-fähig und enthält leistungsstarke Erweiterungs-APIs

Demo

SymmetricDS kann in einer der beiden Optionen konfiguriert werden:

• Ein Master-(Eltern-)Knoten, der als zentraler Vermittler fungiert, der die Datenreplikation zwischen zwei Slave-(Kind-)Knoten koordiniert, wobei die Kommunikation zwischen den beiden Kindknoten nur über den Elternknoten erfolgen kann.
• Ein aktiver Knoten (Knoten1) kann ohne Vermittler zu und von einem anderen aktiven Knoten (Knoten2) replizieren.

Bei beiden Optionen erfolgt die Kommunikation zwischen den Knoten über „Push“- und „Pull“-Events. In dieser Demo wird eine Aktiv-Aktiv-Konfiguration zwischen zwei Knoten erklärt. Die vollständige Architektur kann erschöpfend sein, daher werden die Leser ermutigt, das hier verfügbare Benutzerhandbuch zu lesen, um mehr über die Interna von SymmetricDS zu erfahren.

Die Installation von SymmetricDS ist so einfach wie das Herunterladen der Open-Source-Version der ZIP-Datei von hier und das Extrahieren an einem geeigneten Ort. Die Details zum Installationsort und zur Version von SymmetricDS in dieser Demo sind der nachstehenden Tabelle zu entnehmen, zusammen mit anderen Details zu Datenbankversionen, Linux-Versionen, IP-Adressen und Kommunikationsport für beide teilnehmenden Knoten.

Das Installationsverzeichnis ist in diesem Fall „/usr/local/symmetric-server-3.9.20“, das das Ausgangsverzeichnis von SymmetricDS ist, das verschiedene andere Unterverzeichnisse und Dateien enthält. Zwei der nun wichtigen Unterverzeichnisse sind „samples“ und „engines“. Das Beispielverzeichnis enthält neben Beispiel-SQL-Skripts Beispiele für Konfigurationsdateien für Knoteneigenschaften, um eine schnelle Demo zu starten.

Die folgenden drei Knoteneigenschaften-Konfigurationsdateien können im „samples“-Verzeichnis mit Namen gesehen werden, die die Art des Knotens in einem gegebenen Setup angeben.

corp-000.properties
store-001.properties
store-002.properties

Da SymmetricDS mit allen notwendigen Konfigurationsdateien geliefert wird, um ein einfaches 3-Knoten-Setup (Option 1) zu unterstützen, ist es praktisch, dieselben Konfigurationsdateien auch zum Einrichten eines 2-Knoten-Setups (Option 2) zu verwenden. Die beabsichtigte Konfigurationsdatei wird aus dem Verzeichnis „samples“ in die „engines“ auf Host vm1 kopiert und sieht wie folgt aus.

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

Der Name dieses Knotens in der SymmetricDS-Konfiguration lautet „corp-000“, wobei die Datenbankverbindung mit dem mysql-jdbc-Treiber unter Verwendung der oben angegebenen Verbindungszeichenfolge zusammen mit den Anmeldedaten verwaltet wird. Die zu verbindende Datenbank ist „replica_db“, und die Tabellen werden während der Erstellung des Beispielschemas erstellt. Die „sync.url“ bezeichnet den Ort, an dem der Knoten zur Synchronisierung kontaktiert werden soll.

Der Knoten 2 auf Host vm2 ist als „store-001“ konfiguriert, wobei die restlichen Details wie in der unten gezeigten Datei node.properties konfiguriert sind. Der „store-001“-Knoten führt eine PostgreSQL-Datenbank mit „pgdb_replica“ als Datenbank für die Replikation aus. Die „registration.url“ ermöglicht es Host „vm2“, mit Host „vm1“ zu kommunizieren, um Konfigurationsdetails 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

Die vorkonfigurierte Standarddemo von SymmetricDS enthält Einstellungen 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. Darüber hinaus erstellt die Ausführung von „create-sym-tables“ mit dem Befehl „symadmin“ die Katalogtabellen, die die Regeln und die Richtung der Replikation zwischen den Knoten speichern und steuern. Schließlich werden die Demotabellen mit Beispieldaten 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

Die Demo-Tabellen „item“ und „item_selling_price“ werden automatisch konfiguriert, um von corp-000 bis store-001 zu replizieren, während die Verkaufstabellen (sale_transaction und sale_return_line_item) automatisch konfiguriert werden, um von store-001 bis corp-000 zu replizieren. Der nächste Schritt besteht darin, das Beispielschema in der PostgreSQL-Datenbank auf Host vm2 (store-001) zu erstellen, 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

Es ist wichtig, zu diesem Zeitpunkt das Vorhandensein von Demotabellen und SymmetricDS-Katalogtabellen in der MySQL-Datenbank auf vm1 zu überprüfen. Beachten Sie, dass die SymmetricDS-Systemtabellen (Tabellen mit dem Präfix „sym_“) zu diesem Zeitpunkt nur im Knoten corp-000 verfügbar sind, da dort der Befehl „create-sym-tables“ ausgeführt wurde, der der Ort sein wird um die Replikation zu steuern und zu verwalten. Darüber hinaus enthält die Store-001-Knotendatenbank nur 4 Demotabellen ohne Daten darin.

Die Umgebung ist nun bereit, die „sym“-Serverprozesse auf beiden Knoten zu starten, wie unten gezeigt.

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &

Die Protokolleinträge werden sowohl an eine Hintergrundprotokolldatei (symmetric.log) in einem Protokollverzeichnis im SymmetricDS-Installationsverzeichnis als auch 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 &

Der Start des „sym“-Serverprozesses auf Host vm2 erstellt auch die SymmetricDS-Katalogtabellen in der PostgreSQL-Datenbank. Der Start des „sym“-Serverprozesses auf beiden Knoten veranlasst sie, sich miteinander zu koordinieren, um Daten von corp-000 nach store-001 zu replizieren. Nach einigen Sekunden zeigt das Abfragen aller vier Tabellen auf beiden Seiten die erfolgreichen Replikationsergebnisse. Alternativ kann mit dem folgenden Befehl auch ein Initial Load von corp-000 an den store-001-Knoten gesendet werden.

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

An diesem Punkt wird ein neuer Datensatz in die „item“-Tabelle in der MySQL-Datenbank am Knoten „corp-000“ (Host:vm1) eingefügt und es kann überprüft werden, ob er erfolgreich in die PostgreSQL-Datenbank am Knoten „store-001“ (Host:vm2) repliziert wurde ). Dies zeigt das „Pull“-Ereignis 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)

Das „Push“-Ereignis von Daten von store-001 zu corp-000 kann erreicht werden, indem ein Datensatz in die „sale_transaction“-Tabelle eingefügt und die Replikation bestätigt wird.

pgdb_replica=# insert into "sale_transaction" ("tran_id", "store_id", "workstation", "day", "seq") values (1000, '001', '3', '2007-11-01', 100);
vm1$> [[email protected] ~]#  mysql -uroot -p'admin123' -D replica_db -e "select * from sale_transaction";
+---------+----------+-------------+------------+-----+
| tran_id | store_id | workstation | day        | seq |
+---------+----------+-------------+------------+-----+
|     900 | 001      | 3           | 2012-12-01 |  90 |
|    1000 | 001      | 3           | 2007-11-01 | 100 |
|    2000 | 002      | 2           | 2007-11-01 | 200 |
+---------+----------+-------------+------------+-----+

Dies kennzeichnet die erfolgreiche Konfiguration der bidirektionalen Replikation von Demotabellen zwischen einer MySQL- und einer PostgreSQL-Datenbank. Die Konfiguration der Replikation für neu erstellte Benutzertabellen kann hingegen mit den folgenden Schritten erreicht werden. Für die Demo wird eine Beispieltabelle „t1“ erstellt, und die Regeln ihrer Replikation werden gemäß dem nachstehenden Verfahren konfiguriert. Die Schritte konfigurieren 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)

Danach wird die Konfiguration über die Schemaänderung beim Hinzufügen einer neuen Tabelle benachrichtigt, indem der Befehl symadmin mit dem Argument „sync-triggers“ aufgerufen wird, wodurch die Trigger neu erstellt werden, um Tabellendefinitionen abzugleichen. Führen Sie anschließend „send-schema“ aus, um Schemaänderungen an den store-001-Knoten zu senden, woraufhin die Replikation der „t1“-Tabelle erfolgreich konfiguriert wird.

vm1$> ./symadmin -e corp-000 --node=001 sync-triggers    
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1

Vorteile der Verwendung von SymmetricDS

• Mühelose Installation und Konfiguration, einschließlich eines vorkonfigurierten Satzes von Parameterdateien, um entweder ein 3-Knoten- oder ein 2-Knoten-Setup zu erstellen
• Plattformübergreifende Datenbank aktiviert und plattformunabhängig, einschließlich Server, Laptops und Mobilgeräte
• Replizieren Sie jede Datenbank in jede andere Datenbank, ob lokal, WAN oder Cloud
• Fähig, ein paar Datenbanken bis hin zu mehreren tausend Datenbanken optimal zu handhaben, um Daten nahtlos zu replizieren
• Eine kommerzielle Version der Software bietet eine GUI-gesteuerte Verwaltungskonsole mit einem hervorragenden Support-Paket

Nachteile der Verwendung von SymmetricDS

• Die manuelle Konfiguration über die Befehlszeile kann das Definieren von Regeln und die Richtung der Replikation über SQL-Anweisungen beinhalten, um Katalogtabellen zu laden, was umständlich zu verwalten sein kann
• Das Einrichten einer großen Anzahl von Tabellen für die Replikation ist ein erschöpfender Aufwand, es sei denn, es wird irgendeine Form von Skripting verwendet, um die SQL-Anweisungen zu generieren, die die Regeln und die Richtung der Replikation definieren
• Viele Protokollinformationen verstopfen die Protokolldatei, wodurch eine regelmäßige Wartung der Protokolldatei erforderlich wird, damit die Protokolldatei nicht die Festplatte füllt

SymmetricDS-Zusammenfassung

SymmetricDS bietet die Möglichkeit, eine bidirektionale Replikation zwischen 2 Knoten, 3 Knoten usw. für mehrere tausend Knoten einzurichten, um Daten zu replizieren und eine Dateisynchronisierung zu erreichen. Es ist ein einzigartiges Tool, das viele der selbstheilenden Wartungsaufgaben durchführt, wie z. B. die automatische Wiederherstellung von Daten nach längeren Ausfallzeiten in einem Knoten, sichere und effiziente Kommunikation zwischen Knoten mit Hilfe von HTTPS und automatisches Konfliktmanagement basierend auf festgelegten Regeln , etc. The essential feature of replicating any database to any other database makes SymmetricDS ready to be deployed for a number of use cases including migration, version and patch upgrade, distribution, filtering and transformation of data across diverse platforms.

The demo was created by referring to the official quick-start tutorial of SymmetricDS which can be accessed from here. The user guide can be found here, which provides a detailed account of various concepts involved in a SymmetricDS replication setup.