{"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 \u00fcber 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.<\/p>\n

<\/p>\n

Die Datenbanken PostgreSQL und MySQL gelten als relationale Systeme, bieten jedoch mit zus\u00e4tzlichen Erweiterungen NoSQL-M\u00f6glichkeiten. Hier werden wir die Replikation zwischen PostgreSQL und MySQL aus der Perspektive relationaler Datenbanken diskutieren.<\/p>\n

<\/p>\n

Wir werden nicht die gesamte interne Funktionsweise beschreiben, sondern nur die grundlegenden Prinzipien, damit Sie ein Verst\u00e4ndnis f\u00fcr die Einstellung der Replikation zwischen den Datenbankservern und die Vorteile, Einschr\u00e4nkungen und Anwendungszenarien erhalten.<\/p>\n

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

Normalerweise wird die Replikation zwischen zwei identischen Datenbankservern entweder im bin\u00e4ren Modus oder \u00fcber Anfragen zwischen dem f\u00fchrenden Knoten (Publisher, Master oder aktiv) und dem abh\u00e4ngigen (Subscriber, Wartende oder passiv) durchgef\u00fchrt. Ziel der Replikation ist es, in Echtzeit eine Kopie der Hauptdatenbank auf der Seite des Abh\u00e4ngigen bereitzustellen. Die Daten werden vom f\u00fchrenden auf den abh\u00e4ngigen Server \u00fcbertragen, was bedeutet, dass die Replikation nur in eine Richtung erfolgt. Es ist jedoch m\u00f6glich, die Replikation zwischen zwei Datenbanken in beide Richtungen zu konfigurieren, sodass die Daten vom abh\u00e4ngigen zum f\u00fchrenden Server in einer \u201eaktiv-aktiv\u201c Konfiguration \u00fcbertragen werden. All dies, einschlie\u00dflich der kaskadierenden Replikation, ist zwischen zwei oder mehr identischen Datenbankservern m\u00f6glich. Die Konfiguration \u201eaktiv-aktiv\u201c oder \u201eaktiv-passiv\u201c h\u00e4ngt von den Anforderungen, der Verf\u00fcgbarkeit solcher M\u00f6glichkeiten in der Ausgangskonfiguration oder der Nutzung externer L\u00f6sungen zur Einrichtung und bestehenden Kompromissen ab.<\/p>\n

<\/p>\n

Die beschriebene Konfiguration ist zwischen verschiedenen Datenbankservern m\u00f6glich. Ein Server kann so konfiguriert werden, dass er replizierte Daten von einem anderen Datenbankserver empf\u00e4ngt und dabei Schnappsch\u00fcsse der replizierten Daten in Echtzeit speichert. MySQL und PostgreSQL bieten die meisten dieser Konfigurationen entweder nativ oder \u00fcber Drittanbietererweiterungen an, einschlie\u00dflich Methoden des bin\u00e4ren Journals, Festplattensperren und operator- und zeilenbasierter Methoden.<\/p>\n

<\/p>\n

Die Kreuzreplikation zwischen MySQL und PostgreSQL ist f\u00fcr eine einmalige Migration von einem Datenbankserver auf einen anderen erforderlich. Diese Datenbanken verwenden unterschiedliche Protokolle, daher ist eine direkte Verbindung nicht m\u00f6glich. 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 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.<\/p>\n

<\/p>\n

Funktionen von pg_chameleon<\/h3>\n

<\/p>\n

Mehrere MySQL-Schemas aus einem Cluster k\u00f6nnen in eine Ziel-PostgreSQL-Datenbank mit einer \"Eins-zu-Viele\"-Konfiguration repliziert werden.
\nDie Namen des Quell- und Zielschemas d\u00fcrfen nicht identisch sein.
\nReplikationsdaten k\u00f6nnen aus einer kaskadierten MySQL-Replikation extrahiert werden.
\nTabellen, die nicht repliziert werden k\u00f6nnen oder Fehler verursachen, werden ausgeschlossen.
\nJede Replikationsfunktion wird von D\u00e4monen verwaltet.
\n\u00dcberwachung mit Parametern und Konfigurationsdateien im YAML-Format.<\/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 erforderlichen Komponenten f\u00fcr die Installation von pg_chameleon vor. In diesem Beispiel ist Python 3.6.8 installiert, das eine virtuelle Umgebung erstellt und 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, zum Beispiel das Erstellen und Aktivieren einer virtuellen Umgebung. Au\u00dferdem 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.<\/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\nErstelle Verzeichnis \/root\/.pg_chameleon\nErstelle Verzeichnis \/root\/.pg_chameleon\/configuration\/\nErstelle Verzeichnis \/root\/.pg_chameleon\/logs\/\nErstelle Verzeichnis \/root\/.pg_chameleon\/pid\/\nKopiere Beispieldatei in \/root\/.pg_chameleon\/configuration\/\/config-example.yml<\/code><\/pre>\n
<\/p>\n
Wir erstellen jetzt eine Kopie von config-example.yml als default.yml, damit sie zur 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 es dem Benutzer, die Standardtypen\u00fcbertragung in einen anderen zu \u00e4ndern.\ntype_override:\n  \"tinyint(1)\":\n    override_to: boolean\n    override_tables:\n      - \"*\"\n\n#postgres Zielverbindungsdaten\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: fortsetzen\n    on_error_read: fortsetzen\n    auto_maintenance: \"deaktiviert\"\n    gtid_enable: Nein\n    type: mysql\n    skip_events:\n      insert:\n        - delphis_mediterranea.foo #\u00fcberspringt Einf\u00fcgungen in die Tabelle delphis_mediterranea.foo\n      delete:\n        - delphis_mediterranea #\u00fcberspringt L\u00f6schungen 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 an die Quell- und Zielumgebungen, und unten finden Sie eine \u00dcbersicht \u00fcber die verschiedenen Abschnitte der Konfigurationsdatei.<\/p>\n
<\/p>\n
In der Konfigurationsdatei default.yml gibt es einen Abschnitt f\u00fcr globale Parameter (global settings), in dem Sie Einstellungen wie den Speicherort der Sperrdatei, den Speicherort der Protokolle, den Zeitraum der Protokollaufbewahrung usw. verwalten k\u00f6nnen. Danach folgt der Abschnitt Typ\u00fcberschreibung (type override), in dem eine Reihe von Regeln zur Typ\u00fcberschreibung w\u00e4hrend der Replikation angegeben sind. Im Standardbeispiel wird eine Typ\u00fcberschreibungsregel verwendet, die tinyint(1) in einen booleschen Wert 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 Quellendaten an, also die Verbindungsparameter zur Quell-Datenbank, die Schema-Mappings zwischen der Quell- und Ziel-Datenbank, die zu \u00fcberspringenden Tabellen, Zeitlimits, Speicher und Paketgr\u00f6\u00dfen. Beachten Sie, dass \u201esources\u201c im Plural angegeben ist, das bedeutet, dass wir mehrere Quell-Datenbanken f\u00fcr eine Ziel-Datenbank hinzuf\u00fcgen k\u00f6nnen, um die Konfiguration \u201eviele zu eins\u201c einzurichten.<\/p>\n
<\/p>\n
Die Datenbank world_x im Beispiel enth\u00e4lt 4 Tabellen mit Zeilen, die von der MySQL-Community als Beispiel angeboten werden. Sie kann heruntergeladen werden. hier<\/a><\/noindex>Das Beispiel f\u00fcr die Datenbank wird in Form eines tar- und komprimierten Archivs mit Anweisungen zum Erstellen und Importieren der Zeilen geliefert.<\/p>\n
<\/p>\n
In den Datenbanken MySQL und PostgreSQL wird ein spezieller Benutzer mit dem gleichen Namen usr_replica erstellt. In MySQL erh\u00e4lt er zus\u00e4tzliche Rechte zum Lesen aller replizierten Tabellen.<\/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 die Datenbank db_replica erstellt, die \u00c4nderungen aus der MySQL-Datenbank empfangen wird. Der Benutzer usr_replica wird in PostgreSQL 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 so konfiguriert, dass einige Parameter ge\u00e4ndert werden, um sie auf die Replikation vorzubereiten, wie unten gezeigt. Der Datenbankserver muss neu gestartet werden, 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
Es ist jetzt wichtig, die Verbindung zu beiden Datenbanken zu \u00fcberpr\u00fcfen, damit 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 der Konfiguration hinzu, indem es die Konfigurationsdatei (default.yml) liest, 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 weisen eindeutig auf ihre erfolgreiche Ausf\u00fchrung hin. Alle Fehler oder Syntaxprobleme werden in klaren und verst\u00e4ndlichen Nachrichten mit Hinweisen zur Probleml\u00f6sung angezeigt.<\/p>\n
<\/p>\n
Schlie\u00dflich starten wir die Replikation mit start_replica und erhalten eine Nachricht \u00fcber den erfolgreichen Abschluss.<\/p>\n
<\/p>\n
$> chameleon start_replica --config default --source mysql \nout: Starte den Replikationsprozess f\u00fcr die Quelle mysql<\/code><\/pre>\n
<\/p>\n
Den Status der Replikation kann man mit dem Argument show_status abfragen, und Fehler k\u00f6nnen mit dem Argument show_errors angezeigt werden.<\/p>\n
<\/p>\n
Ergebnis.<\/a><\/noindex><\/p>\n
<\/p>\n
Wie bereits erw\u00e4hnt, werden alle Replikationsfunktionen von Daemons verwaltet. Um diese anzuzeigen, fragen wir die Prozessliste mit dem Linux-Befehl ps an, wie unten gezeigt.<\/p>\n
<\/p>\n
Ergebnis.<\/a><\/noindex><\/p>\n
<\/p>\n
Die Replikation wird nicht als eingerichtet angesehen, bis wir sie in Echtzeit getestet haben, wie unten gezeigt. Wir erstellen eine Tabelle, f\u00fcgen ein paar Eintr\u00e4ge 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\u00e4gen 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 Synchronisierungsprozess f\u00fcr die Quelle mysql wurde gestartet.<\/code><\/pre>\n
<\/p>\n
Um die Testergebnisse zu best\u00e4tigen, fragen wir die Tabelle aus der PostgreSQL-Datenbank ab 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 | one\n  2 | two<\/code><\/pre>\n
<\/p>\n
Wenn wir eine Migration durchf\u00fchren, werden die folgenden Befehle in pg_chameleon deren Abschluss darstellen. Diese Befehle sollten ausgef\u00fchrt werden, nachdem wir sichergestellt haben, dass die Zeilen aller Zieltabellen repliziert wurden, und das Ergebnis wird eine sauber \u00fcbertragene PostgreSQL-Datenbank sein, die keine Verweise auf die urspr\u00fcngliche Datenbank oder das Replikationsschema (sch_chameleon) beinhaltet.<\/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
Die Vorteile von pg_chameleon<\/h3>\n
<\/p>\n
Einfache Einrichtung und Konfiguration.
\nBenutzerfreundliche Fehlerbehebung und Auffinden von Anomalien mit verst\u00e4ndlichen Fehlermeldungen.
\nNach der Initialisierung k\u00f6nnen zus\u00e4tzliche spezielle Tabellen zur Replikation hinzugef\u00fcgt werden, ohne die restliche Konfiguration zu \u00e4ndern.
\nEs k\u00f6nnen mehrere Quell-Datenbanken f\u00fcr eine Ziel-Datenbank konfiguriert werden, was sehr praktisch ist, wenn Sie Daten aus einer oder mehreren MySQL-Datenbanken in einer PostgreSQL-Datenbank zusammenf\u00fchren.
\nAusgew\u00e4hlte Tabellen m\u00fcssen nicht repliziert werden.<\/p>\n
<\/p>\n
Nachteile von pg_chameleon<\/h3>\n
<\/p>\n
Es wird nur MySQL 5.5 und h\u00f6her als Quelle und PostgreSQL 9.5 und h\u00f6her als Ziel-Datenbank unterst\u00fctzt.
\nJede Tabelle muss einen Prim\u00e4r- oder eindeutigen Schl\u00fcssel haben, sonst werden die Tabellen w\u00e4hrend des Init_replica-Prozesses initialisiert, aber nicht repliziert.
\nDie Replikation erfolgt einseitig \u2014 nur von MySQL nach PostgreSQL. Daher eignet sie sich nur f\u00fcr das Schema \"aktiv-passiv\".
\nDie Quelle kann nur eine MySQL-Datenbank sein, w\u00e4hrend die Unterst\u00fctzung f\u00fcr PostgreSQL-Datenbanken als Quelle noch experimentell und mit Einschr\u00e4nkungen ist (erfahren Sie mehr 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 einseitig ist, weshalb Datenbankspezialisten wahrscheinlich nicht wollen, es f\u00fcr etwas anderes als Migration zu verwenden. Das Problem der einseitigen Replikation kann jedoch mit einem weiteren Open-Source-Tool \u2014 SymmetricDS \u2014 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 beliebige Datenbanken in andere g\u00e4ngige Datenbanken repliziert: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird und andere Cloud-Datenbankinstanzen wie Redshift und Azure. Verf\u00fcgbare Funktionen: Datenbank- und Dateisynchronisierung, Replikation mehrerer f\u00fchrender 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\u00f6her). Hier k\u00f6nnen Daten\u00e4nderungen \u00fcber Trigger in der Quell-Datenbank aufgezeichnet und in Form von Paketen an die entsprechende Ziel-Datenbank weitergeleitet werden.<\/p>\n
<\/p>\n
Funktionen von SymmetricDS<\/h3>\n
<\/p>\n
Das Tool ist plattformunabh\u00e4ngig, was bedeutet, dass zwei oder mehr unterschiedliche Datenbanken Daten austauschen k\u00f6nnen.
\nRelationale Datenbanken synchronisieren sich durch das Aufzeichnen von Daten\u00e4nderungen, w\u00e4hrend dateibasierten Datenbanken die Dateisynchronisierung verwenden.
\nZweiseitige Replikation unter Verwendung von Push- und Pull-Methoden basierend auf einer Regelmenge.
\nDie Daten\u00fcbertragung ist \u00fcber gesicherte Netzwerke und Netzwerke mit niedriger Bandbreite m\u00f6glich.
\nAutomatische Wiederherstellung bei der Wiederaufnahme des Betriebs von Knoten nach einem Ausfall und automatisches L\u00f6sen von Konflikten.
\nKompatibilit\u00e4t mit der Cloud und effektive API-Erweiterungen.<\/p>\n
<\/p>\n
Beispiel<\/h3>\n
<\/p>\n
SymmetricDS kann in einer von zwei Varianten konfiguriert werden:
\nEin f\u00fchrender (\u00fcbergeordneter) Knoten, der zentral die Replikation von Daten zwischen zwei untergeordneten (untergeordneten) Knoten koordiniert, wobei der Datenaustausch zwischen den untergeordneten Knoten nur \u00fcber den \u00fcbergeordneten Knoten 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\u00e4re zu lang, die gesamte Architektur zu beschreiben, daher schauen Sie sich Anleitung<\/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 von hier<\/a><\/noindex> und entpacken Sie sie an einen Ort Ihrer Wahl. In der folgenden Tabelle sind Informationen \u00fcber den Installationsort und die Version von SymmetricDS in diesem Beispiel sowie die Datenbankversionen, Linuxversionen, IP-Adressen und Ports f\u00fcr beide Knoten aufgef\u00fchrt.<\/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
Version von SymmetricDS<\/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
Name des SymmetricDS-Knotens<\/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 untergeordnete Verzeichnisse und Dateien gespeichert. Wir interessieren uns f\u00fcr die untergeordneten Verzeichnisse samples und engines. Im Verzeichnis samples befinden sich Beispielkonfigurationsdateien mit Knotenattributen sowie Beispiel-SQL-Skripte f\u00fcr einen schnellen Einstieg in die Demonstration.<\/p>\n
<\/p>\n
Im Verzeichnis samples sehen wir drei Konfigurationsdateien mit Knotenattributen \u2014 der Name zeigt die Art des Knotens in einem bestimmten Schema.<\/p>\n
<\/p>\n
corp-000.properties\nstore-001.properties\nstore-002.properties<\/code><\/pre>\n
<\/p>\n
In SymmetricDS sind alle erforderlichen Konfigurationsdateien f\u00fcr ein Basis-Schema aus 3 Knoten (Variante 1) vorhanden, und dieselben Dateien k\u00f6nnen f\u00fcr ein Schema aus 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 Folgendes:<\/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 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\u00e4hrend der Erstellung des Schemas werden Tabellen erstellt. 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 restlichen Informationen sind in der unten angef\u00fchrten Datei node.properties enthalten. Der Knoten store-001 verwendet die PostgreSQL-Datenbank, w\u00e4hrend pgdb_replica die Datenbank f\u00fcr die Replikation ist. registration.url erm\u00f6glicht es dem Host vm2, mit dem Host vm1 zu kommunizieren und die Konfigurationsdetails zu erhalten.<\/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 von SymmetricDS enth\u00e4lt Parameter zur Konfiguration der bidirektionalen Replikation zwischen zwei Datenbankservern (zwei Knoten). Die folgenden Schritte werden auf dem Host vm1 (corp-000) durchgef\u00fchrt, der ein Beispiel-Schema mit 4 Tabellen erstellt. Anschlie\u00dfend 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\u00dflich werden Beispiel-Daten 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 f\u00fcr die Replikation von corp-000 nach store-001 konfiguriert, 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 ein 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
Es ist wichtig sicherzustellen, dass die Datenbank MySQL auf vm1 Beispieltabellen und die Katalogtabellen von SymmetricDS enth\u00e4lt. Beachten Sie, dass die systemeigenen Tabellen von SymmetricDS (mit dem Pr\u00e4fix 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. Au\u00dferdem wird die Datenbank auf dem Knoten store-001 nur 4 Beispieltabellen ohne Daten enthalten.<\/p>\n
<\/p>\n
Das ist alles. Die Umgebung ist bereit zur Ausf\u00fchrung der Serverprozesse von sym auf beiden Knoten, 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 Logeintr\u00e4ge 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.<\/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 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.<\/p>\n
<\/p>\n
vm1$> .\/symadmin --engine corp-000 reload-node 001<\/code><\/pre>\n
<\/p>\n
An diesem Punkt wird ein neuer Datensatz in die Tabelle item in der MySQL-Datenbank auf dem Knoten corp-000 (Host: vm1) eingef\u00fcgt, und wir k\u00f6nnen die Replikation in die 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 Sek.)<\/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 Eintrag 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 die erfolgreiche Einrichtung der bidirektionalen Replikation von Beispieltabellen zwischen MySQL- und PostgreSQL-Datenbanken. Um die Replikation f\u00fcr neue benutzerdefinierte Tabellen einzurichten, f\u00fchren 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.<\/p>\n
<\/p>\n
mysql> create table t1 (no integer);\nAbfrage OK, 0 Zeilen betroffen (0.01 Sek.)<\/code><\/pre>\n
<\/p>\n
mysql> insert into sym_channel (channel_id,create_time,last_update_time) \nvalues ('t1',current_timestamp,current_timestamp);\nAbfrage OK, 1 Zeile betroffen (0.01 Sek.)<\/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);\nAbfrage OK, 1 Zeile betroffen (0.01 Sek.)<\/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);\nAbfrage OK, 1 Zeile betroffen (0.01 Sek.)<\/code><\/pre>\n
<\/p>\n
Die Konfiguration erh\u00e4lt dann eine Benachrichtigung \u00fcber die \u00c4nderung des Schemas, das hei\u00dft, die Hinzuf\u00fcgung einer neuen Tabelle, \u00fcber den Befehl 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 wird 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 fertigen Satzes von Dateien mit Parametern zum Erstellen eines Schemas mit drei oder zwei Knoten.
\nPlattform\u00fcbergreifende Datenbanken und Unabh\u00e4ngigkeit von der Plattform, einschlie\u00dflich Server, Laptops und mobilen Ger\u00e4ten.
\nReplikation jeder Datenbank in jede andere Datenbank lokal, \u00fcber WAN oder in der Cloud.
\nDie M\u00f6glichkeit, optimal mit einem Paar von Datenbanken oder mehreren Tausend f\u00fcr eine bequeme Replikation zu arbeiten.
\nDie kostenpflichtige Version mit grafischer Benutzeroberfl\u00e4che und hervorragendem Support.<\/p>\n
<\/p>\n
Nachteile von SymmetricDS<\/h3>\n
<\/p>\n
Es ist notwendig, die Regeln und die Richtung der Replikation manuell in der Eingabeaufforderung \u00fcber SQL-Operatoren f\u00fcr das Laden der Katalogtabellen zu definieren, was unangenehm sein kann.
\nDie Einrichtung vieler Tabellen f\u00fcr die Replikation kann m\u00fchsam sein, wenn man keine Skripte zur Erstellung der SQL-Operatoren verwendet, die die Regeln und die Richtung der Replikation definieren.
\nIn die Protokolle wird zu viele Informationen geschrieben, und manchmal muss Ordnung in die Protokolldatei gebracht werden, damit sie nicht zu viel Platz einnimmt.<\/p>\n
<\/p>\n
Zusammenfassung zu SymmetricDS<\/h3>\n
<\/p>\n
SymmetricDS erm\u00f6glicht die Konfiguration der bidirektionalen Replikation zwischen zwei, drei und sogar mehreren Tausend Knoten, um Replikationen durchzuf\u00fchren und Dateien zu synchronisieren. Es handelt sich um ein einzigartiges Tool, das viele Aufgaben selbstst\u00e4ndig erledigt, wie beispielsweise die automatische Wiederherstellung von Daten nach l\u00e4ngeren Ausfallzeiten am Knoten, den sicheren und effizienten Datenaustausch zwischen Knoten \u00fcber HTTPS, die automatische Konfliktverwaltung basierend auf einem Regelwerk usw. SymmetricDS f\u00fchrt Replikationen zwischen beliebigen Datenbanken durch, sodass es f\u00fcr eine Vielzahl von Szenarien genutzt werden kann, einschlie\u00dflich Migration, Upgrade, Verteilung, Filterung und Transformation von Daten auf unterschiedlichen Plattformen.<\/p>\n
<\/p>\n
Das Beispiel wurde auf der Grundlage des offiziellen kurzen Handbuchs<\/a><\/noindex> zu SymmetricDS. In Benutzerhandbuch<\/a><\/noindex> Es werden verschiedene Konzepte im Zusammenhang mit der Einrichtung 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\udd47Kreuzreplikation zwischen PostgreSQL und MySQL | ProHoster","description":"Ich werde im Gro\u00dfen und Ganzen dar\u00fcber sprechen.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}