Ich werde im Großen und Ganzen über die Kreuzreplikation zwischen PostgreSQL und MySQL sprechen und auch über die Methoden zur Einrichtung dieser Replikation zwischen den beiden Datenbankservern. In der Regel werden Datenbanken in der Kreuzreplikation als homogener bezeichnet, und dies ist eine praktische Methode, um von einem relationalen DB-Server auf einen anderen zu wechseln.
PostgreSQL und MySQL werden zwar als relationale Datenbanken betrachtet, bieten aber mit zusätzlichen Erweiterungen auch NoSQL-Funktionen. Hier werden wir die Replikation zwischen PostgreSQL und MySQL aus der Perspektive relationaler Datenbanksysteme besprechen.
Wir werden nicht die gesamte interne Funktionsweise beschreiben, sondern uns auf die grundlegenden Prinzipien konzentrieren, damit Sie einen Überblick über die Einrichtung der Replikation zwischen den Datenbankservern, deren Vorteile, Einschränkungen und Anwendungsfälle erhalten.
In der Regel erfolgt die Replikation zwischen zwei identischen Datenbankservern entweder im binären Modus oder über Anfragen zwischen dem Master-Knoten (auch Publisher, primär oder aktiv) und dem Slave-Knoten (Subscriber, Standby oder passiv). Das Ziel der Replikation ist es, in Echtzeit eine Kopie der Hauptdatenbank auf der Seite des Slaves bereitzustellen. Dabei werden die Daten vom Master zum Slave übertragen, also vom aktiven zum passiven Knoten, da die Replikation nur in eine Richtung erfolgt. Es ist jedoch möglich, die Replikation zwischen zwei Datenbanken in beide Richtungen einzurichten, sodass die Daten im „Active-Active“-Konzept vom Slave zum Master übertragen werden. All dies, einschließlich der kaskadierenden Replikation, ist zwischen zwei oder mehr identischen Datenbankservern möglich. Die Konfiguration „Active-Active“ oder „Active-Passive“ hängt von den Anforderungen, der Verfügbarkeit solcher Möglichkeiten in der ursprünglichen Konfiguration oder der Nutzung externer Lösungen zur Einrichtung 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 gleichzeitig Echtzeit-Schnappschüsse der replizierten Daten speichert. MySQL und PostgreSQL bieten die meisten dieser Konfigurationen entweder nativ oder durch Drittanbietererweiterungen an, einschließlich Methoden wie binäre Protokolle, Festplattensperren und operatorenbasierte sowie zeilenbasierte Ansätze.
Der Quervergleich zwischen MySQL und PostgreSQL ist für die einmalige Migration von einem Datenbankserver zu einem anderen erforderlich. Diese Datenbanken verwenden unterschiedliche Protokolle, sodass sie nicht direkt verbunden werden können. 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 nach PostgreSQL, das in Python 3 geschrieben ist. Es verwendet eine Open-Source-Bibliothek namens mysql-replication, ebenfalls in Python. Die Zeilenbilder werden aus MySQL-Tabellen extrahiert und als JSONB-Objekte in der PostgreSQL-Datenbank gespeichert, bevor sie durch die pl/pgsql-Funktion entschlüsselt und in der PostgreSQL-Datenbank wiederhergestellt werden.
Funktionen von pg_chameleon
Mehrere MySQL-Schemas aus einem Cluster können in eine Ziel-Datenbank PostgreSQL mit einer „eins zu vielen“-Konfiguration repliziert werden.
Die Namen des Quell- und Zielschemas dürfen nicht identisch sein.
Replikationsdaten können aus einem kaskadierenden MySQL-Replikat extrahiert werden.
Tabellen, die nicht repliziert werden können oder Fehler verursachen, werden ausgeschlossen.
Jede Replikationsfunktion wird von Daemons verwaltet.
Die Kontrolle erfolgt über Parameter und Konfigurationsdateien basierend auf YAML.
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 notwendigen Komponenten zur Installation von pg_chameleon vor. In diesem Beispiel ist Python 3.6.8 installiert, das eine virtuelle Umgebung erstellt und diese 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, wie zum Beispiel das Erstellen und Aktivieren einer virtuellen Umgebung. Außerdem wird das pip-Modul auf die neueste Version aktualisiert und für die 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 geschieht, 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
Verzeichnis /root/.pg_chameleon wird erstellt
Verzeichnis /root/.pg_chameleon/configuration/ wird erstellt
Verzeichnis /root/.pg_chameleon/logs/ wird erstellt
Verzeichnis /root/.pg_chameleon/pid/ wird erstellt
Kopiere Konfigurationsexemplar in /root/.pg_chameleon/configuration/config-example.ymlJetzt erstellen wir eine Kopie von config-example.yml als default.yml, damit es die 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 dem Benutzer, die standardmäßige Typumwandlung zu überschreiben.
type_override:
"tinyint(1)":
override_to: boolean
override_tables:
- "*"
#postgres-Zielverbindung
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: fortfahren
on_error_read: fortfahren
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öschvorgänge im Schema delphis_mediterranea
update:Die Konfigurationsdatei in diesem Beispiel ist ein Muster für eine Datei mit pg_chameleon mit geringfügigen Anpassungen entsprechend der Quell- und Zielumgebung. Im Folgenden wird eine Übersicht über die verschiedenen Abschnitte der Konfigurationsdatei bereitgestellt.
In der Konfigurationsdatei default.yml gibt es einen Abschnitt für globale Parameter, in dem Sie Einstellungen wie den Speicherort der Sperrdatei, den Speicherort der Protokolle, die Aufbewahrungsdauer der Protokolle usw. verwalten können. Danach folgt der Abschnitt für Typübersteuerungen, in dem eine Reihe von Regeln für die Typübersteuerung während der Replikation festgelegt ist. Im Standardbeispiel wird eine Regel zur Übersteuerung verwendet, die tinyint(1) in einen Wahrheitswert 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 Quelldaten an, d. h. die Verbindungsparameter der Quell-Datenbank, das Mapping der Quell- und Ziel-Datenbank-Schemata, Tabellen, die übersprungen werden sollen, Zeitüberschreitungen, Speicher und Paketgröße. Beachten Sie, dass „sources“ im Plural angegeben ist, was bedeutet, dass wir mehrere Quell-Datenbanken für eine Ziel-Datenbank hinzufügen können, um die Konfiguration „viele zu eins“ anzupassen.
Die Datenbank world_x in diesem Beispiel enthält 4 Tabellen mit Zeilen, die die MySQL-Community als Beispiel anbietet. Sie kann heruntergeladen werden. Das Beispiel der Datenbank wird als tar- und komprimiertes Archiv mit Anweisungen zum Erstellen und Importieren von Zeilen bereitgestellt.
In MySQL- und PostgreSQL-Datenbanken wird ein spezieller Benutzer mit dem gleichen Namen usr_replica erstellt. In MySQL erhält er zusätzliche Rechte, um auf alle replizierten Tabellen zuzugreifen.
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 db_replica erstellt, die Änderungen aus der MySQL-Datenbank empfangen wird. Der Benutzer usr_replica in PostgreSQL wird 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 mit Änderungen an bestimmten Parametern konfiguriert, um sie für die Replikation vorzubereiten, wie unten gezeigt. Es ist erforderlich, den Datenbankserver neu zu starten, damit die Änderungen wirksam werden.
$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1Jetzt ist es wichtig, die Verbindung zu beiden Datenbankservern zu überprüfen, um sicherzustellen, dass 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 zur Konfiguration hinzu, indem die Konfigurationsdatei (default.yml) gelesen wird, 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 zeigen eindeutig ihren erfolgreichen Ablauf an. Alle Fehler oder Syntaxprobleme werden in klaren und verständlichen Nachrichten angezeigt, die Hinweise zur Behebung der Probleme enthalten.
Lassen Sie uns schließlich die Replikation mit dem Befehl start_replica starten und eine Bestätigung über die erfolgreiche Ausführung erhalten.
$> chameleon start_replica --config default --source mysql
Ausgabe: Starten des Replikationsprozesses für die Quelle mysqlDen Replikationsstatus können Sie mit dem Argument show_status abfragen, und um Fehler anzuzeigen, verwenden Sie das Argument show_errors.
Wie bereits erwähnt, werden alle Replikationsfunktionen von Daemons gesteuert. Um diese zu sehen, lassen Sie uns die Prozessliste mit dem Linux-Befehl ps abfragen, wie unten gezeigt.
Die Replikation gilt nicht als eingerichtet, bis wir sie in Echtzeit getestet haben, wie unten gezeigt. Wir erstellen eine Tabelle, fügen ein paar Datensätze in die MySQL-Datenbank ein und verwenden das Argument sync_tables in pg_chameleon, 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));
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 Synchronisationsprozess der Tabellen für die Quelle mysql hat begonnen.Um die Testergebnisse zu bestätigen, fordern wir eine Tabelle aus der PostgreSQL-Datenbank an und geben die Zeilen aus.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | eins
2 | zweiWenn wir eine Migration durchführen, werden die folgenden pg_chameleon-Befehle diesen Prozess abschließen. Diese Befehle sollten ausgeführt werden, nachdem wir sichergestellt haben, dass alle Zeilen der Zieltabellen repliziert wurden, und das Ergebnis wird eine sauber übertragene PostgreSQL-Datenbank ohne Verweise auf die ursprüngliche Datenbank oder das Replikationsschema (sch_chameleon) sein.
$> 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 --debugVorteile von pg_chameleon
Einfache Einrichtung und Konfiguration.
Komfortable Fehlerbehebung und Identifikation von Anomalien mit verständlichen Fehlermeldungen.
Zusätzliche spezielle Tabellen können nach der Initialisierung zur Replikation hinzugefügt werden, ohne die restliche Konfiguration zu verändern.
Es können mehrere Quell-Datenbanken für eine Ziel-Datenbank konfiguriert werden, was besonders praktisch ist, wenn Sie Daten aus einer oder mehreren MySQL-Datenbanken in einer PostgreSQL-Datenbank zusammenführen.
Es ist möglich, bestimmte Tabellen von der Replikation auszunehmen.
Nachteile von pg_chameleon
Unterstützt nur MySQL 5.5 und höher als Quelle sowie PostgreSQL 9.5 und höher als Ziel-Datenbank.
Jede Tabelle muss einen Primär- oder eindeutigen Schlüssel haben, sonst werden die Tabellen im Init-Replicas-Prozess initialisiert, aber nicht repliziert.
Es handelt sich um eine unidirektionale Replikation – nur von MySQL nach PostgreSQL. Daher ist es nur für ein „Aktiv-Passiv“-Schema geeignet.
Die Quelle kann nur eine MySQL-Datenbank sein, während die Unterstützung für PostgreSQL als Quelle nur experimentell und mit Einschränkungen ist (mehr erfahren) )
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 unidirektional ist, weshalb Datenbankspezialisten es wahrscheinlich nicht für etwas anderes als migrationszwecke einsetzen möchten. Das Problem der unidirektionalen 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 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 wie Redshift und Azure usw. Verfügbare Funktionen: Datenbank- und Dateisynchronisation, Replikation mehrerer Master-Datenbanken, gefilterte Synchronisation, Transformationen und mehr. Es handelt sich um ein Java-Tool, das eine Standardversion von JRE oder JDK (Version 8.0 oder höher) benötigt. Hier können Datenänderungen über Trigger in der Quell-Datenbank aufgezeichnet und in Form von Paketen an die entsprechende Ziel-Datenbank gesendet werden.
Funktionen von SymmetricDS
Das Tool ist plattformunabhängig, das heißt, zwei oder mehr unterschiedliche Datenbanken können Daten austauschen.
Relationale Datenbanken synchronisieren sich durch das Protokollieren von Datenänderungen, während dateibasierte Datenbanken eine Dateisynchronisation nutzen.
Bidirektionale Replikation mithilfe von Push- und Pull-Methoden basierend auf einer Regelbasis.
Die Datenübertragung ist über sichere Netzwerke und Netzwerke mit niedriger Bandbreite möglich.
Automatische Wiederherstellung nach der Wiederaufnahme des Betriebs von Knoten nach einem Ausfall und automatische Konfliktlösung.
Kompatibilität mit der Cloud und effiziente API-Erweiterungen.
Beispiel
SymmetricDS kann in einer von zwei Varianten konfiguriert werden:
Ein führender (Eltern-) Knoten, der die Datenreplikation zwischen zwei nachgelagerten (Kind-) Knoten zentral koordiniert, wobei der Datenaustausch zwischen den Kindknoten nur über den Elternknoten 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ürde zu lange dauern, die gesamte Architektur zu beschreiben, also schauen Sie sich an , 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 extrahieren Sie es, wo immer Sie möchten. In der folgenden Tabelle finden Sie Informationen zum Installationsort und zur Version von SymmetricDS in diesem Beispiel sowie zu den Datenbankversionen, Linux-Versionen, IP-Adressen und Ports für beide Knoten.
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
SymmetricDS-Version
SymmetricDS 3.9
SymmetricDS 3.9
Installationspfad von SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20
Knotenname von SymmetricDS
corp-000
store-001
Hier installieren wir SymmetricDS in /usr/local/symmetric-server-3.9.20, und hier werden verschiedene Unterverzeichnisse und Dateien gespeichert. Uns interessieren die Unterverzeichnisse samples und engines. Im Verzeichnis samples befinden sich Beispielkonfigurationsdateien mit den Knotenattributen sowie SQL-Skripte für einen schnellen Start der Demonstration.
Im Verzeichnis samples sehen wir drei Konfigurationsdateien mit den Knotenattributen - der Name zeigt den Typ des Knotens in einem bestimmten Schema an.
corp-000.properties
store-001.properties
store-002.propertiesSymmetricDS enthält alle erforderlichen Konfigurationsdateien für ein einfaches Schema mit 3 Knoten (Variante 1), und dieselben Dateien können auch für ein Schema mit 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:
$> 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 als corp-000 bezeichnet, und die Verbindung zur Datenbank erfolgt über den MySQL JDBC-Treiber, der die oben angegebene Verbindungszeichenfolge und die Anmeldedaten verwendet. Wir stellen eine Verbindung zur Datenbank replica_db her, und beim Erstellen des Schemas werden die Tabellen angelegt. sync.url zeigt den Verbindungsort des Knotens für die Synchronisation an.
Knoten 2 auf dem Host vm2 wird als store-001 konfiguriert, die weiteren Details sind in der Datei node.properties angegeben, die unten folgt. Knoten store-001 betreibt eine PostgreSQL-Datenbank, während pgdb_replica die Datenbank für die Replikation ist. registration.url ermöglicht es dem Host vm2, sich mit dem Host vm1 zu verbinden und die 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=001Das Beispiel für SymmetricDS enthält Parameter zur Konfiguration der bidirektionalen Replikation zwischen zwei Datenbankservern (zwei Knoten). Die folgenden Schritte werden auf dem Host vm1 (corp-000) ausgeführt, der ein Beispielschema mit 4 Tabellen erstellt. Anschließend erstellt der Befehl create-sym-tables von symadmin die Katalogtabellen, in denen die Regeln und Richtungen der Replikation zwischen den 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.sqlIm Beispiel sind die Tabellen item und item_selling_price automatisch so konfiguriert, dass sie von corp-000 nach store-001 repliziert werden, 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 das 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.xmlStellen Sie sicher, dass in der MySQL-Datenbank auf vm1 Beispieltabellen und Katalogtabellen von SymmetricDS vorhanden sind. Beachten Sie, dass die systemeigenen Tabellen von SymmetricDS (mit dem Prefix 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. Darüber hinaus wird es in der Datenbank auf dem Knoten store-001 nur 4 Beispieltabellen ohne Daten geben.
Alles klar. Die Umgebung ist bereit, um die Serverprozesse von sym 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 in die Hintergrundprotokolldatei (symmetric.log) im Log-Verzeichnis des Installationsverzeichnisses von SymmetricDS sowie in die Standardausgabe gesendet. 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 Serverprozess sym auf dem Host vm2 gestartet wird, erstellt er ebenfalls die SymmetricDS-Verzeichnistabellen in der PostgreSQL-Datenbank. Wenn der Serverprozess sym auf beiden Knoten gestartet wird, koordinieren sie sich, um Daten von corp-000 nach store-001 zu replizieren. Wenn wir nach einigen Sekunden alle 4 Tabellen auf beiden Seiten abfragen, werden wir sehen, dass die Replikation erfolgreich war. Alternativ kann die Anfangsladung an den Knoten store-001 von corp-000 mit dem folgenden Befehl gesendet werden.
vm1$> ./symadmin --engine corp-000 reload-node 001An dieser Stelle wird in die Tabelle item in der MySQL-Datenbank auf dem Knoten corp-000 (Host: vm1) ein neuer Datensatz eingefügt, und wir können seine Replikation in der 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 sec)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 Datensatz in die Tabelle sale_transaction ein und überprüfen, ob die Replikation erfolgreich war.
Wir sehen eine erfolgreiche Konfiguration der bidirektionalen Replikation der Beispieltabellen zwischen MySQL- und PostgreSQL-Datenbanken. Um die Replikation für neue Benutzertabellen einzurichten, führen wir die folgenden Schritte aus. Zuerst erstellen wir die Tabelle t1 als Beispiel und konfigurieren die Regeln für ihre Replikation wie folgt. Damit richten wir nur die Replikation von corp-000 nach store-001 ein.
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 erhält die Konfiguration eine Benachrichtigung über die Änderung des Schemas, also die Hinzufügung einer neuen Tabelle, mithilfe des Befehls 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 ist 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 vollständigen Satzes von Dateien mit Parametern zur Erstellung eines Schemas mit drei oder zwei Knoten.
Plattformübergreifende Datenbanken und Plattformunabhängigkeit, einschließlich Servern, Laptops und mobilen Geräten.
Replikation jeder Datenbank in jede andere Datenbank lokal, über WAN oder in der Cloud.
Optimale Funktionalität mit einer Handvoll Datenbanken oder mehreren Tausend für eine bequeme Replikation.
Kostenpflichtige Version mit grafischer Benutzeroberfläche und hervorragendem Support.
Nachteile von SymmetricDS
Regeln und Richtung der Replikation müssen manuell über die Befehlszeile mit SQL-Anweisungen festgelegt werden, um Katalogtabellen zu laden, was unpraktisch sein kann.
Das Einrichten vieler Tabellen für die Replikation kann mühsam sein, es sei denn, es werden Skripte verwendet, um SQL-Anweisungen zu erstellen, die die Regeln und Richtung der Replikation definieren.
Es werden zu viele Informationen in die Protokolle geschrieben, und manchmal muss man die Protokolldatei aufräumen, damit sie nicht zu viel Platz einnimmt.
Zusammenfassung zu SymmetricDS
SymmetricDS ermöglicht die Konfiguration einer bidirektionalen Replikation zwischen zwei, drei oder sogar mehreren tausend Knoten, um Replikation durchzuführen und Dateien zu synchronisieren. Dieses einzigartige Tool führt viele Aufgaben eigenständig aus, wie beispielsweise die automatische Wiederherstellung von Daten nach längeren Ausfallzeiten an einem Knoten, den sicheren und effektiven Austausch von Daten zwischen Knoten über HTTPS, die automatische Konfliktverwaltung basierend auf einer Regelmenge usw. SymmetricDS ermöglicht die Replikation zwischen beliebigen Datenbanken, weshalb es für die unterschiedlichsten Szenarien eingesetzt werden kann, einschließlich Migration, Upgrade auf eine neue Version, Verteilung, Filterung und Transformation von Daten auf verschiedenen Plattformen.
Beispiel erstellt basierend auf dem offiziellen für SymmetricDS. Darin werden verschiedene Konzepte zur Konfiguration der Replikation mit SymmetricDS detailliert beschrieben.
Quelle: habr.com
