Ich werde im Großen und Ganzen über die Kreuzreplikation zwischen PostgreSQL und MySQL sprechen und über die Methoden zur Konfiguration der Kreuzreplikation zwischen diesen beiden Datenbankservern. Datenbanken in der Kreuzreplikation werden normalerweise als homogener bezeichnet, und dies ist eine bequeme Methode, um von einem Server der relationalen Datenbankmanagementsystem auf einen anderen zu wechseln.
Die Datenbanken PostgreSQL und MySQL gelten als relationale Systeme, bieten jedoch mit zusätzlichen Erweiterungen NoSQL-Möglichkeiten. Hier werden wir die Replikation zwischen PostgreSQL und MySQL aus der Perspektive relationaler Datenbanken diskutieren.
Wir werden nicht die gesamte interne Funktionsweise beschreiben, sondern nur die grundlegenden Prinzipien, damit Sie ein Verständnis für die Einstellung der Replikation zwischen den Datenbankservern und die Vorteile, Einschränkungen und Anwendungszenarien erhalten.
Normalerweise wird die Replikation zwischen zwei identischen Datenbankservern entweder im binären Modus oder über Anfragen zwischen dem führenden Knoten (Publisher, Master oder aktiv) und dem abhängigen (Subscriber, Wartende oder passiv) durchgeführt. Ziel der Replikation ist es, in Echtzeit eine Kopie der Hauptdatenbank auf der Seite des Abhängigen bereitzustellen. Die Daten werden vom führenden auf den abhängigen Server übertragen, was bedeutet, dass die Replikation nur in eine Richtung erfolgt. Es ist jedoch möglich, die Replikation zwischen zwei Datenbanken in beide Richtungen zu konfigurieren, sodass die Daten vom abhängigen zum führenden Server in einer „aktiv-aktiv“ Konfiguration übertragen werden. All dies, einschließlich der kaskadierenden Replikation, ist zwischen zwei oder mehr identischen Datenbankservern möglich. Die Konfiguration „aktiv-aktiv“ oder „aktiv-passiv“ hängt von den Anforderungen, der Verfügbarkeit solcher Möglichkeiten in der Ausgangskonfiguration oder der Nutzung externer Lösungen zur Einrichtung und bestehenden Kompromissen ab.
Die beschriebene Konfiguration ist zwischen verschiedenen Datenbankservern möglich. Ein Server kann so konfiguriert werden, dass er replizierte Daten von einem anderen Datenbankserver empfängt und dabei Schnappschüsse der replizierten Daten in Echtzeit speichert. MySQL und PostgreSQL bieten die meisten dieser Konfigurationen entweder nativ oder über Drittanbietererweiterungen an, einschließlich Methoden des binären Journals, Festplattensperren und operator- und zeilenbasierter Methoden.
Die Kreuzreplikation zwischen MySQL und PostgreSQL ist für eine einmalige Migration von einem Datenbankserver auf einen anderen erforderlich. Diese Datenbanken verwenden unterschiedliche Protokolle, daher ist eine direkte Verbindung nicht möglich. Um den Datenaustausch zu ermöglichen, kann ein externes Open-Source-Tool wie pg_chameleon verwendet werden.
Was ist pg_chameleon
pg_chameleon ist ein Replikationssystem von MySQL zu PostgreSQL, das auf Python 3 basiert. Es verwendet die Open-Source-Bibliothek mysql-replication, die ebenfalls in Python geschrieben ist. Zeilenabbilder werden aus MySQL-Tabellen extrahiert und als JSONB-Objekte in der PostgreSQL-Datenbank gespeichert, bevor sie mit der pl/pgsql-Funktion decodiert und in der PostgreSQL-Datenbank wiederhergestellt werden.
Funktionen von pg_chameleon
Mehrere MySQL-Schemas aus einem Cluster können in eine Ziel-PostgreSQL-Datenbank mit einer "Eins-zu-Viele"-Konfiguration repliziert werden.
Die Namen des Quell- und Zielschemas dürfen nicht identisch sein.
Replikationsdaten können aus einer kaskadierten MySQL-Replikation extrahiert werden.
Tabellen, die nicht repliziert werden können oder Fehler verursachen, werden ausgeschlossen.
Jede Replikationsfunktion wird von Dämonen verwaltet.
Überwachung mit Parametern und Konfigurationsdateien im YAML-Format.
Beispiel
Host
vm1
vm2
Betriebssystemversion
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64
Datenbankserverversion
MySQL 5.7.26
PostgreSQL 10.5
Datenbankport
3306
5433
IP-Adresse
192.168.56.102
192.168.56.106
Bereiten Sie zunächst alle erforderlichen Komponenten für die Installation von pg_chameleon vor. In diesem Beispiel ist 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 altinstallNach der erfolgreichen Installation von Python 3.6 müssen die weiteren Anforderungen erfüllt werden, zum Beispiel 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. In den folgenden Befehlen wird absichtlich pg_chameleon 2.0.9 installiert, 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.9Dann rufen wir pg_chameleon (chameleon ist der Befehl) mit dem Argument set_configuration_files auf, um pg_chameleon zu aktivieren und die Standardverzeichnisse und Konfigurationsdateien zu erstellen.
(venv) $> chameleon set_configuration_files
Erstelle Verzeichnis /root/.pg_chameleon
Erstelle Verzeichnis /root/.pg_chameleon/configuration/
Erstelle Verzeichnis /root/.pg_chameleon/logs/
Erstelle Verzeichnis /root/.pg_chameleon/pid/
Kopiere Beispieldatei in /root/.pg_chameleon/configuration//config-example.ymlWir erstellen jetzt eine Kopie von config-example.yml als default.yml, damit sie zur Standardkonfigurationsdatei wird. Ein Beispiel für die Konfigurationsdatei für dieses Beispiel ist unten aufgeführt.
$> cat default.yml
---
#globale Einstellungen
pid_dir: '~/.pg_chameleon/pid/'
log_dir: '~/.pg_chameleon/logs/'
log_dest: datei
log_level: info
log_days_keep: 10
rollbar_key: ''
rollbar_env: ''
# type_override ermöglicht es dem Benutzer, die Standardtypenübertragung in einen anderen zu ändern.
type_override:
"tinyint(1)":
override_to: boolean
override_tables:
- "*"
#postgres Zielverbindungsdaten
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 Tag'
copy_max_memory: "300M"
copy_mode: 'datei'
out_dir: /tmp
sleep_loop: 1
on_error_replay: fortsetzen
on_error_read: fortsetzen
auto_maintenance: "deaktiviert"
gtid_enable: Nein
type: mysql
skip_events:
insert:
- delphis_mediterranea.foo #überspringt Einfügungen in die Tabelle delphis_mediterranea.foo
delete:
- delphis_mediterranea #überspringt Löschungen im Schema delphis_mediterranea
update:Die Konfigurationsdatei in diesem Beispiel ist ein Muster für eine Datei mit pg_chameleon mit geringfügigen Anpassungen an die Quell- und Zielumgebungen, und unten finden Sie eine Übersicht über die verschiedenen Abschnitte der Konfigurationsdatei.
In der Konfigurationsdatei default.yml gibt es einen Abschnitt für globale Parameter (global settings), in dem Sie Einstellungen wie den Speicherort der Sperrdatei, den Speicherort der Protokolle, den Zeitraum der Protokollaufbewahrung usw. verwalten können. Danach folgt der Abschnitt Typüberschreibung (type override), in dem eine Reihe von Regeln zur Typüberschreibung während der Replikation angegeben sind. Im Standardbeispiel wird eine Typüberschreibungsregel verwendet, die tinyint(1) in einen booleschen Wert umwandelt. Im nächsten Abschnitt geben wir die Verbindungsdetails zur Ziel-Datenbank an. In unserem Fall handelt es sich um eine PostgreSQL-Datenbank, die als pg_conn bezeichnet wird. Im letzten Abschnitt geben wir die Quellendaten an, also die Verbindungsparameter zur Quell-Datenbank, die Schema-Mappings zwischen der Quell- und Ziel-Datenbank, die zu überspringenden Tabellen, Zeitlimits, Speicher und Paketgrößen. Beachten Sie, dass „sources“ im Plural angegeben ist, das bedeutet, dass wir mehrere Quell-Datenbanken für eine Ziel-Datenbank hinzufügen können, um die Konfiguration „viele zu eins“ einzurichten.
Die Datenbank world_x im Beispiel enthält 4 Tabellen mit Zeilen, die von der MySQL-Community als Beispiel angeboten werden. Sie kann heruntergeladen werden. Das Beispiel für die Datenbank wird in Form eines tar- und komprimierten Archivs mit Anweisungen zum Erstellen und Importieren der Zeilen geliefert.
In den Datenbanken MySQL und PostgreSQL wird ein spezieller Benutzer mit dem gleichen Namen usr_replica 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 empfangen wird. Der Benutzer usr_replica wird in PostgreSQL automatisch als Eigentümer der beiden Schemata pgworld_x und sch_chameleon eingerichtet, die die tatsächlichen replizierten Tabellen bzw. die Tabellen mit Replikationskatalogen enthalten. Für die automatische Konfiguration ist das Argument create_replica_schema 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 DATABASEDie MySQL-Datenbank wird so konfiguriert, dass einige Parameter geändert werden, um sie auf die Replikation vorzubereiten, wie unten gezeigt. Der Datenbankserver muss neu gestartet werden, damit die Änderungen wirksam werden.
$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1Es ist jetzt wichtig, die Verbindung zu beiden Datenbanken zu überprüfen, damit bei der Ausführung der pg_chameleon-Befehle keine Probleme auftreten.
Auf dem PostgreSQL-Knoten:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_xAuf dem MySQL-Knoten:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaDie folgenden drei Befehle von pg_chameleon (chameleon) bereiten die Umgebung vor, fügen die Quelle hinzu und initialisieren die Replik. Das Argument create_replica_schema in pg_chameleon erstellt das Standardschema (sch_chameleon) und das Replikationsschema (pgworld_x) in der PostgreSQL-Datenbank, wie bereits erwähnt. Das Argument add_source fügt die Quell-Datenbank der Konfiguration hinzu, indem es die Konfigurationsdatei (default.yml) liest, und in unserem Fall ist dies mysql, während init_replica die Konfiguration basierend auf den Parametern in der Konfigurationsdatei initialisiert.
$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debugDie Ausgaben dieser drei Befehle weisen eindeutig auf ihre erfolgreiche Ausführung hin. Alle Fehler oder Syntaxprobleme werden in klaren und verständlichen Nachrichten mit Hinweisen zur Problemlösung angezeigt.
Schließlich starten wir die Replikation mit start_replica und erhalten eine Nachricht über den erfolgreichen Abschluss.
$> chameleon start_replica --config default --source mysql
out: Starte den Replikationsprozess für die Quelle mysqlDen Status der Replikation kann man mit dem Argument show_status abfragen, und Fehler können mit dem Argument show_errors angezeigt werden.
Wie bereits erwähnt, werden alle Replikationsfunktionen von Daemons verwaltet. Um diese anzuzeigen, fragen wir die Prozessliste mit dem Linux-Befehl ps an, wie unten gezeigt.
Die Replikation wird nicht als eingerichtet angesehen, bis wir sie in Echtzeit getestet haben, wie unten gezeigt. Wir erstellen eine Tabelle, fügen ein paar Einträge 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 Einträgen in die PostgreSQL-Datenbank zu replizieren.
mysql> create table t1 (n1 int primary key, n2 varchar(10));
Abfrage OK, 0 Zeilen betroffen (0.01 Sek)
mysql> insert into t1 values (1,'one');
Abfrage OK, 1 Zeile betroffen (0.00 Sek)
mysql> insert into t1 values (2,'two');
Abfrage OK, 1 Zeile betroffen (0.00 Sek)$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Der Synchronisierungsprozess für die Quelle mysql wurde gestartet.Um die Testergebnisse zu bestätigen, 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 | twoWenn wir eine Migration durchführen, werden die folgenden Befehle in pg_chameleon deren Abschluss darstellen. Diese Befehle sollten ausgeführt werden, nachdem wir sichergestellt haben, dass die Zeilen aller Zieltabellen repliziert wurden, und das Ergebnis wird eine sauber übertragene PostgreSQL-Datenbank sein, die keine Verweise auf die ursprüngliche Datenbank oder das Replikationsschema (sch_chameleon) beinhaltet.
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugOptional können mit den folgenden Befehlen die ursprüngliche Konfiguration und das Replikationsschema entfernt werden.
$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debugDie Vorteile von pg_chameleon
Einfache Einrichtung und Konfiguration.
Benutzerfreundliche Fehlerbehebung und Auffinden von Anomalien mit verständlichen Fehlermeldungen.
Nach der Initialisierung können zusätzliche spezielle Tabellen zur Replikation hinzugefügt werden, ohne die restliche Konfiguration zu ändern.
Es können mehrere Quell-Datenbanken für eine Ziel-Datenbank konfiguriert werden, was sehr praktisch ist, wenn Sie Daten aus einer oder mehreren MySQL-Datenbanken in einer PostgreSQL-Datenbank zusammenführen.
Ausgewählte Tabellen müssen nicht repliziert werden.
Nachteile von pg_chameleon
Es wird nur MySQL 5.5 und höher als Quelle und PostgreSQL 9.5 und höher als Ziel-Datenbank unterstützt.
Jede Tabelle muss einen Primär- oder eindeutigen Schlüssel haben, sonst werden die Tabellen während des Init_replica-Prozesses initialisiert, aber nicht repliziert.
Die Replikation erfolgt einseitig — nur von MySQL nach PostgreSQL. Daher eignet sie sich nur für das Schema "aktiv-passiv".
Die Quelle kann nur eine MySQL-Datenbank sein, während die Unterstützung für PostgreSQL-Datenbanken als Quelle noch experimentell und mit Einschränkungen ist (erfahren Sie mehr )
Zusammenfassung zu pg_chameleon
Das Replikationsverfahren in pg_chameleon eignet sich hervorragend für die Migration von Datenbanken von MySQL nach PostgreSQL. Ein wesentlicher Nachteil ist, dass die Replikation nur einseitig ist, weshalb Datenbankspezialisten wahrscheinlich nicht wollen, es für etwas anderes als Migration zu verwenden. Das Problem der einseitigen Replikation kann jedoch mit einem weiteren Open-Source-Tool — SymmetricDS — gelöst werden.
Weitere Informationen finden Sie in der offiziellen Dokumentation . Informationen zur Befehlszeile finden Sie .
Überblick über SymmetricDS
SymmetricDS ist ein Open-Source-Tool, das beliebige Datenbanken in andere gängige Datenbanken repliziert: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird und andere Cloud-Datenbankinstanzen wie Redshift und Azure. Verfügbare Funktionen: Datenbank- und Dateisynchronisierung, Replikation mehrerer führender Datenbanken, gefilterte Synchronisierung, Transformation und mehr. Es ist ein Tool in Java und erfordert die Standardversion des JRE oder JDK (Version 8.0 oder höher). Hier können Datenänderungen über Trigger in der Quell-Datenbank aufgezeichnet und in Form von Paketen an die entsprechende Ziel-Datenbank weitergeleitet werden.
Funktionen von SymmetricDS
Das Tool ist plattformunabhängig, was bedeutet, dass zwei oder mehr unterschiedliche Datenbanken Daten austauschen können.
Relationale Datenbanken synchronisieren sich durch das Aufzeichnen von Datenänderungen, während dateibasierten Datenbanken die Dateisynchronisierung verwenden.
Zweiseitige Replikation unter Verwendung von Push- und Pull-Methoden basierend auf einer Regelmenge.
Die Datenübertragung ist über gesicherte Netzwerke und Netzwerke mit niedriger Bandbreite möglich.
Automatische Wiederherstellung bei der Wiederaufnahme des Betriebs von Knoten nach einem Ausfall und automatisches Lösen von Konflikten.
Kompatibilität mit der Cloud und effektive API-Erweiterungen.
Beispiel
SymmetricDS kann in einer von zwei Varianten konfiguriert werden:
Ein führender (übergeordneter) Knoten, der zentral die Replikation von Daten zwischen zwei untergeordneten (untergeordneten) Knoten koordiniert, wobei der Datenaustausch zwischen den untergeordneten Knoten nur über den übergeordneten Knoten erfolgt.
Ein aktiver Knoten (Knoten 1) kann Daten zur Replikation mit einem anderen aktiven Knoten (Knoten 2) ohne Vermittler austauschen.
In beiden Varianten erfolgt der Datenaustausch über Push und Pull. In diesem Beispiel betrachten wir die Konfiguration "aktiv-aktiv". Es wäre zu lang, die gesamte Architektur zu beschreiben, daher schauen Sie sich , um mehr über die Funktionsweise von SymmetricDS zu erfahren.
Die Installation von SymmetricDS ist sehr einfach: Laden Sie die Open-Source-Version der Zip-Datei herunter und entpacken Sie sie an einen Ort Ihrer Wahl. In der folgenden Tabelle sind Informationen über den Installationsort und die Version von SymmetricDS in diesem Beispiel sowie die Datenbankversionen, Linuxversionen, IP-Adressen und Ports für beide Knoten aufgeführt.
Host
vm1
vm2
Betriebssystemversion
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64
Datenbankserverversion
MySQL 5.7.26
PostgreSQL 10.5
Datenbankport
3306
5832
IP-Adresse
192.168.1.107
192.168.1.112
Version von SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9
Installationspfad von SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20
Name des SymmetricDS-Knotens
corp-000
store-001
Hier installieren wir SymmetricDS in /usr/local/symmetric-server-3.9.20, und hier werden verschiedene untergeordnete Verzeichnisse und Dateien gespeichert. Wir interessieren uns für die untergeordneten Verzeichnisse samples und engines. Im Verzeichnis samples befinden sich Beispielkonfigurationsdateien mit Knotenattributen sowie Beispiel-SQL-Skripte für einen schnellen Einstieg in die Demonstration.
Im Verzeichnis samples sehen wir drei Konfigurationsdateien mit Knotenattributen — der Name zeigt die Art des Knotens in einem bestimmten Schema.
corp-000.properties
store-001.properties
store-002.propertiesIn SymmetricDS sind alle erforderlichen Konfigurationsdateien für ein Basis-Schema aus 3 Knoten (Variante 1) vorhanden, und dieselben Dateien können für ein Schema aus 2 Knoten (Variante 2) verwendet werden. Wir kopieren die benötigte Konfigurationsdatei aus dem Verzeichnis samples in engines auf dem Host vm1. Es ergibt sich Folgendes:
$> 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=000Dieser Knoten in der Konfiguration von SymmetricDS wird corp-000 genannt, und die Verbindung zur Datenbank wird vom mysql jdbc Treiber verarbeitet, der die oben angegebene Verbindungszeichenfolge und Anmeldedaten verwendet. Wir verbinden uns mit der Datenbank replica_db, und während der Erstellung des Schemas werden Tabellen erstellt. sync.url zeigt den Verbindungsort des Knotens für die Synchronisation an.
Knoten 2 auf dem Host vm2 wird als store-001 konfiguriert, die restlichen Informationen sind in der unten angeführten Datei node.properties enthalten. Der Knoten store-001 verwendet die PostgreSQL-Datenbank, während pgdb_replica die Datenbank für die Replikation ist. registration.url ermöglicht es dem Host vm2, mit dem Host vm1 zu kommunizieren und die Konfigurationsdetails zu erhalten.
$> 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=001Das Beispiel von SymmetricDS enthält Parameter zur Konfiguration der bidirektionalen Replikation zwischen zwei Datenbankservern (zwei Knoten). Die folgenden Schritte werden auf dem Host vm1 (corp-000) durchgeführt, der ein Beispiel-Schema mit 4 Tabellen erstellt. Anschließend erstellt der Befehl create-sym-tables von symadmin die Katalogtabellen, in denen die Regeln und die Richtung der Replikation zwischen den Knoten gespeichert werden. Schließlich werden Beispiel-Daten 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.sqlIm Beispiel sind die Tabellen item und item_selling_price automatisch für die Replikation von corp-000 nach store-001 konfiguriert, während die Tabellen sale (sale_transaction und sale_return_line_item) automatisch für die Replikation von store-001 nach corp-000 konfiguriert sind. Jetzt erstellen wir ein Schema in der PostgreSQL-Datenbank auf dem Host vm2 (store-001), um es auf 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.xmlEs ist wichtig sicherzustellen, dass die Datenbank MySQL auf vm1 Beispieltabellen und die Katalogtabellen von SymmetricDS enthält. Beachten Sie, dass die systemeigenen Tabellen von SymmetricDS (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. Außerdem wird die Datenbank auf dem Knoten store-001 nur 4 Beispieltabellen ohne Daten enthalten.
Das ist alles. Die Umgebung ist bereit zur Ausführung der Serverprozesse von sym auf beiden Knoten, wie unten gezeigt.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &Die Logeinträge werden in die Datei des Hintergrund-Logs (symmetric.log) im Log-Verzeichnis des Ordners, in dem SymmetricDS installiert ist, sowie in die Standardausgabe geschrieben. Der sym-Server kann jetzt auf dem Knoten store-001 gestartet werden.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &Wenn der serverseitige Prozess sym auf dem Host vm2 gestartet wird, werden die SymmetricDS-Katalogtabellen auch in der PostgreSQL-Datenbank erstellt. Wenn der serverseitige Prozess sym auf beiden Knoten gestartet wird, werden sie koordiniert, um die 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 war. Alternativ kann der Initial-Load zum Knoten store-001 von corp-000 mit dem folgenden Befehl gesendet werden.
vm1$> ./symadmin --engine corp-000 reload-node 001An diesem Punkt wird ein neuer Datensatz in die Tabelle item in der MySQL-Datenbank auf dem Knoten corp-000 (Host: vm1) eingefügt, und wir können die Replikation in die PostgreSQL-Datenbank auf dem Knoten store-001 (Host: vm2) überprüfen. Wir sehen die Pull-Operation, um Daten von corp-000 nach store-001 zu verschieben.
mysql> insert into item values ('22000002','Jelly Bean');
Abfrage OK, 1 Zeile betroffen (0.00 Sek.)vm2$> psql -p 5832 -U postgres pgdb_replica -c "select * from item"
item_id | name
----------+-----------
11000001 | Yummy Gum
22000002 | Jelly Bean
(2 Zeilen)Um eine Push-Operation durchzuführen, um Daten von store-001 nach corp-000 zu verschieben, fügen wir einen Eintrag in die Tabelle sale_transaction ein und überprüfen, ob die Replikation erfolgreich war.
Wir sehen die erfolgreiche Einrichtung der bidirektionalen Replikation von Beispieltabellen zwischen MySQL- und PostgreSQL-Datenbanken. Um die Replikation für neue benutzerdefinierte Tabellen einzurichten, führen wir die folgenden Schritte aus. Wir erstellen eine Tabelle t1 als Beispiel und konfigurieren die Replikationsregeln wie folgt. Damit richten wir nur die Replikation von corp-000 nach store-001 ein.
mysql> create table t1 (no integer);
Abfrage OK, 0 Zeilen betroffen (0.01 Sek.)mysql> insert into sym_channel (channel_id,create_time,last_update_time)
values ('t1',current_timestamp,current_timestamp);
Abfrage OK, 1 Zeile betroffen (0.01 Sek.)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);
Abfrage OK, 1 Zeile betroffen (0.01 Sek.)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);
Abfrage OK, 1 Zeile betroffen (0.01 Sek.)Die Konfiguration erhält dann eine Benachrichtigung über die Änderung des Schemas, das heißt, die Hinzufügung einer neuen Tabelle, über den Befehl symadmin mit dem Argument sync-triggers, das die Trigger zum Abgleichen der Tabellendefinitionen neu erstellt. Der Befehl send-schema wird ausgeführt, um die Schemaänderungen an den Knoten store-001 zu senden, und die Replikation der Tabelle t1 wird eingerichtet.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Vorteile von SymmetricDS
Einfache Installation und Konfiguration, einschließlich eines fertigen Satzes von Dateien mit Parametern zum Erstellen eines Schemas mit drei oder zwei Knoten.
Plattformübergreifende Datenbanken und Unabhängigkeit von der Plattform, einschließlich Server, Laptops und mobilen Geräten.
Replikation jeder Datenbank in jede andere Datenbank lokal, über WAN oder in der Cloud.
Die Möglichkeit, optimal mit einem Paar von Datenbanken oder mehreren Tausend für eine bequeme Replikation zu arbeiten.
Die kostenpflichtige Version mit grafischer Benutzeroberfläche und hervorragendem Support.
Nachteile von SymmetricDS
Es ist notwendig, die Regeln und die Richtung der Replikation manuell in der Eingabeaufforderung über SQL-Operatoren für das Laden der Katalogtabellen zu definieren, was unangenehm sein kann.
Die Einrichtung vieler Tabellen für die Replikation kann mühsam sein, wenn man keine Skripte zur Erstellung der SQL-Operatoren verwendet, die die Regeln und die Richtung der Replikation definieren.
In die Protokolle wird zu viele Informationen geschrieben, und manchmal muss Ordnung in die Protokolldatei gebracht werden, damit sie nicht zu viel Platz einnimmt.
Zusammenfassung zu SymmetricDS
SymmetricDS ermöglicht die Konfiguration der bidirektionalen Replikation zwischen zwei, drei und sogar mehreren Tausend Knoten, um Replikationen durchzuführen und Dateien zu synchronisieren. Es handelt sich um ein einzigartiges Tool, das viele Aufgaben selbstständig erledigt, wie beispielsweise die automatische Wiederherstellung von Daten nach längeren Ausfallzeiten am Knoten, den sicheren und effizienten Datenaustausch zwischen Knoten über HTTPS, die automatische Konfliktverwaltung basierend auf einem Regelwerk usw. SymmetricDS führt Replikationen zwischen beliebigen Datenbanken durch, sodass es für eine Vielzahl von Szenarien genutzt werden kann, einschließlich Migration, Upgrade, Verteilung, Filterung und Transformation von Daten auf unterschiedlichen Plattformen.
Das Beispiel wurde auf der Grundlage des offiziellen zu SymmetricDS. In Es werden verschiedene Konzepte im Zusammenhang mit der Einrichtung der Replikation mit SymmetricDS detailliert beschrieben.
Quelle: habr.com
