{"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\/da\/blog\/administrirovanie\/perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql","title":{"rendered":"Krydsreplikation mellem PostgreSQL og MySQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Krydsreplikation<\/p>\n

<\/p>\n

Jeg vil i grove tr\u00e6k fort\u00e6lle om krydsgentagelse mellem PostgreSQL og MySQL, samt metoder til at konfigurere krydsgentagelse mellem disse to databaser. Database i krydsgentagelse kaldes normalt homogene, og det er en praktisk metode til at overf\u00f8re fra en server af en relationel DBMS til en anden.<\/p>\n

<\/p>\n

Databaserne PostgreSQL og MySQL betragtes som relationelle, men med ekstra udvidelser tilbyder de NoSQL-muligheder. Her vil vi diskutere gentagelse mellem PostgreSQL og MySQL set fra et relationelt DBMS-perspektiv.<\/p>\n

<\/p>\n

Vi vil ikke beskrive hele den indre mekanisme, kun de grundl\u00e6ggende principper, s\u00e5 du f\u00e5r en id\u00e9 om konfigurationen af gentagelse mellem databaseservere, fordele, begr\u00e6nsninger og anvendelsesscenarier.<\/p>\n

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

Normalt udf\u00f8res gentagelse mellem to identiske databaseservere enten i bin\u00e6r tilstand eller ved hj\u00e6lp af foresp\u00f8rgsler mellem den f\u00f8rende node (som ogs\u00e5 er udgiver, hoved eller aktiv) og den underordnede (abonnent, ventende eller passiv). Form\u00e5let med gentagelse er at give et realtidskopi af den prim\u00e6re database p\u00e5 underordnede side. Data sendes fra den f\u00f8rende til den underordnede, det vil sige fra aktiv til passiv, fordi gentagelse kun udf\u00f8res i \u00e9n retning. Men det er muligt at konfigurere gentagelse mellem to databaser i begge retninger, s\u00e5 data sendes fra underordnede til f\u00f8rende i en 'aktiv-aktiv' konfiguration. Alt dette, herunder kaskadegensekvenser, er muligt mellem to eller flere identiske databaseservere. Konfigurationen 'aktiv-aktiv' eller 'aktiv-passiv' afh\u00e6nger af behovet, tilg\u00e6ngeligheden af s\u00e5danne muligheder i den oprindelige konfiguration eller brugen af eksterne l\u00f8sninger til konfiguration og eksisterende kompromiser.<\/p>\n

<\/p>\n

Den beskrevne konfiguration er mulig mellem forskellige databaseservere. En server kan konfigureres til at modtage replikerede data fra en anden databaseserver og samtidig bevare snapshots af de replikerede data i realtid. MySQL og PostgreSQL tilbyder de fleste af disse konfigurationer enten selv eller ved hj\u00e6lp af tredjepartsudvidelser, herunder metoder til bin\u00e6r log, diskl\u00e5se og metoder baseret p\u00e5 operatorer og r\u00e6kker.<\/p>\n

<\/p>\n

Krydsreplikation mellem MySQL og PostgreSQL er n\u00f8dvendig for engangs migration fra \u00e9n database-server til en anden. Disse databaser bruger forskellige protokoller, s\u00e5 de kan ikke forbindes direkte. For at etablere datadeling kan man bruge et eksternt open source-v\u00e6rkt\u00f8j s\u00e5som pg_chameleon.<\/p>\n

<\/p>\n

Hvad er pg_chameleon<\/h3>\n

<\/p>\n

pg_chameleon er et replikationssystem fra MySQL til PostgreSQL baseret p\u00e5 Python 3. Det bruger open source-biblioteket mysql-replication, ogs\u00e5 skrevet p\u00e5 Python. Data fra MySQL tabeller udtr\u00e6kkes og gemmes som JSONB-objekter i PostgreSQL databasen, hvorefter de dekodes af pl\/pgsql-funktionen og genopbygges i PostgreSQL databasen.<\/p>\n

<\/p>\n

Kapaciteterne i pg_chameleon<\/h3>\n

<\/p>\n

Flere MySQL-skemaer fra en enkelt klynge kan replikeres til \u00e9n m\u00e5l PostgreSQL-database med konfigurationen \"\u00e9n til mange\".
\nNavnene p\u00e5 kilde- og m\u00e5lschemaer m\u00e5 ikke v\u00e6re ens.
\nReplikationsdata kan udtr\u00e6kkes fra en kaskadereplik MySQL.
\nTabeller, der ikke kan replikeres eller skaber fejl, ekskluderes.
\nHver replikationsfunktion styres af d\u00e6moner.
\nKontrol via parametre og konfigurationsfiler baseret p\u00e5 YAML.<\/p>\n

<\/p>\n

Eksempel<\/h3>\n

<\/p>\n

V\u00e6rt
\nvm1
\nvm2<\/p>\n

OS-version<\/strong>
\nCentOS Linux 7.6 x86_64
\nCentOS Linux 7.5 x86_64<\/p>\n

Database server version<\/strong>
\nMySQL 5.7.26
\nPostgreSQL 10.5<\/p>\n

Database port<\/strong>
\n3306
\n5433<\/p>\n

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

<\/p>\n

For at komme i gang skal du forberede alle n\u00f8dvendige komponenter til installationen af pg_chameleon. I dette eksempel er Python 3.6.8 installeret, som opretter et virtuelt milj\u00f8 og aktiverer det.<\/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
Efter en vellykket installation af Python3.6 skal du opfylde de \u00f8vrige krav, s\u00e5som at oprette og aktivere det virtuelle milj\u00f8. Derudover opdateres pip-modulet til den nyeste version og bruges til at installere pg_chameleon. I kommandoerne nedenfor installeres pg_chameleon 2.0.9 bevidst, selvom den nyeste version er 2.0.10. Dette g\u00f8res for at undg\u00e5 nye fejl i den opdaterede version.<\/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
Derefter kalder vi pg_chameleon (chameleon er kommandoen) med argumentet set_configuration_files for at aktivere pg_chameleon og oprette standardkataloger og konfigurationsfiler.<\/p>\n
<\/p>\n
(venv) $> chameleon set_configuration_files\ncreating directory \/root\/.pg_chameleon\ncreating directory \/root\/.pg_chameleon\/configuration\/\ncreating directory \/root\/.pg_chameleon\/logs\/\ncreating directory \/root\/.pg_chameleon\/pid\/\ncoping configuration example in \/root\/.pg_chameleon\/configuration\/\/config-example.yml<\/code><\/pre>\n
<\/p>\n
Nu opretter vi en kopi af config-example.yml som default.yml, s\u00e5 den bliver standardkonfigurationsfilen. Et eksempel p\u00e5 konfigurationsfilen til dette eksempel gives nedenfor.<\/p>\n
<\/p>\n
$> cat default.yml\n---\n# globale indstillinger\npid_dir: '~\/.pg_chameleon\/pid\/'\nlog_dir: '~\/.pg_chameleon\/logs\/'\nlog_dest: fil\nlog_level: info\nlog_days_keep: 10\nrollbar_key: ''\nrollbar_env: ''\n\n# type_override giver brugeren mulighed for at overskrive standard typekonvertering til en anden.\ntype_override:\n  \"tinyint(1)\":\n    override_to: boolean\n    override_tables:\n      - \"*\"\n\n#postgres destinationsforbindelse\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 day'\n    copy_max_memory: \"300M\"\n    copy_mode: 'file'\n    out_dir: \/tmp\n    sleep_loop: 1\n    on_error_replay: continue\n    on_error_read: continue\n    auto_maintenance: \"disabled\"\n    gtid_enable: No\n    type: mysql\n    skip_events:\n      insert:\n        - delphis_mediterranea.foo #spring inds\u00e6tninger p\u00e5 tabellen delphis_mediterranea.foo\n      delete:\n        - delphis_mediterranea #spring sletninger p\u00e5 skemaet delphis_mediterranea\n      update:<\/code><\/pre>\n
<\/p>\n
Konfigurationsfilen i dette eksempel er et eksempel p\u00e5 en fil med pg_chameleon med sm\u00e5 \u00e6ndringer i overensstemmelse med kilde- og destinationsmilj\u00f8erne, og nedenfor gives en oversigt over de forskellige sektioner i konfigurationsfilen.<\/p>\n
<\/p>\n
I konfigurationsfilen default.yml er der en sektion for globale indstillinger, hvor du kan administrere indstillinger s\u00e5som placeringen af l\u00e5sefilen, logfilerne, logopbevaringsperioden osv. Derefter f\u00f8lger sektionen for typeoverriding, der angiver et s\u00e6t regler for typeoverriding under replikering. I standardeksemplet anvendes en regel til typeoverriding, som konverterer tinyint(1) til en boolesk v\u00e6rdi. I den n\u00e6ste sektion angiver vi forbindelsesdetaljerne til den \u00f8nskede database. I vores tilf\u00e6lde er det databasen PostgreSQL, ben\u00e6vnt pg_conn. I den sidste sektion angiver vi kildedataene, dvs. parametrene for forbindelsen til kilde databasen, skemaet der kortl\u00e6gger kilde- og m\u00e5ldatabasen, de tabeller der skal undg\u00e5s, timeout, hukommelse, batchst\u00f8rrelse. Bem\u00e6rk, at 'sources' er angivet i flertal, hvilket betyder, at vi kan tilf\u00f8je flere kildedatabaser til \u00e9n destination for at konfigurere en \"mange-til-en\" ops\u00e6tning.<\/p>\n
<\/p>\n
Database world_x in the example contains 4 tables with rows that the MySQL community offers as an example. It can be downloaded her<\/a><\/noindex>. The example database is provided as a tar and compressed archive with instructions for creating and importing rows.<\/p>\n
<\/p>\n
In MySQL and PostgreSQL databases, a special user with the same name usr_replica is created. In MySQL, he is granted additional rights to read all replicated tables.<\/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
On the PostgreSQL side, a database db_replica is created that will receive changes from the MySQL database. The user usr_replica in PostgreSQL is automatically configured as the owner of two schemas pgworld_x and sch_chameleon, which contain the actual replicated tables and replication catalog tables, respectively. The automatic configuration is managed by the create_replica_schema argument, as you will see below.<\/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
The MySQL database is configured with changes to certain parameters to prepare it for replication, as shown below. The database server will need to be restarted for the changes to take effect.<\/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
It is now important to check the connection to both database servers to avoid problems when executing pg_chameleon commands.<\/p>\n
<\/p>\n
On the PostgreSQL node:<\/p>\n
<\/p>\n
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x<\/code><\/pre>\n
<\/p>\n
On the MySQL node:<\/p>\n
<\/p>\n
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica<\/code><\/pre>\n
<\/p>\n
The following three pg_chameleon (chameleon) commands prepare the environment, add the source, and initialize the replica. The create_replica_schema argument in pg_chameleon creates a default schema (sch_chameleon) and a replication schema (pgworld_x) in the PostgreSQL database, as we already mentioned. The add_source argument adds the source database to the configuration by reading the configuration file (default.yml), and in our case, this is mysql, while init_replica initializes the configuration based on the parameters in the configuration file.<\/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
Resultaterne af disse tre kommandoer indikerer tydeligt deres succesfulde udf\u00f8relse. Alle fejl eller syntaksfejl vises i enkle og forst\u00e5elige meddelelser med tips til at rette problemerne.<\/p>\n
<\/p>\n
Til sidst, lad os starte replikationen med start_replica og f\u00e5 en meddelelse om succesfuld udf\u00f8relse.<\/p>\n
<\/p>\n
$> chameleon start_replica --config default --source mysql \noutput: Starter replikationsprocessen for kilde mysql<\/code><\/pre>\n
<\/p>\n
Status for replikationen kan anmodes om med argumentet show_status, og fejl kan gennemg\u00e5s med argumentet show_errors.<\/p>\n
<\/p>\n
Result.<\/a><\/noindex><\/p>\n
<\/p>\n
Som n\u00e6vnt styres hver replikationsfunktion af d\u00e6moner. For at se dem anmoder vi om proceslisten med Linux-kommandoen ps, som vist nedenfor.<\/p>\n
<\/p>\n
Result.<\/a><\/noindex><\/p>\n
<\/p>\n
Replikationen betragtes ikke som opsat, f\u00f8r vi tester den i realtid som vist nedenfor. Vi opretter en tabel, inds\u00e6tter et par poster i MySQL-databasen og kalder argumentet sync_tables i pg_chameleon for at opdatere d\u00e6monerne og replikere tabellen med posterne i PostgreSQL-databasen.<\/p>\n
<\/p>\n
mysql> create table t1 (n1 int primary key, n2 varchar(10));\nQuery OK, 0 rows affected (0.01 sec)\nmysql> insert into t1 values (1,'one');\nQuery OK, 1 row affected (0.00 sec)\nmysql> insert into t1 values (2,'two');\nQuery OK, 1 row affected (0.00 sec)<\/code><\/pre>\n
<\/p>\n
$> chameleon sync_tables --tables world_x.t1 --config default --source mysql\nSync tabelprocessen for kilde mysql er startet.<\/code><\/pre>\n
<\/p>\n
For at bekr\u00e6fte testresultaterne anmoder vi om tabellen fra PostgreSQL-databasen og viser r\u00e6kkerne.<\/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
Hvis vi udf\u00f8rer en migration, vil f\u00f8lgende pg_chameleon-kommandoer markere dens afslutning. Kommandoerne skal udf\u00f8res, efter vi har bekr\u00e6ftet, at alle m\u00e5ltabellers r\u00e6kker er blevet replikeret, og resultatet vil v\u00e6re en p\u00e6n overf\u00f8rt PostgreSQL-database uden henvisninger til den oprindelige database eller replikationsskemaet (sch_chameleon).<\/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
Valgfrit kan de f\u00f8lgende kommandoer fjerne den oprindelige konfiguration og replikationsskemaet.<\/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
Fordele ved pg_chameleon<\/h3>\n
<\/p>\n
Nem ops\u00e6tning og konfiguration.
\nBrugervenlig fejlfinding og identifikation af anomalier med klare fejlmeddelelser.
\nDet er muligt at tilf\u00f8je yderligere specialtabeller til replikationen efter initialization, uden at \u00e6ndre den \u00f8vrige konfiguration.
\nDet er muligt at konfigurere flere kildedatabaser til \u00e9n m\u00e5l database, hvilket er meget praktisk, hvis du kombinerer data fra en eller flere MySQL-databaser til \u00e9n PostgreSQL-database.
\nValgte tabeller kan undg\u00e5s at blive replikeret.<\/p>\n
<\/p>\n
Ulemper ved pg_chameleon<\/h3>\n
<\/p>\n
Kun underst\u00f8ttet med MySQL 5.5 og nyere som kilde og PostgreSQL 9.5 og nyere som m\u00e5l database.
\nHver tabel skal have en prim\u00e6r eller unik n\u00f8gle, ellers initialiseres tabellerne under init_replica-processen, men replikeres ikke.
\nEnvejsreplikering \u2014 kun fra MySQL til PostgreSQL. Derfor er det kun egnet til et \"aktivt-passiv\"-skema.
\nKilden kan kun v\u00e6re en MySQL-database, og underst\u00f8ttelse af PostgreSQL som kilde er kun eksperimentel og med begr\u00e6nsninger (l\u00e6s mere) her<\/a><\/noindex>)<\/p>\n
<\/p>\n
Sammenfatning af pg_chameleon<\/h3>\n
<\/p>\n
Replikationsmetoden i pg_chameleon er velegnet til migrering af databaser fra MySQL til PostgreSQL. En betydelig ulempe er, at replikeringen kun er envejs, s\u00e5 databaseeksperter vil n\u00e6ppe \u00f8nske at bruge det til andet end migrering. Men problemet med envejsreplikering kan l\u00f8ses med et andet open source-v\u00e6rkt\u00f8j \u2014 SymmetricDS.<\/p>\n
<\/p>\n
L\u00e6s mere i den officielle dokumentation her<\/a><\/noindex>. CLI-dokumentationen kan findes her<\/a><\/noindex>.<\/p>\n
<\/p>\n
Oversigt over SymmetricDS<\/h3>\n
<\/p>\n
SymmetricDS er et open source-v\u00e6rkt\u00f8j, der replikerer enhver database til enhver anden almindelig database: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird og andre cloud-databaseinstanser, s\u00e5som Redshift og Azure osv. Tilg\u00e6ngelige funktioner: databasesynkronisering og filsynkronisering, replikering af flere kildedatabaser, filtreret synkronisering, transformation og mere. Det er et Java-baseret v\u00e6rkt\u00f8j, og standardudgaven af JRE eller JDK (version 8.0 eller nyere) er p\u00e5kr\u00e6vet. Her kan \u00e6ndringer i data registreres via triggers i kildedatabasen og sendes til den tilsvarende m\u00e5ldatabase i form af pakker.<\/p>\n
<\/p>\n
Funktioner i SymmetricDS<\/h3>\n
<\/p>\n
V\u00e6rkt\u00f8jet er platform-uafh\u00e6ngigt, hvilket betyder, at to eller flere forskellige databaser kan udveksle data.
\nRelationelle databaser synkroniseres ved hj\u00e6lp af \u00e6ndringsregistrering, mens filsystembaserede databaser bruger filsynkronisering.
\nTo-vejsreplikering ved hj\u00e6lp af Push- og Pull-metoder baseret p\u00e5 s\u00e6t regler.
\nDataoverf\u00f8rsel er mulig via beskyttede netv\u00e6rk og netv\u00e6rk med lav b\u00e5ndbredde.
\nAutomatisk genopretning ved genoptagelse af noder efter nedbrud og automatisk konfliktl\u00f8sning.
\nKompatibilitet med skyen og effektive API-udvidelser.<\/p>\n
<\/p>\n
Eksempel<\/h3>\n
<\/p>\n
SymmetricDS kan konfigureres p\u00e5 en af to m\u00e5der:
\nEn f\u00f8rende (parent) node, der centralt koordinerer datareplication mellem to underordnede (child) noder, og dataudveksling mellem de underordnede noder finder kun sted gennem den f\u00f8rende.
\nEn aktiv node (node 1) kan udveksle data til replication med en anden aktiv node (node 2) uden mellemm\u00e6nd.<\/p>\n
<\/p>\n
I begge tilf\u00e6lde foreg\u00e5r dataudvekslingen via Push og Pull. I dette eksempel vil vi se p\u00e5 konfigurationen \"aktiv-aktiv\". At beskrive hele arkitekturen ville tage for lang tid, s\u00e5 se vejledning<\/a><\/noindex>for at l\u00e6re mere om SymmetricDS-enheden.<\/p>\n
<\/p>\n
At installere SymmetricDS er meget nemt: download den opensource-version af zip-filen from here<\/a><\/noindex> og ekstrakt den, hvor du vil. Tabellen nedenfor indeholder oplysninger om installationsstedet og versionen af SymmetricDS i dette eksempel, samt databasens versioner, versioner af Linux, IP-adresser og porte for begge noder.<\/p>\n
<\/p>\n
V\u00e6rt
\nvm1
\nvm2<\/p>\n
OS-version<\/strong>
\nCentOS Linux 7.6 x86_64
\nCentOS Linux 7.6 x86_64<\/p>\n
Database server version<\/strong>
\nMySQL 5.7.26
\nPostgreSQL 10.5<\/p>\n
Database port<\/strong>
\n3306
\n5832<\/p>\n
IP-adresse<\/strong>
\n192.168.1.107
\n192.168.1.112<\/p>\n
Version af SymmetricDS<\/strong>
\nSymmetricDS 3.9
\nSymmetricDS 3.9<\/p>\n
Installationssti for SymmetricDS<\/strong>
\n\/usr\/local\/symmetric-server-3.9.20
\n\/usr\/local\/symmetric-server-3.9.20<\/p>\n
Navn p\u00e5 SymmetricDS-node<\/strong>
\ncorp-000
\nstore-001<\/p>\n
<\/p>\n
Her installerer vi SymmetricDS i \/usr\/local\/symmetric-server-3.9.20, og her vil forskellige underkataloger og filer blive opbevaret. Vi er interesseret i underkatalogerne samples og engines. I katalogen samples findes eksempelkonfigurationsfiler med nodeegenskaber samt eksempel-SQL-scripts til hurtigt at komme i gang med demonstrationer.<\/p>\n
<\/p>\n
I katalogen samples ser vi tre konfigurationsfiler med nodeegenskaber - navnet angiver nodeligens karakter i en bestemt skema.<\/p>\n
<\/p>\n
corp-000.properties\nstore-001.properties\nstore-002.properties<\/code><\/pre>\n
<\/p>\n
I SymmetricDS er alle n\u00f8dvendige konfigurationsfiler til en grundl\u00e6ggende skema af 3 noder (variant 1), og de samme filer kan bruges til en skema med 2 noder (variant 2). Vi kopierer den n\u00f8dvendige konfigurationsfil fra katalogen samples til engines p\u00e5 v\u00e6rten vm1. S\u00e5dan ser det ud:<\/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
Denne knude i SymmetricDS-konfigurationen hedder corp-000, og forbindelsen til databasen h\u00e5ndteres af mysql jdbc-driveren, der bruger den ovenfor n\u00e6vnte forbindelsesstreng og legitimationsoplysninger til login. Vi opretter forbindelse til databasen replica_db, og under oprettelsen af skemaet vil tabellerne blive oprettet. sync.url angiver forbindelsespunktet til noden for synkronisering.<\/p>\n
<\/p>\n
Node 2 p\u00e5 v\u00e6rten vm2 konfigureres som store-001, og resten er angivet i node.properties-filen, som er vist nedenfor. Nodens store-001 k\u00f8rer en PostgreSQL-database, mens pgdb_replica er databasen til replikering. registration.url giver v\u00e6rten vm2 mulighed for at kontakte v\u00e6rten vm1 og f\u00e5 konfigurationsdetaljer fra denne.<\/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
Det f\u00e6rdige eksempel p\u00e5 SymmetricDS indeholder parametre til at konfigurere tovejsreplikering mellem to databaseservere (to noder). De f\u00f8lgende trin udf\u00f8res p\u00e5 v\u00e6rten vm1 (corp-000), som vil oprette et eksempel skema med 4 tabeller. Derefter opretter kommandoen create-sym-tables i symadmin tabellerne, hvor reglerne og retningen for replikering mellem noderne vil blive gemt. Endelig indl\u00e6ses eksemplariske data i tabellerne.<\/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
I eksemplet er tabellerne item og item_selling_price automatisk konfigureret til at replikere fra corp-000 til store-001, mens tabellerne sale (sale_transaction og sale_return_line_item) automatisk er konfigureret til at replikere fra store-001 til corp-000. Nu opretter vi skemaet i PostgreSQL-databasen p\u00e5 v\u00e6rten vm2 (store-001) for at forberede det til at modtage data fra corp-000.<\/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
S\u00f8rg for, at der i MySQL-databasen p\u00e5 vm1 er eksempler p\u00e5 tabeller og katalogtabeller fra SymmetricDS. Bem\u00e6rk, at SymmetricDS-systemtabellerne (med pr\u00e6fikset sym_) i \u00f8jeblikket kun er tilg\u00e6ngelige p\u00e5 noden corp-000, da vi udf\u00f8rte command create-sym-tables der og vil styre replikeringen. Derudover vil der kun v\u00e6re 4 eksemplartabeller uden data i databasen p\u00e5 noden store-001.<\/p>\n
<\/p>\n
Det er hele. Milj\u00f8et er klar til at k\u00f8re serverprocesserne sym p\u00e5 begge noder, som vist nedenfor.<\/p>\n
<\/p>\n
vm1$> cd \/usr\/local\/symmetric-server-3.9.20\/bin\nvm1$> sym 2>&1 &<\/code><\/pre>\n
<\/p>\n
Logfilerne sendes til baggrundslogfilen (symmetric.log) i logmappen i den mappe, hvor SymmetricDS er installeret, samt til standard output. Sym-serveren kan nu startes p\u00e5 noden store-001.<\/p>\n
<\/p>\n
vm2$> cd \/usr\/local\/symmetric-server-3.9.20\/bin\nvm2$> sym 2>&1 &<\/code><\/pre>\n
<\/p>\n
Hvis serverprocessen sym k\u00f8res p\u00e5 v\u00e6rten vm2, vil den oprette SymmetricDS katalogtabellerne ogs\u00e5 i PostgreSQL-databasen. Hvis serverprocessen sym k\u00f8res p\u00e5 begge noder, vil de koordinere med hinanden for at replikere data fra corp-000 til store-001. Hvis vi efter nogle sekunder foresp\u00f8rger de 4 tabeller p\u00e5 begge sider, vil vi se, at replikationen er lykkedes. Alternativt kan vi sende en initial belastning til noden store-001 fra corp-000 med f\u00f8lgende kommando.<\/p>\n
<\/p>\n
vm1$> .\/symadmin --engine corp-000 reload-node 001<\/code><\/pre>\n
<\/p>\n
P\u00e5 dette tidspunkt inds\u00e6ttes en ny post i item-tabellen i MySQL-databasen p\u00e5 noden corp-000 (v\u00e6rt: vm1), og vi kan kontrollere dens replikation i PostgreSQL-databasen p\u00e5 noden store-001 (v\u00e6rt: vm2). Vi ser Pull-operationen for at flytte data fra corp-000 til store-001.<\/p>\n
<\/p>\n
mysql> insert into item values ('22000002','Jelly Bean');\nQuery OK, 1 row affected (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 rows)<\/code><\/pre>\n
<\/p>\n
For at udf\u00f8re Push-operationen for at flytte data fra store-001 til corp-000, inds\u00e6tter vi en post i sale_transaction-tabellen og kontrollerer, at replikationen er udf\u00f8rt.<\/p>\n
<\/p>\n
Result.<\/a><\/noindex><\/p>\n
<\/p>\n
Vi ser en vellykket ops\u00e6tning af tovejsreplikation af eksempel-tabeller mellem MySQL- og PostgreSQL-databaser. For at konfigurere replikation for nye brugerdefinerede tabeller udf\u00f8rer vi f\u00f8lgende trin. Vi opretter tabellen t1 som eksempel og konfigurerer reglerne for dens replikation p\u00e5 f\u00f8lgende m\u00e5de. S\u00e5dan ops\u00e6tter vi kun replikation fra corp-000 til store-001.<\/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
Derefter modtager konfigurationen et notifikationssignal om \u00e6ndringen af skemaet, dvs. tilf\u00f8jelsen af en ny tabel, ved hj\u00e6lp af kommandoen symadmin med argumentet sync-triggers, som genskaber udl\u00f8sere for at matche tabeldefinitioner. send-schema udf\u00f8res for at sende \u00e6ndringerne i skemaet til noden store-001, og replikationen af tabel t1 er konfigureret.<\/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
Fordele ved SymmetricDS<\/h3>\n
<\/p>\n
Simpel installation og konfiguration, herunder et klar til brug s\u00e6t af filer med parametre til oprettelse af skema med tre eller to noder.
\nTv\u00e6rplatformskompatibilitet af databaser og uafh\u00e6ngighed af platformen, inklusive servere, b\u00e6rbare computere og mobile enheder.
\nReplikation af enhver database til enhver anden database lokalt, i WAN eller i cloud.
\nMulighed for optimal drift med et par databaser eller tusindvis for bekvem replikation.
\nBetalingsversion med grafisk gr\u00e6nseflade og fremragende support.<\/p>\n
<\/p>\n
Ulemper ved SymmetricDS<\/h3>\n
<\/p>\n
Det er n\u00f8dvendigt manuelt at definere replikationsregler og retning i kommandolinjen via SQL-operatorer for at indl\u00e6se katalogtabel, hvilket kan v\u00e6re besv\u00e6rligt.
\nAt konfigurere mange tabeller til replikation kan v\u00e6re tr\u00e6ttende, medmindre man bruger scripts til at oprette SQL-operatorer, der definerer replikationsregler og retning.
\nLogfilerne indeholder for meget information, og nogle gange skal man rydde op i logfilen for at undg\u00e5, at den fylder for meget.<\/p>\n
<\/p>\n
Konklusion vedr\u00f8rende SymmetricDS<\/h3>\n
<\/p>\n
SymmetricDS muligg\u00f8r konfiguration af tovej replikation mellem to, tre og selv flere tusinde noder for at udf\u00f8re replikation og synkronisere filer. Det er et unikt v\u00e6rkt\u00f8j, der selv udf\u00f8rer mange opgaver, s\u00e5som automatisk gendannelse af data efter en l\u00e6ngere nedetid p\u00e5 en node, sikker og effektiv dataudveksling mellem noder via HTTPS, automatisk konfliktstyring baseret p\u00e5 et regels\u00e6t osv. SymmetricDS udf\u00f8rer replikation mellem alle databaser, s\u00e5 det kan anvendes til forskellige scenarier, herunder migration, opgradering, distribution, filtrering og datatransformation p\u00e5 forskellige platforme.<\/p>\n
<\/p>\n
Eksemplet er lavet baseret p\u00e5 den officielle korte vejledning<\/a><\/noindex> om SymmetricDS. I brugerh\u00e5ndbogen<\/a><\/noindex> forskellige begreber relateret til konfiguration af replikation ved hj\u00e6lp af SymmetricDS beskrives i detaljer.<\/p>\n
Kilde: 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\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\udd47Krydsgenerering mellem PostgreSQL og MySQL | ProHoster","description":"Jeg vil kort beskrive.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/perekrestnaya-replikatsiya-mezhdu-postgresql-i-mysql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/38146","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=38146"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38146\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/28635"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=38146"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=38146"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=38146"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}