{"id":38146,"date":"2019-10-31T22:21:54","date_gmt":"2019-10-31T19:21:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql\/"},"modified":"2019-10-31T22:21:54","modified_gmt":"2019-10-31T19:21:54","slug":"perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql","title":{"rendered":"Cross-Replication zwischen PostgreSQL und MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Cross-Replication<\/p>\n

<\/p>\n

Ich werde im Gro\u00dfen und Ganzen \u00fcber die Kreuzreplikation zwischen PostgreSQL und MySQL sprechen und auch \u00fcber 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.<\/p>\n

<\/p>\n

PostgreSQL und MySQL werden zwar als relationale Datenbanken betrachtet, bieten aber mit zus\u00e4tzlichen Erweiterungen auch NoSQL-Funktionen. Hier werden wir die Replikation zwischen PostgreSQL und MySQL aus der Perspektive relationaler Datenbanksysteme besprechen.<\/p>\n

<\/p>\n

Wir werden nicht die gesamte interne Funktionsweise beschreiben, sondern uns auf die grundlegenden Prinzipien konzentrieren, damit Sie einen \u00dcberblick \u00fcber die Einrichtung der Replikation zwischen den Datenbankservern, deren Vorteile, Einschr\u00e4nkungen und Anwendungsf\u00e4lle erhalten.<\/p>\n

<\/a><\/noindex><\/p>\n

In der Regel erfolgt die Replikation zwischen zwei identischen Datenbankservern entweder im bin\u00e4ren Modus oder \u00fcber Anfragen zwischen dem Master-Knoten (auch Publisher, prim\u00e4r 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 \u00fcbertragen, also vom aktiven zum passiven Knoten, da die Replikation nur in eine Richtung erfolgt. Es ist jedoch m\u00f6glich, die Replikation zwischen zwei Datenbanken in beide Richtungen einzurichten, sodass die Daten im \u201eActive-Active\u201c-Konzept vom Slave zum Master \u00fcbertragen werden. All dies, einschlie\u00dflich der kaskadierenden Replikation, ist zwischen zwei oder mehr identischen Datenbankservern m\u00f6glich. Die Konfiguration \u201eActive-Active\u201c oder \u201eActive-Passive\u201c h\u00e4ngt von den Anforderungen, der Verf\u00fcgbarkeit solcher M\u00f6glichkeiten in der urspr\u00fcnglichen Konfiguration oder der Nutzung externer L\u00f6sungen zur Einrichtung und vorhandenen Kompromissen ab.<\/p>\n

<\/p>\n

Die beschriebene Konfiguration ist zwischen verschiedenen Datenbankservern m\u00f6glich. Der Server kann so konfiguriert werden, dass er replizierte Daten von einem anderen Datenbankserver empf\u00e4ngt und gleichzeitig Echtzeit-Schnappsch\u00fcsse der replizierten Daten speichert. MySQL und PostgreSQL bieten die meisten dieser Konfigurationen entweder nativ oder durch Drittanbietererweiterungen an, einschlie\u00dflich Methoden wie bin\u00e4re Protokolle, Festplattensperren und operatorenbasierte sowie zeilenbasierte Ans\u00e4tze.<\/p>\n

<\/p>\n

Der Quervergleich zwischen MySQL und PostgreSQL ist f\u00fcr die einmalige Migration von einem Datenbankserver zu einem anderen erforderlich. Diese Datenbanken verwenden unterschiedliche Protokolle, sodass sie nicht direkt verbunden werden k\u00f6nnen. Um den Datenaustausch zu erm\u00f6glichen, kann ein externes Open-Source-Tool wie pg_chameleon verwendet werden.<\/p>\n

<\/p>\n

Was ist pg_chameleon<\/h3>\n

<\/p>\n

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\u00fcsselt und in der PostgreSQL-Datenbank wiederhergestellt werden.<\/p>\n

<\/p>\n

Funktionen von pg_chameleon<\/h3>\n

<\/p>\n

Mehrere MySQL-Schemas aus einem Cluster k\u00f6nnen in eine Ziel-Datenbank PostgreSQL mit einer \u201eeins zu vielen\u201c-Konfiguration repliziert werden.
\nDie Namen des Quell- und Zielschemas d\u00fcrfen nicht identisch sein.
\nReplikationsdaten k\u00f6nnen aus einem kaskadierenden MySQL-Replikat extrahiert werden.
\nTabellen, die nicht repliziert werden k\u00f6nnen oder Fehler verursachen, werden ausgeschlossen.
\nJede Replikationsfunktion wird von Daemons verwaltet.
\nDie Kontrolle erfolgt \u00fcber Parameter und Konfigurationsdateien basierend auf YAML.<\/p>\n

<\/p>\n

Beispiel<\/h3>\n

<\/p>\n

Host
\nvm1
\nvm2<\/p>\n

Betriebssystemversion<\/strong>
\nCentOS Linux 7.6 x86_64
\nCentOS Linux 7.5 x86_64<\/p>\n

Datenbankserverversion<\/strong>
\nMySQL 5.7.26
\nPostgreSQL 10.5<\/p>\n

Datenbankport<\/strong>
\n3306
\n5433<\/p>\n

IP-Adresse<\/strong>
\n192.168.56.102
\n192.168.56.106<\/p>\n

<\/p>\n

Bereiten Sie zun\u00e4chst 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.<\/p>\n

<\/p>\n

$> wget https:\/\/www.python.org\/ftp\/python\/3.6.8\/Python-3.6.8.tar.xz\n$> tar -xJf Python-3.6.8.tar.xz\n$> cd Python-3.6.8\n$> .\/configure --enable-optimizations\n$> make altinstall<\/code><\/pre>\n
<\/p>\n
Nach der erfolgreichen Installation von Python 3.6 m\u00fcssen die weiteren Anforderungen erf\u00fcllt werden, wie zum Beispiel das Erstellen und Aktivieren einer virtuellen Umgebung. Au\u00dferdem wird das pip-Modul auf die neueste Version aktualisiert und f\u00fcr 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.<\/p>\n
<\/p>\n
$> python3.6 -m venv venv\n$> source venv\/bin\/activate\n(venv) $> pip install pip --upgrade\n(venv) $> pip install pg_chameleon==2.0.9<\/code><\/pre>\n
<\/p>\n
Dann 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.<\/p>\n
<\/p>\n
(venv) $> chameleon set_configuration_files\nVerzeichnis \/root\/.pg_chameleon wird erstellt\nVerzeichnis \/root\/.pg_chameleon\/configuration\/ wird erstellt\nVerzeichnis \/root\/.pg_chameleon\/logs\/ wird erstellt\nVerzeichnis \/root\/.pg_chameleon\/pid\/ wird erstellt\nKopiere Konfigurationsexemplar in \/root\/.pg_chameleon\/configuration\/config-example.yml<\/code><\/pre>\n
<\/p>\n
Jetzt erstellen wir eine Kopie von config-example.yml als default.yml, damit es die Standardkonfigurationsdatei wird. Ein Beispiel f\u00fcr die Konfigurationsdatei f\u00fcr dieses Beispiel ist unten aufgef\u00fchrt.<\/p>\n
<\/p>\n
$> cat default.yml\n---\n#Globale Einstellungen\npid_dir: '~\/.pg_chameleon\/pid\/'\nlog_dir: '~\/.pg_chameleon\/logs\/'\nlog_dest: Datei\nlog_level: info\nlog_days_keep: 10\nrollbar_key: ''\nrollbar_env: ''\n\n# type_override erm\u00f6glicht dem Benutzer, die standardm\u00e4\u00dfige Typumwandlung zu \u00fcberschreiben.\ntype_override:\n  \"tinyint(1)\":\n    override_to: boolean\n    override_tables:\n      - \"*\"\n\n#postgres-Zielverbindung\npg_conn:\n  host: \"192.168.56.106\"\n  port: \"5433\"\n  user: \"usr_replica\"\n  password: \"pass123\"\n  database: \"db_replica\"\n  charset: \"utf8\"\n\nsources:\n  mysql:\n    db_conn:\n      host: \"192.168.56.102\"\n      port: \"3306\"\n      user: \"usr_replica\"\n      password: \"pass123\"\n      charset: 'utf8'\n      connect_timeout: 10\n    schema_mappings:\n      world_x: pgworld_x\n    limit_tables:\n#      - delphis_mediterranea.foo\n    skip_tables:\n#      - delphis_mediterranea.bar\n    grant_select_to:\n      - usr_readonly\n    lock_timeout: \"120s\"\n    my_server_id: 100\n    replica_batch_size: 10000\n    replay_max_rows: 10000\n    batch_retention: '1 Tag'\n    copy_max_memory: \"300M\"\n    copy_mode: 'Datei'\n    out_dir: \/tmp\n    sleep_loop: 1\n    on_error_replay: fortfahren\n    on_error_read: fortfahren\n    auto_maintenance: \"deaktiviert\"\n    gtid_enable: Nein\n    type: mysql\n    skip_events:\n      insert:\n        - delphis_mediterranea.foo #\u00dcberspringt Einf\u00fcgungen in die Tabelle delphis_mediterranea.foo\n      delete:\n        - delphis_mediterranea #\u00dcberspringt L\u00f6schvorg\u00e4nge im Schema delphis_mediterranea\n      update:<\/code><\/pre>\n
<\/p>\n
Die Konfigurationsdatei in diesem Beispiel ist ein Muster f\u00fcr eine Datei mit pg_chameleon mit geringf\u00fcgigen Anpassungen entsprechend der Quell- und Zielumgebung. Im Folgenden wird eine \u00dcbersicht \u00fcber die verschiedenen Abschnitte der Konfigurationsdatei bereitgestellt.<\/p>\n
<\/p>\n
In der Konfigurationsdatei default.yml gibt es einen Abschnitt f\u00fcr globale Parameter, in dem Sie Einstellungen wie den Speicherort der Sperrdatei, den Speicherort der Protokolle, die Aufbewahrungsdauer der Protokolle usw. verwalten k\u00f6nnen. Danach folgt der Abschnitt f\u00fcr Typ\u00fcbersteuerungen, in dem eine Reihe von Regeln f\u00fcr die Typ\u00fcbersteuerung w\u00e4hrend der Replikation festgelegt ist. Im Standardbeispiel wird eine Regel zur \u00dcbersteuerung verwendet, die tinyint(1) in einen Wahrheitswert umwandelt. Im n\u00e4chsten 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 \u00fcbersprungen werden sollen, Zeit\u00fcberschreitungen, Speicher und Paketgr\u00f6\u00dfe. Beachten Sie, dass \u201esources\u201c im Plural angegeben ist, was bedeutet, dass wir mehrere Quell-Datenbanken f\u00fcr eine Ziel-Datenbank hinzuf\u00fcgen k\u00f6nnen, um die Konfiguration \u201eviele zu eins\u201c anzupassen.<\/p>\n
<\/p>\n
Die Datenbank world_x in diesem Beispiel enth\u00e4lt 4 Tabellen mit Zeilen, die die MySQL-Community als Beispiel anbietet. Sie kann heruntergeladen werden. hier<\/a><\/noindex>Das Beispiel der Datenbank wird als tar- und komprimiertes Archiv mit Anweisungen zum Erstellen und Importieren von Zeilen bereitgestellt.<\/p>\n
<\/p>\n
In MySQL- und PostgreSQL-Datenbanken wird ein spezieller Benutzer mit dem gleichen Namen usr_replica erstellt. In MySQL erh\u00e4lt er zus\u00e4tzliche Rechte, um auf alle replizierten Tabellen zuzugreifen.<\/p>\n
<\/p>\n
mysql> CREATE USER usr_replica ;\nmysql> SET PASSWORD FOR usr_replica='pass123';\nmysql> GRANT ALL ON world_x.* TO 'usr_replica';\nmysql> GRANT RELOAD ON *.* to 'usr_replica';\nmysql> GRANT REPLICATION CLIENT ON *.* to 'usr_replica';\nmysql> GRANT REPLICATION SLAVE ON *.* to 'usr_replica';\nmysql> FLUSH PRIVILEGES;<\/code><\/pre>\n
<\/p>\n
Auf der PostgreSQL-Seite wird eine Datenbank db_replica erstellt, die \u00c4nderungen aus der MySQL-Datenbank empfangen wird. Der Benutzer usr_replica in PostgreSQL wird automatisch als Eigent\u00fcmer der beiden Schemata pgworld_x und sch_chameleon eingerichtet, die die tats\u00e4chlichen replizierten Tabellen bzw. die Tabellen mit Replikationskatalogen enthalten. F\u00fcr die automatische Konfiguration ist das Argument create_replica_schema verantwortlich, wie Sie weiter unten sehen werden.<\/p>\n
<\/p>\n
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';\nCREATE ROLE\npostgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;\nCREATE DATABASE<\/code><\/pre>\n
<\/p>\n
Die MySQL-Datenbank wird mit \u00c4nderungen an bestimmten Parametern konfiguriert, um sie f\u00fcr die Replikation vorzubereiten, wie unten gezeigt. Es ist erforderlich, den Datenbankserver neu zu starten, damit die \u00c4nderungen wirksam werden.<\/p>\n
<\/p>\n
$> vi \/etc\/my.cnf\nbinlog_format= ROW\nbinlog_row_image=FULL\nlog-bin = mysql-bin\nserver-id = 1<\/code><\/pre>\n
<\/p>\n
Jetzt ist es wichtig, die Verbindung zu beiden Datenbankservern zu \u00fcberpr\u00fcfen, um sicherzustellen, dass bei der Ausf\u00fchrung der pg_chameleon-Befehle keine Probleme auftreten.<\/p>\n
<\/p>\n
Auf dem PostgreSQL-Knoten:<\/p>\n
<\/p>\n
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x<\/code><\/pre>\n
<\/p>\n
Auf dem MySQL-Knoten:<\/p>\n
<\/p>\n
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica<\/code><\/pre>\n
<\/p>\n
Die folgenden drei Befehle von pg_chameleon (chameleon) bereiten die Umgebung vor, f\u00fcgen 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\u00e4hnt. Das Argument add_source f\u00fcgt die Quell-Datenbank zur Konfiguration hinzu, indem die Konfigurationsdatei (default.yml) gelesen wird, und in unserem Fall ist dies mysql, w\u00e4hrend init_replica die Konfiguration basierend auf den Parametern in der Konfigurationsdatei initialisiert.<\/p>\n
<\/p>\n
$> chameleon create_replica_schema --debug\n$> chameleon add_source --config default --source mysql --debug\n$> chameleon init_replica --config default --source mysql --debug<\/code><\/pre>\n
<\/p>\n
Die Ausgaben dieser drei Befehle zeigen eindeutig ihren erfolgreichen Ablauf an. Alle Fehler oder Syntaxprobleme werden in klaren und verst\u00e4ndlichen Nachrichten angezeigt, die Hinweise zur Behebung der Probleme enthalten.<\/p>\n
<\/p>\n
Lassen Sie uns schlie\u00dflich die Replikation mit dem Befehl start_replica starten und eine Best\u00e4tigung \u00fcber die erfolgreiche Ausf\u00fchrung erhalten.<\/p>\n
<\/p>\n
$> chameleon start_replica --config default --source mysql \nAusgabe: Starten des Replikationsprozesses f\u00fcr die Quelle mysql<\/code><\/pre>\n
<\/p>\n
Den Replikationsstatus k\u00f6nnen Sie mit dem Argument show_status abfragen, und um Fehler anzuzeigen, verwenden Sie das Argument show_errors.<\/p>\n
<\/p>\n
Ergebnis.<\/a><\/noindex><\/p>\n
<\/p>\n
Wie bereits erw\u00e4hnt, werden alle Replikationsfunktionen von Daemons gesteuert. Um diese zu sehen, lassen Sie uns die Prozessliste mit dem Linux-Befehl ps abfragen, wie unten gezeigt.<\/p>\n
<\/p>\n
Ergebnis.<\/a><\/noindex><\/p>\n
<\/p>\n
Die Replikation gilt nicht als eingerichtet, bis wir sie in Echtzeit getestet haben, wie unten gezeigt. Wir erstellen eine Tabelle, f\u00fcgen ein paar Datens\u00e4tze 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\u00e4tzen in die PostgreSQL-Datenbank zu replizieren.<\/p>\n
<\/p>\n
mysql> create table t1 (n1 int primary key, n2 varchar(10));\nAbfrage OK, 0 Zeilen betroffen (0,01 Sek.)\nmysql> insert into t1 values (1,'one');\nAbfrage OK, 1 Zeile betroffen (0,00 Sek.)\nmysql> insert into t1 values (2,'two');\nAbfrage OK, 1 Zeile betroffen (0,00 Sek.)<\/code><\/pre>\n
<\/p>\n
$> chameleon sync_tables --tables world_x.t1 --config default --source mysql\nDer Synchronisationsprozess der Tabellen f\u00fcr die Quelle mysql hat begonnen.<\/code><\/pre>\n
<\/p>\n
Um die Testergebnisse zu best\u00e4tigen, fordern wir eine Tabelle aus der PostgreSQL-Datenbank an und geben die Zeilen aus.<\/p>\n
<\/p>\n
$> psql -p 5433 -U usr_replica -d db_replica -c \"select * from pgworld_x.t1\";\n n1 |  n2\n----+-------\n  1 | eins\n  2 | zwei<\/code><\/pre>\n
<\/p>\n
Wenn wir eine Migration durchf\u00fchren, werden die folgenden pg_chameleon-Befehle diesen Prozess abschlie\u00dfen. Diese Befehle sollten ausgef\u00fchrt werden, nachdem wir sichergestellt haben, dass alle Zeilen der Zieltabellen repliziert wurden, und das Ergebnis wird eine sauber \u00fcbertragene PostgreSQL-Datenbank ohne Verweise auf die urspr\u00fcngliche Datenbank oder das Replikationsschema (sch_chameleon) sein.<\/p>\n
<\/p>\n
$> chameleon stop_replica --config default --source mysql \n$> chameleon detach_replica --config default --source mysql --debug<\/code><\/pre>\n
<\/p>\n
Optional k\u00f6nnen mit den folgenden Befehlen die urspr\u00fcngliche Konfiguration und das Replikationsschema entfernt werden.<\/p>\n
<\/p>\n
$> chameleon drop_source --config default --source mysql --debug\n$> chameleon drop_replica_schema --config default --source mysql --debug<\/code><\/pre>\n
<\/p>\n
Vorteile von pg_chameleon<\/h3>\n
<\/p>\n
Einfache Einrichtung und Konfiguration.
\nKomfortable Fehlerbehebung und Identifikation von Anomalien mit verst\u00e4ndlichen Fehlermeldungen.
\nZus\u00e4tzliche spezielle Tabellen k\u00f6nnen nach der Initialisierung zur Replikation hinzugef\u00fcgt werden, ohne die restliche Konfiguration zu ver\u00e4ndern.
\nEs k\u00f6nnen mehrere Quell-Datenbanken f\u00fcr eine Ziel-Datenbank konfiguriert werden, was besonders praktisch ist, wenn Sie Daten aus einer oder mehreren MySQL-Datenbanken in einer PostgreSQL-Datenbank zusammenf\u00fchren.
\nEs ist m\u00f6glich, bestimmte Tabellen von der Replikation auszunehmen.<\/p>\n
<\/p>\n
Nachteile von pg_chameleon<\/h3>\n
<\/p>\n
Unterst\u00fctzt nur MySQL 5.5 und h\u00f6her als Quelle sowie PostgreSQL 9.5 und h\u00f6her als Ziel-Datenbank.
\nJede Tabelle muss einen Prim\u00e4r- oder eindeutigen Schl\u00fcssel haben, sonst werden die Tabellen im Init-Replicas-Prozess initialisiert, aber nicht repliziert.
\nEs handelt sich um eine unidirektionale Replikation \u2013 nur von MySQL nach PostgreSQL. Daher ist es nur f\u00fcr ein \u201eAktiv-Passiv\u201c-Schema geeignet.
\nDie Quelle kann nur eine MySQL-Datenbank sein, w\u00e4hrend die Unterst\u00fctzung f\u00fcr PostgreSQL als Quelle nur experimentell und mit Einschr\u00e4nkungen ist (mehr erfahren) hier<\/a><\/noindex>)<\/p>\n
<\/p>\n
Zusammenfassung zu pg_chameleon<\/h3>\n
<\/p>\n
Das Replikationsverfahren in pg_chameleon eignet sich hervorragend f\u00fcr die Migration von Datenbanken von MySQL nach PostgreSQL. Ein wesentlicher Nachteil ist, dass die Replikation nur unidirektional ist, weshalb Datenbankspezialisten es wahrscheinlich nicht f\u00fcr etwas anderes als migrationszwecke einsetzen m\u00f6chten. Das Problem der unidirektionalen Replikation kann jedoch mit einem weiteren Open-Source-Tool, SymmetricDS, gel\u00f6st werden.<\/p>\n
<\/p>\n
Weitere Informationen finden Sie in der offiziellen Dokumentation hier<\/a><\/noindex>. Informationen zur Befehlszeile finden Sie hier<\/a><\/noindex>.<\/p>\n
<\/p>\n
\u00dcberblick \u00fcber SymmetricDS<\/h3>\n
<\/p>\n
SymmetricDS ist ein Open-Source-Tool, das jede Datenbank in jede andere g\u00e4ngige 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\u00fcgbare 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\u00f6her) ben\u00f6tigt. Hier k\u00f6nnen Daten\u00e4nderungen \u00fcber Trigger in der Quell-Datenbank aufgezeichnet und in Form von Paketen an die entsprechende Ziel-Datenbank gesendet werden.<\/p>\n
<\/p>\n
Funktionen von SymmetricDS<\/h3>\n
<\/p>\n
Das Tool ist plattformunabh\u00e4ngig, das hei\u00dft, zwei oder mehr unterschiedliche Datenbanken k\u00f6nnen Daten austauschen.
\nRelationale Datenbanken synchronisieren sich durch das Protokollieren von Daten\u00e4nderungen, w\u00e4hrend dateibasierte Datenbanken eine Dateisynchronisation nutzen.
\nBidirektionale Replikation mithilfe von Push- und Pull-Methoden basierend auf einer Regelbasis.
\nDie Daten\u00fcbertragung ist \u00fcber sichere Netzwerke und Netzwerke mit niedriger Bandbreite m\u00f6glich.
\nAutomatische Wiederherstellung nach der Wiederaufnahme des Betriebs von Knoten nach einem Ausfall und automatische Konfliktl\u00f6sung.
\nKompatibilit\u00e4t mit der Cloud und effiziente API-Erweiterungen.<\/p>\n
<\/p>\n
Beispiel<\/h3>\n
<\/p>\n
SymmetricDS kann in einer von zwei Varianten konfiguriert werden:
\nEin f\u00fchrender (Eltern-) Knoten, der die Datenreplikation zwischen zwei nachgelagerten (Kind-) Knoten zentral koordiniert, wobei der Datenaustausch zwischen den Kindknoten nur \u00fcber den Elternknoten erfolgt.
\nEin aktiver Knoten (Knoten 1) kann Daten zur Replikation mit einem anderen aktiven Knoten (Knoten 2) ohne Vermittler austauschen.<\/p>\n
<\/p>\n
In beiden Varianten erfolgt der Datenaustausch \u00fcber Push und Pull. In diesem Beispiel betrachten wir die Konfiguration 'aktiv-aktiv'. Es w\u00fcrde zu lange dauern, die gesamte Architektur zu beschreiben, also schauen Sie sich an die Richtlinien<\/a><\/noindex>, um mehr \u00fcber die Funktionsweise von SymmetricDS zu erfahren.<\/p>\n
<\/p>\n
Die Installation von SymmetricDS ist sehr einfach: Laden Sie die Open-Source-Version der Zip-Datei herunter. hier herunter<\/a><\/noindex> und extrahieren Sie es, wo immer Sie m\u00f6chten. 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\u00fcr beide Knoten.<\/p>\n
<\/p>\n
Host
\nvm1
\nvm2<\/p>\n
Betriebssystemversion<\/strong>
\nCentOS Linux 7.6 x86_64
\nCentOS Linux 7.6 x86_64<\/p>\n
Datenbankserverversion<\/strong>
\nMySQL 5.7.26
\nPostgreSQL 10.5<\/p>\n
Datenbankport<\/strong>
\n3306
\n5832<\/p>\n
IP-Adresse<\/strong>
\n192.168.1.107
\n192.168.1.112<\/p>\n
SymmetricDS-Version<\/strong>
\nSymmetricDS 3.9
\nSymmetricDS 3.9<\/p>\n
Installationspfad von SymmetricDS<\/strong>
\n\/usr\/local\/symmetric-server-3.9.20
\n\/usr\/local\/symmetric-server-3.9.20<\/p>\n
Knotenname von SymmetricDS<\/strong>
\ncorp-000
\nstore-001<\/p>\n
<\/p>\n
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\u00fcr einen schnellen Start der Demonstration.<\/p>\n
<\/p>\n
Im Verzeichnis samples sehen wir drei Konfigurationsdateien mit den Knotenattributen - der Name zeigt den Typ des Knotens in einem bestimmten Schema an.<\/p>\n
<\/p>\n
corp-000.properties\nstore-001.properties\nstore-002.properties<\/code><\/pre>\n
<\/p>\n
SymmetricDS enth\u00e4lt alle erforderlichen Konfigurationsdateien f\u00fcr ein einfaches Schema mit 3 Knoten (Variante 1), und dieselben Dateien k\u00f6nnen auch f\u00fcr ein Schema mit 2 Knoten (Variante 2) verwendet werden. Wir kopieren die ben\u00f6tigte Konfigurationsdatei aus dem Verzeichnis samples in engines auf dem Host vm1. Es ergibt sich:<\/p>\n
<\/p>\n
$> cat engines\/corp-000.properties\nengine.name=corp-000\ndb.driver=com.mysql.jdbc.Driver\ndb.url=jdbc:mysql:\/\/192.168.1.107:3306\/replica_db?autoReconnect=true&useSSL=false\ndb.user=root\ndb.password=admin123\nregistration.url=\nsync.url=http:\/\/192.168.1.107:31415\/sync\/corp-000\ngroup.id=corp\nexternal.id=000<\/code><\/pre>\n
<\/p>\n
Dieser Knoten in der Konfiguration von SymmetricDS wird als corp-000 bezeichnet, und die Verbindung zur Datenbank erfolgt \u00fcber 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\u00fcr die Synchronisation an.<\/p>\n
<\/p>\n
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\u00e4hrend pgdb_replica die Datenbank f\u00fcr die Replikation ist. registration.url erm\u00f6glicht es dem Host vm2, sich mit dem Host vm1 zu verbinden und die Konfigurationsdetails abzurufen.<\/p>\n
<\/p>\n
$> cat engines\/store-001.properties\nengine.name=store-001\ndb.driver=org.postgresql.Driver\ndb.url=jdbc:postgresql:\/\/192.168.1.112:5832\/pgdb_replica\ndb.user=postgres\ndb.password=admin123\nregistration.url=http:\/\/192.168.1.107:31415\/sync\/corp-000\ngroup.id=store\nexternal.id=001<\/code><\/pre>\n
<\/p>\n
Das Beispiel f\u00fcr SymmetricDS enth\u00e4lt Parameter zur Konfiguration der bidirektionalen Replikation zwischen zwei Datenbankservern (zwei Knoten). Die folgenden Schritte werden auf dem Host vm1 (corp-000) ausgef\u00fchrt, der ein Beispielschema mit 4 Tabellen erstellt. Anschlie\u00dfend erstellt der Befehl create-sym-tables von symadmin die Katalogtabellen, in denen die Regeln und Richtungen der Replikation zwischen den Knoten gespeichert werden. Schlie\u00dflich werden Beispieldaten in die Tabellen geladen.<\/p>\n
<\/p>\n
vm1$> cd \/usr\/local\/symmetric-server-3.9.20\/bin\nvm1$> .\/dbimport --engine corp-000 --format XML create_sample.xml\nvm1$> .\/symadmin --engine corp-000 create-sym-tables\nvm1$> .\/dbimport --engine corp-000 insert_sample.sql<\/code><\/pre>\n
<\/p>\n
Im Beispiel sind die Tabellen item und item_selling_price automatisch so konfiguriert, dass sie von corp-000 nach store-001 repliziert werden, w\u00e4hrend die Tabellen sale (sale_transaction und sale_return_line_item) automatisch f\u00fcr 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.<\/p>\n
<\/p>\n
vm2$> cd \/usr\/local\/symmetric-server-3.9.20\/bin\nvm2$> .\/dbimport --engine store-001 --format XML create_sample.xml<\/code><\/pre>\n
<\/p>\n
Stellen 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\u00fcgbar sind, da wir dort den Befehl create-sym-tables ausgef\u00fchrt haben und die Replikation verwalten werden. Dar\u00fcber hinaus wird es in der Datenbank auf dem Knoten store-001 nur 4 Beispieltabellen ohne Daten geben.<\/p>\n
<\/p>\n
Alles klar. Die Umgebung ist bereit, um die Serverprozesse von sym auf beiden Knoten zu starten, wie unten gezeigt.<\/p>\n
<\/p>\n
vm1$> cd \/usr\/local\/symmetric-server-3.9.20\/bin\nvm1$> sym 2>&1 &<\/code><\/pre>\n
<\/p>\n
Die Protokolleintr\u00e4ge 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.<\/p>\n
<\/p>\n
vm2$> cd \/usr\/local\/symmetric-server-3.9.20\/bin\nvm2$> sym 2>&1 &<\/code><\/pre>\n
<\/p>\n
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.<\/p>\n
<\/p>\n
vm1$> .\/symadmin --engine corp-000 reload-node 001<\/code><\/pre>\n
<\/p>\n
An dieser Stelle wird in die Tabelle item in der MySQL-Datenbank auf dem Knoten corp-000 (Host: vm1) ein neuer Datensatz eingef\u00fcgt, und wir k\u00f6nnen seine Replikation in der PostgreSQL-Datenbank auf dem Knoten store-001 (Host: vm2) \u00fcberpr\u00fcfen. Wir sehen die Pull-Operation, um Daten von corp-000 nach store-001 zu verschieben.<\/p>\n
<\/p>\n
mysql> insert into item values ('22000002','Jelly Bean');\nAbfrage OK, 1 Zeile betroffen (0.00 sec)<\/code><\/pre>\n
<\/p>\n
vm2$> psql -p 5832 -U postgres pgdb_replica -c \"select * from item\"\n item_id  |   name\n----------+-----------\n 11000001 | Yummy Gum\n 22000002 | Jelly Bean\n(2 Zeilen)<\/code><\/pre>\n
<\/p>\n
Um eine Push-Operation durchzuf\u00fchren, um Daten von store-001 nach corp-000 zu verschieben, f\u00fcgen wir einen Datensatz in die Tabelle sale_transaction ein und \u00fcberpr\u00fcfen, ob die Replikation erfolgreich war.<\/p>\n
<\/p>\n
Ergebnis.<\/a><\/noindex><\/p>\n
<\/p>\n
Wir sehen eine erfolgreiche Konfiguration der bidirektionalen Replikation der Beispieltabellen zwischen MySQL- und PostgreSQL-Datenbanken. Um die Replikation f\u00fcr neue Benutzertabellen einzurichten, f\u00fchren wir die folgenden Schritte aus. Zuerst erstellen wir die Tabelle t1 als Beispiel und konfigurieren die Regeln f\u00fcr ihre Replikation wie folgt. Damit richten wir nur die Replikation von corp-000 nach store-001 ein.<\/p>\n
<\/p>\n
mysql> create table  t1 (no integer);\nQuery OK, 0 rows affected (0.01 sec)<\/code><\/pre>\n
<\/p>\n
mysql> insert into sym_channel (channel_id,create_time,last_update_time) \nvalues ('t1',current_timestamp,current_timestamp);\nQuery OK, 1 row affected (0.01 sec)<\/code><\/pre>\n
<\/p>\n
mysql> insert into sym_trigger (trigger_id, source_table_name,channel_id,\nlast_update_time, create_time) values ('t1', 't1', 't1', current_timestamp,\ncurrent_timestamp);\nQuery OK, 1 row affected (0.01 sec)<\/code><\/pre>\n
<\/p>\n
mysql> insert into sym_trigger_router (trigger_id, router_id,\nInitial_load_order, create_time,last_update_time) values ('t1',\n'corp-2-store-1', 1, current_timestamp,current_timestamp);\nQuery OK, 1 row affected (0.01 sec)<\/code><\/pre>\n
<\/p>\n
Anschlie\u00dfend erh\u00e4lt die Konfiguration eine Benachrichtigung \u00fcber die \u00c4nderung des Schemas, also die Hinzuf\u00fcgung 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\u00fchrt, um die Schema\u00e4nderungen an den Knoten store-001 zu senden, und die Replikation der Tabelle t1 ist eingerichtet.<\/p>\n
<\/p>\n
vm1$> .\/symadmin -e corp-000 --node=001 sync-triggers    \nvm1$> .\/symadmin send-schema -e corp-000 --node=001 t1<\/code><\/pre>\n
<\/p>\n
Vorteile von SymmetricDS<\/h3>\n
<\/p>\n
Einfache Installation und Konfiguration, einschlie\u00dflich eines vollst\u00e4ndigen Satzes von Dateien mit Parametern zur Erstellung eines Schemas mit drei oder zwei Knoten.
\nPlattform\u00fcbergreifende Datenbanken und Plattformunabh\u00e4ngigkeit, einschlie\u00dflich Servern, Laptops und mobilen Ger\u00e4ten.
\nReplikation jeder Datenbank in jede andere Datenbank lokal, \u00fcber WAN oder in der Cloud.
\nOptimale Funktionalit\u00e4t mit einer Handvoll Datenbanken oder mehreren Tausend f\u00fcr eine bequeme Replikation.
\nKostenpflichtige Version mit grafischer Benutzeroberfl\u00e4che und hervorragendem Support.<\/p>\n
<\/p>\n
Nachteile von SymmetricDS<\/h3>\n
<\/p>\n
Regeln und Richtung der Replikation m\u00fcssen manuell \u00fcber die Befehlszeile mit SQL-Anweisungen festgelegt werden, um Katalogtabellen zu laden, was unpraktisch sein kann.
\nDas Einrichten vieler Tabellen f\u00fcr die Replikation kann m\u00fchsam sein, es sei denn, es werden Skripte verwendet, um SQL-Anweisungen zu erstellen, die die Regeln und Richtung der Replikation definieren.
\nEs werden zu viele Informationen in die Protokolle geschrieben, und manchmal muss man die Protokolldatei aufr\u00e4umen, damit sie nicht zu viel Platz einnimmt.<\/p>\n
<\/p>\n
Zusammenfassung zu SymmetricDS<\/h3>\n
<\/p>\n
SymmetricDS erm\u00f6glicht die Konfiguration einer bidirektionalen Replikation zwischen zwei, drei oder sogar mehreren tausend Knoten, um Replikation durchzuf\u00fchren und Dateien zu synchronisieren. Dieses einzigartige Tool f\u00fchrt viele Aufgaben eigenst\u00e4ndig aus, wie beispielsweise die automatische Wiederherstellung von Daten nach l\u00e4ngeren Ausfallzeiten an einem Knoten, den sicheren und effektiven Austausch von Daten zwischen Knoten \u00fcber HTTPS, die automatische Konfliktverwaltung basierend auf einer Regelmenge usw. SymmetricDS erm\u00f6glicht die Replikation zwischen beliebigen Datenbanken, weshalb es f\u00fcr die unterschiedlichsten Szenarien eingesetzt werden kann, einschlie\u00dflich Migration, Upgrade auf eine neue Version, Verteilung, Filterung und Transformation von Daten auf verschiedenen Plattformen.<\/p>\n
<\/p>\n
Beispiel erstellt basierend auf dem offiziellen Kurzleitfaden<\/a><\/noindex> f\u00fcr SymmetricDS. Darin Benutzerhandbuch<\/a><\/noindex> werden verschiedene Konzepte zur Konfiguration der Replikation mit SymmetricDS detailliert beschrieben.<\/p>\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u042f \u0432 \u043e\u0431\u0449\u0438\u0445 \u0447\u0435\u0440\u0442\u0430\u0445 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043e \u043f\u0435\u0440\u0435\u043a\u0440\u0435\u0441\u0442\u043d\u043e\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043c\u0435\u0436\u0434\u0443 PostgreSQL \u0438 MySQL, \u0430 \u0435\u0449\u0435 \u043e \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u043f\u0435\u0440\u0435\u043a\u0440\u0435\u0441\u0442\u043d\u043e\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043c\u0435\u0436\u0434\u0443 \u044d\u0442\u0438\u043c\u0438 \u0434\u0432\u0443\u043c\u044f \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c\u0438 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445. \u041e\u0431\u044b\u0447\u043d\u043e \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 \u043f\u0435\u0440\u0435\u043a\u0440\u0435\u0441\u0442\u043d\u043e\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043d\u0430\u0437\u044b\u0432\u0430\u044e\u0442\u0441\u044f \u043e\u0434\u043d\u043e\u0440\u043e\u0434\u043d\u044b\u043c\u0438, \u0438 \u044d\u0442\u043e \u0443\u0434\u043e\u0431\u043d\u044b\u0439 \u043c\u0435\u0442\u043e\u0434 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0430 \u0441 \u043e\u0434\u043d\u043e\u0433\u043e \u0441\u0435\u0440\u0432\u0435\u0440\u0430 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0421\u0423\u0411\u0414 \u043d\u0430 \u0434\u0440\u0443\u0433\u043e\u0439. \u0411\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 PostgreSQL \u0438 MySQL \u043f\u0440\u0438\u043d\u044f\u0442\u043e \u0441\u0447\u0438\u0442\u0430\u0442\u044c \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u044b\u043c\u0438, \u043d\u043e \u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28635,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38146","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Quell-zu-Ziel-Replikation zwischen PostgreSQL und MySQL | ProHoster","description":"Ich werde im Allgemeinen \u00fcber die Quell-zu-Ziel-Replikation zwischen PostgreSQL und MySQL sprechen und die Methoden zur Konfiguration dieser Replikation zwischen den beiden Datenbankservern erl\u00e4utern. Datenbanken in einer Quell-zu-Ziel-Replikation werden normalerweise als homogen bezeichnet, und es ist eine bequeme Methode, um von einem relationalen Datenbankserver zu einem anderen zu wechseln. PostgreSQL und MySQL gelten als relationale Datenbanken, aber mit","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0435\u0440\u0435\u043a\u0440\u0435\u0441\u0442\u043d\u0430\u044f \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044f \u043c\u0435\u0436\u0434\u0443 PostgreSQL \u0438 MySQL | ProHoster","og:description":"\u042f \u0432 \u043e\u0431\u0449\u0438\u0445 \u0447\u0435\u0440\u0442\u0430\u0445 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043e \u043f\u0435\u0440\u0435\u043a\u0440\u0435\u0441\u0442\u043d\u043e\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043c\u0435\u0436\u0434\u0443 PostgreSQL \u0438 MySQL, \u0430 \u0435\u0449\u0435 \u043e \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u043f\u0435\u0440\u0435\u043a\u0440\u0435\u0441\u0442\u043d\u043e\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043c\u0435\u0436\u0434\u0443 \u044d\u0442\u0438\u043c\u0438 \u0434\u0432\u0443\u043c\u044f \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c\u0438 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445. \u041e\u0431\u044b\u0447\u043d\u043e \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 \u043f\u0435\u0440\u0435\u043a\u0440\u0435\u0441\u0442\u043d\u043e\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043d\u0430\u0437\u044b\u0432\u0430\u044e\u0442\u0441\u044f \u043e\u0434\u043d\u043e\u0440\u043e\u0434\u043d\u044b\u043c\u0438, \u0438 \u044d\u0442\u043e \u0443\u0434\u043e\u0431\u043d\u044b\u0439 \u043c\u0435\u0442\u043e\u0434 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0430 \u0441 \u043e\u0434\u043d\u043e\u0433\u043e \u0441\u0435\u0440\u0432\u0435\u0440\u0430 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0421\u0423\u0411\u0414 \u043d\u0430 \u0434\u0440\u0443\u0433\u043e\u0439. \u0411\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 PostgreSQL \u0438 MySQL \u043f\u0440\u0438\u043d\u044f\u0442\u043e \u0441\u0447\u0438\u0442\u0430\u0442\u044c \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u044b\u043c\u0438, \u043d\u043e \u0441","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:21:54+00:00","article:modified_time":"2019-10-31T19:21:54+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38146","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 20:38:22","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:59:41","updated":"2026-01-23 20:38:22"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38146","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=38146"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38146\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/28635"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=38146"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=38146"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=38146"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}