Kruisreplikasie tussen PostgreSQL en MySQL

Ek sal kortliks praat oor kruisreplikasie tussen PostgreSQL en MySQL, sowel as metodes om kruisreplikasie tussen hierdie twee databasisbedieners op te stel. Daar word gewoonlik na kruisgerepliseerde databasisse verwys as homogene databasisse, en dit is 'n gerieflike metode om van een RDBMS-bediener na 'n ander te migreer.

PostgreSQL- en MySQL-databasisse word tradisioneel as relasioneel beskou, maar met bykomende uitbreidings bied hulle NoSQL-vermoëns. Hier sal ons replikasie tussen PostgreSQL en MySQL bespreek vanuit 'n relasionele databasisbestuursperspektief.

Ons sal nie die hele internals beskryf nie, slegs die basiese beginsels, sodat u 'n idee kry van die opstel van replikasie tussen databasisbedieners, voordele, beperkings en gebruiksgevalle.

Tipies word replikasie tussen twee identiese databasisbedieners óf in binêre modus gedoen óf deur navrae tussen 'n meester (ook bekend as uitgewer, meester of aktief) en 'n slaaf (intekenaar, bystand of passief). Die doel van replikasie is om 'n intydse kopie van die meesterdatabasis aan die bystandkant te verskaf. In hierdie geval word data van meester na slaaf oorgedra, dit wil sê van aktief na passief, omdat replikasie slegs in een rigting uitgevoer word. Maar jy kan replikasie tussen die twee databasisse in beide rigtings opstel, sodat data van die slaaf na die meester oorgedra word in 'n aktief-aktiewe konfigurasie. Dit alles, insluitend kaskade-replikasie, is moontlik tussen twee of meer identiese databasisbedieners. Aktief-aktiewe of aktief-passiewe konfigurasie hang af van die behoefte, die beskikbaarheid van sulke vermoëns in die aanvanklike konfigurasie of die gebruik van eksterne tuning oplossings en bestaande handel -afs.

Die beskryfde konfigurasie is moontlik tussen verskillende databasisbedieners. Die bediener kan gekonfigureer word om gerepliseerde data vanaf 'n ander databasisbediener te ontvang en steeds intydse momentopnames van die gerepliseerde data te behou. MySQL en PostgreSQL bied die meeste van hierdie konfigurasies inheems of deur derdeparty-uitbreidings, insluitend binêre logmetodes, skyfslotte en stelling- en rygebaseerde metodes.

Kruisreplikasie tussen MySQL en PostgreSQL is nodig vir 'n eenmalige migrasie van een databasisbediener na 'n ander. Hierdie databasisse gebruik verskillende protokolle, so jy kan hulle nie direk koppel nie. Om data-uitruiling te vergemaklik, kan jy 'n eksterne oopbronhulpmiddel gebruik, soos pg_chameleon.

Wat is pg_chameleon

pg_chameleon is 'n replikasiestelsel van MySQL na PostgreSQL in Python 3. Dit gebruik die mysql-replikasie oopbronbiblioteek, ook in Python. Rybeelde word van MySQL-tabelle afgehaal en as JSONB-voorwerpe in die PostgreSQL-databasis gestoor, en dan deur die pl/pgsql-funksie gedekodeer en in die PostgreSQL-databasis teruggespeel.

Kenmerke van pg_chameleon

Veelvuldige MySQL-skemas van dieselfde groep kan na 'n enkele PostgreSQL-teikendatabasis gerepliseer word met 'n een-tot-veel-konfigurasie
Die bron- en teikenskemaname kan nie dieselfde wees nie.
Replikasiedata kan van 'n MySQL-watervalreplika herwin word.
Tabelle wat nie kan herhaal of foute kan genereer nie, word uitgesluit.
Elke replikasiefunksie word deur daemone beheer.
Beheer met parameters en konfigurasielêers gebaseer op YAML.

Voorbeeld

Gasheer
vm1
vm2

OS weergawe
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Databasis bediener weergawe
MySQL 5.7.26
10.5 PostgreSQL

DB poort
3306
5433

IP-adres
192.168.56.102
192.168.56.106

Berei eers al die nodige komponente voor vir die installering van pg_chameleon. Hierdie voorbeeld het Python 3.6.8 geïnstalleer, wat 'n virtuele omgewing skep en dit aktiveer.

$> wget https://www.python.org/ftp/python/3.6.8/Python-3.6.8.tar.xz
$> tar -xJf Python-3.6.8.tar.xz
$> cd Python-3.6.8
$> ./configure --enable-optimizations
$> make altinstall

Sodra Python3.6 suksesvol geïnstalleer is, moet die res van die vereistes voltooi word, soos die skep en aktivering van 'n virtuele omgewing. Die pip-module word ook na die nuutste weergawe opgedateer en gebruik om pg_chameleon te installeer. Die opdragte hieronder installeer doelbewus pg_chameleon 2.0.9, al is die nuutste weergawe 2.0.10. Dit is nodig om nuwe foute in die opgedateerde weergawe te vermy.

$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9

Ons noem dan pg_chameleon (chameleon is 'n opdrag) met die set_configuration_files argument om pg_chameleon te aktiveer en die verstek konfigurasie gidse en lêers te skep.

(venv) $> chameleon set_configuration_files
creating directory /root/.pg_chameleon
creating directory /root/.pg_chameleon/configuration/
creating directory /root/.pg_chameleon/logs/
creating directory /root/.pg_chameleon/pid/
copying configuration  example in /root/.pg_chameleon/configuration//config-example.yml

Ons maak nou 'n kopie van config-example.yml as default.yml sodat dit die verstek konfigurasielêer word. 'n Voorbeeld konfigurasielêer vir hierdie voorbeeld word hieronder verskaf.

$> cat default.yml
---
#global settings
pid_dir: '~/.pg_chameleon/pid/'
log_dir: '~/.pg_chameleon/logs/'
log_dest: file
log_level: info
log_days_keep: 10
rollbar_key: ''
rollbar_env: ''

# type_override allows the user to override the default type conversion into a different one.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

#postgres  destination connection
pg_conn:
  host: "192.168.56.106"
  port: "5433"
  user: "usr_replica"
  password: "pass123"
  database: "db_replica"
  charset: "utf8"

sources:
  mysql:
    db_conn:
      host: "192.168.56.102"
      port: "3306"
      user: "usr_replica"
      password: "pass123"
      charset: 'utf8'
      connect_timeout: 10
    schema_mappings:
      world_x: pgworld_x
    limit_tables:
#      - delphis_mediterranea.foo
    skip_tables:
#      - delphis_mediterranea.bar
    grant_select_to:
      - usr_readonly
    lock_timeout: "120s"
    my_server_id: 100
    replica_batch_size: 10000
    replay_max_rows: 10000
    batch_retention: '1 day'
    copy_max_memory: "300M"
    copy_mode: 'file'
    out_dir: /tmp
    sleep_loop: 1
    on_error_replay: continue
    on_error_read: continue
    auto_maintenance: "disabled"
    gtid_enable: No
    type: mysql
    skip_events:
      insert:
        - delphis_mediterranea.foo #skips inserts on the table delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #skips deletes on schema delphis_mediterranea
      update:

Die konfigurasielêer in hierdie voorbeeld is 'n voorbeeld pg_chameleon-lêer met geringe wysigings om by die bron- en teikenomgewings te pas, en hieronder is 'n oorsig van die verskillende afdelings van die konfigurasielêer.

Die default.yml-konfigurasielêer het 'n afdeling van globale instellings (globale instellings) waar jy instellings kan beheer soos die ligging van die slotlêer, die ligging van die logs, die stoortydperk vir die logs, ens. Volgende kom die tipe oorheersing afdeling, waar die stel reëls vir die oorheersing van tipes tydens replikasie. Die verstekvoorbeeld gebruik 'n tipe oorheersingsreël wat tinyint(1) omskakel na 'n boolean. In die volgende afdeling spesifiseer ons die besonderhede van koppeling aan die teikendatabasis. In ons geval is dit 'n PostgreSQL-databasis, aangedui as pg_conn. In die laaste afdeling spesifiseer ons die brondata, dit wil sê die verbindingsparameters van die brondatabasis, die karteringskema van die bron- en teikendatabasisse, tabelle wat oorgeslaan moet word, time-out, geheue, pakketgrootte. Let daarop dat "bronne" meervoud is, wat beteken dat ons veelvuldige brondatabasisse by dieselfde teiken kan voeg om 'n veel-tot-een-konfigurasie op te stel.

Die world_x-databasis in die voorbeeld bevat 4 tabelle met rye wat die MySQL-gemeenskap vir die voorbeeld voorstel. Dit kan afgelaai word hier. Die voorbeelddatabasis kom as 'n teer en saamgeperste argief met instruksies vir die skep en invoer van stringe.

'n Spesiale gebruiker met dieselfde naam usr_replica word in die MySQL- en PostgreSQL-databasisse geskep. MySQL gee dit addisionele leestoegang tot alle gerepliseerde tabelle.

mysql> CREATE USER usr_replica ;
mysql> SET PASSWORD FOR usr_replica='pass123';
mysql> GRANT ALL ON world_x.* TO 'usr_replica';
mysql> GRANT RELOAD ON *.* to 'usr_replica';
mysql> GRANT REPLICATION CLIENT ON *.* to 'usr_replica';
mysql> GRANT REPLICATION SLAVE ON *.* to 'usr_replica';
mysql> FLUSH PRIVILEGES;

Aan die PostgreSQL-kant word 'n db_replica-databasis geskep wat veranderinge vanaf die MySQL-databasis sal aanvaar. Die usr_replica-gebruiker in PostgreSQL word outomaties gekonfigureer as die eienaar van die twee skemas pgworld_x en sch_chameleon, wat onderskeidelik die werklike gerepliseerde tabelle en replikasiekatalogustabelle bevat. Die create_replica_schema argument is verantwoordelik vir outomatiese konfigurasie, soos u hieronder sal sien.

postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASE

Die MySQL-databasis is gekonfigureer met 'n paar veranderinge om dit gereed te maak vir replikasie soos hieronder getoon. Jy sal die databasisbediener moet herbegin vir die veranderinge om in werking te tree.

$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1

Nou is dit belangrik om die verbinding met beide databasisbedieners na te gaan sodat daar geen probleme is wanneer die pg_chameleon-opdragte uitgevoer word nie.

Op die PostgreSQL-knooppunt:

$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x

Op MySQL node:

$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica

Die volgende drie pg_chameleon (chameleon) opdragte berei die omgewing voor, voeg die bron by en inisialiseer die replika. Die create_replica_schema argument na pg_chameleon skep 'n verstek skema (sch_chameleon) en 'n replikasie skema (pgworld_x) in die PostgreSQL databasis, soos ons gesê het. Die add_source-argument voeg 'n brondatabasis by die konfigurasie deur die konfigurasielêer (default.yml) te lees, wat in ons geval mysql is, en init_replica initialiseer die konfigurasie gebaseer op die instellings in die konfigurasielêer.

$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debug

Die uitset van hierdie drie opdragte dui duidelik hul sukses aan. Alle foute of sintaksisfoute word in eenvoudige en verstaanbare boodskappe aangedui met wenke oor hoe om probleme op te los.

Uiteindelik begin ons replikasie met start_replica en kry 'n suksesboodskap.

$> chameleon start_replica --config default --source mysql 
output: Starting the replica process for source mysql

Replikasiestatus kan navraag gedoen word met die show_status-argument, en foute kan met die show_errors-argument bekyk word.

Die resultaat.

Soos ons reeds gesê het, bestuur daemone elke replikasiefunksie. Om dit te sien, vra die prosestabel met die Linux ps-opdrag, soos hieronder getoon.

Die resultaat.

Replikasie word nie as gekonfigureer beskou nie totdat ons dit intyds toets, soos hieronder getoon. Ons skep 'n tabel, voeg 'n paar rekords in die MySQL-databasis in, en roep die sync_tables-argument in pg_chameleon om die daemone op te dateer en die tabel met die rekords na die PostgreSQL-databasis te repliseer.

mysql> create table t1 (n1 int primary key, n2 varchar(10));
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t1 values (1,'one');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values (2,'two');
Query OK, 1 row affected (0.00 sec)

$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Sync tables process for source mysql started.

Om die toetsresultate te bekragtig, vra ons die tabel uit die PostgreSQL-databasis en voer die rye uit.

$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
 n1 |  n2
----+-------
  1 | one
  2 | two

As ons migreer, sal die volgende pg_chameleon-opdragte die einde van die migrasie wees. Die opdragte moet uitgevoer word nadat ons geverifieer het dat die rye van alle teikentabelle gerepliseer is, wat lei tot 'n netjies gemigreerde PostgreSQL-databasis met geen verwysings na die brondatabasis of replikasieskema (sch_chameleon).

$> chameleon stop_replica --config default --source mysql 
$> chameleon detach_replica --config default --source mysql --debug

U kan opsioneel die oorspronklike konfigurasie en replikasieskema uitvee met die volgende opdragte.

$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debug

Voordele van pg_chameleon

Maklike opstelling en konfigurasie.
Gerieflike foutopsporing en anomalie-opsporing met duidelike foutboodskappe.
Bykomende spesiale tabelle kan na inisialisering by replikasie gevoeg word sonder om die res van die konfigurasie te verander.
Dit is moontlik om verskeie brondatabasisse vir een teikendatabasis op te stel, en dit is baie handig as jy data van een of meer MySQL-databasisse saamvoeg in een PostgreSQL-databasis.
Jy kan kies om nie geselekteerde tabelle te herhaal nie.

Nadele van pg_chameleon

Word slegs ondersteun met MySQL 5.5 en hoër as die bron en PostgreSQL 9.5 en hoër as die teikendatabasis.
Elke tabel moet 'n primêre of unieke sleutel hê, anders word die tabelle in die init_replica-proses geïnisialiseer, maar nie gerepliseer nie.
Eenrigtingreplikasie - slegs van MySQL na PostgreSQL. Daarom is dit slegs geskik vir die aktief-passiewe skema.
Die bron kan slegs 'n MySQL-databasis wees, en ondersteuning vir 'n PostgreSQL-databasis as 'n bron is slegs eksperimenteel en beperk (kom meer te wete hier)

Totale vir pg_chameleon

Die replikasiemetode in pg_chameleon is ideaal om 'n databasis van MySQL na PostgreSQL te migreer. Die groot nadeel is dat replikasie net eenrigting is, dus is dit onwaarskynlik dat databasisprofessionele dit vir enigiets anders as migrasie wil gebruik. Maar die probleem van eenrigtingreplikasie kan opgelos word met 'n ander oopbron-instrument - SymmetricDS.

Lees meer in die amptelike dokumentasie hier. Opdragreëlhulp kan gevind word hier.

Oorsig van SymmetricDS

SymmetricDS is 'n oopbronhulpmiddel wat enige databasis na enige ander algemene databasis repliseer: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird en ander wolkdatabasisgevalle, byvoorbeeld Redshift, en Azure, ens. Beskikbare kenmerke: databasis- en lêersinchronisasie, multi-meester databasisreplikasie, gefiltreerde sinchronisasie, transformasie, en ander. Dit is 'n Java-instrument en vereis die standaardvrystelling JRE of JDK (weergawe 8.0 of hoër). Hier kan u dataveranderings op snellers in die brondatabasis aanteken en dit as bondels na die ooreenstemmende teikendatabasis stuur.

Simmetriese DS-vermoëns

Die instrument is platformonafhanklik, wat beteken dat twee of meer verskillende databasisse data kan uitruil.
Relasionele databasisse word gesinchroniseer deur dataveranderings aan te teken, en databasisse gebaseer op lêerstelsels gebruik lêersinchronisasie.
Tweerigtingreplikasie met behulp van druk- en trekmetodes gebaseer op 'n stel reëls.
Data-oordrag is moontlik oor veilige netwerke en netwerke met lae bandwydte.
Outomatiese herstel wanneer nodusse hervat na 'n mislukking en outomatiese konflikoplossing.
Wolkversoenbare en doeltreffende uitbreidings-API's.

Voorbeeld

SymmetricDS kan op een van twee maniere gekonfigureer word:
'n Meester (ouer) nodus wat data-replikasie tussen twee slawe (kind) nodusse sentraal koördineer, en data-uitruiling tussen kind nodusse word slegs deur die ouer uitgevoer.
'n Aktiewe nodus (knooppunt 1) kan sonder 'n tussenganger met 'n ander aktiewe nodus (knooppunt 2) vir replikasie kommunikeer.

In beide opsies vind data-uitruiling plaas met Push en Pull. In hierdie voorbeeld sal ons die aktief-aktiewe konfigurasie oorweeg. Dit is te lank om die hele argitektuur te beskryf, so bestudeer leierskapom meer te wete te kom oor die SymmetricDS-toestel.

Die installering van SymmetricDS is maklik: laai die oopbron-zip-lêer af vandaar en haal dit uit waar jy wil. Die volgende tabel lys die installasieligging en weergawe van SymmetricDS in hierdie voorbeeld, sowel as databasisweergawes, Linux-weergawes, IP-adresse en poorte vir beide nodusse.

Gasheer
vm1
vm2

OS weergawe
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Databasis bediener weergawe
MySQL 5.7.26
10.5 PostgreSQL

DB poort
3306
5832

IP-adres
192.168.1.107
192.168.1.112

SimmetrieseDS weergawe
SimmetrieseDS 3.9
SimmetrieseDS 3.9

SymmetricDS installasie pad
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

SymmetricDS gasheernaam
korp-000
winkel-001

Hier installeer ons SymmetricDS in /usr/local/symmetric-server-3.9.20 en verskeie subgidse en lêers sal daar gestoor word. Ons is geïnteresseerd in die subgidse monsters en enjins. Die voorbeeldgids bevat voorbeeldkonfigurasielêers met noduseienskappe, sowel as voorbeeld SQL-skrifte om die demonstrasie vinnig te begin.

In die voorbeeldgids sien ons drie konfigurasielêers met noduseienskappe - die naam toon die aard van die nodus in 'n spesifieke skema.

corp-000.properties
store-001.properties
store-002.properties

SymmetricDS het al die nodige konfigurasielêers vir 'n basiese 3 node skema (opsie 1) en dieselfde lêers kan gebruik word vir 'n 2 node skema (opsie 2). Kopieer die vereiste konfigurasielêer van die voorbeeldgids na enjins op die vm1-gasheer. Dit blyk so uit:

$> cat engines/corp-000.properties
engine.name=corp-000
db.driver=com.mysql.jdbc.Driver
db.url=jdbc:mysql://192.168.1.107:3306/replica_db?autoReconnect=true&useSSL=false
db.user=root
db.password=admin123
registration.url=
sync.url=http://192.168.1.107:31415/sync/corp-000
group.id=corp
external.id=000

Hierdie nodus word corp-000 genoem in die SymmetricDS-konfigurasie en die databasisverbinding word deur die mysql jdbc-bestuurder hanteer wat die verbindingstring hierbo en aanmeldbewyse gebruik. Ons koppel aan die replica_db-databasis en tabelle sal tydens die skepping van die skema geskep word. sync.url wys die skakel na die nodus om te sinchroniseer.

Node 2 op gasheer vm2 is opgestel as winkel-001 en die res word gespesifiseer in die node.properties lêer hieronder. Die winkel-001-nodus bestuur die PostgreSQL-databasis, en pgdb_replica is die databasis om te repliseer. registration.url laat vm2 gasheer toe om vm1 gasheer te kontak en konfigurasie besonderhede daaruit te kry.

$> cat engines/store-001.properties
engine.name=store-001
db.driver=org.postgresql.Driver
db.url=jdbc:postgresql://192.168.1.112:5832/pgdb_replica
db.user=postgres
db.password=admin123
registration.url=http://192.168.1.107:31415/sync/corp-000
group.id=store
external.id=001

Die voltooide SymmetricDS-voorbeeld bevat opsies vir die opstel van tweerigtingreplikasie tussen twee databasisbedieners (twee nodusse). Die stappe hieronder word uitgevoer op gasheer vm1 (corp-000) wat 'n voorbeeldskema met 4 tabelle sal skep. Die uitvoering van create-sym-tables met die symadmin-opdrag skep dan gidstabelle waar die reëls en rigting van replikasie tussen nodusse gestoor sal word. Laastens word die voorbeelddata in die tabelle gelaai.

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> ./dbimport --engine corp-000 --format XML create_sample.xml
vm1$> ./symadmin --engine corp-000 create-sym-tables
vm1$> ./dbimport --engine corp-000 insert_sample.sql

In die voorbeeld word die item- en item_selling_price-tabelle outomaties gekonfigureer om van corp-000 na winkel-001 te repliseer, en die verkooptabelle (sale_transaction en sale_return_line_item) word outomaties gekonfigureer om van winkel-001 na corp-000 te repliseer. Ons skep nou 'n skema in die PostgreSQL-databasis op gasheer vm2 (store-001) om dit voor te berei om data van corp-000 te ontvang.

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xml

Maak seker dat u seker maak dat die MySQL-databasis op vm1 voorbeeldtabelle en 'n SymmetricDS-katalogustabel het. Let daarop dat die SymmetricDS-stelseltabelle (met die sym_-voorvoegsel) tans slegs op die corp-000-nodus beskikbaar is, want dit is waar ons die create-sym-tables-opdrag uitgevoer het en replikasie sal bestuur. En in die databasis by die winkel-001 nodus sal daar slegs 4 voorbeeldtabelle sonder data wees.

Almal. Die omgewing is gereed om sim-bedienerprosesse op beide nodusse uit te voer, soos hieronder getoon.

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &

Loginskrywings word gestuur na die agtergrondloglêer (symmetric.log) in die loglêergids in die gids waar SymmetricDS geïnstalleer is, sowel as na die standaarduitvoer. Die sim-bediener kan nou op die winkel-001-nodus geïnisieer word.

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &

As jy die sim-bedienerproses op die vm2-gasheer laat loop, sal dit ook die SymmetricDS-katalogustabelle in die PostgreSQL-databasis skep. As jy die sim-bedienerproses op beide nodusse laat loop, sal hulle met mekaar koördineer om data van corp-000 na winkel-001 te repliseer. As ons na 'n paar sekondes al 4 tabelle aan beide kante bevraagteken, sal ons sien dat die replikasie suksesvol was. Of jy kan die bootstrap na store-001 stuur vanaf corp-000 met die volgende opdrag.

vm1$> ./symadmin --engine corp-000 reload-node 001

Op hierdie stadium word 'n nuwe rekord in die itemtabel in die MySQL-databasis op node corp-000 (gasheer: vm1) ingevoeg en kan nagegaan word vir replikasie na die PostgreSQL-databasis op node store-001 (gasheer: vm2). Ons sien 'n Pull-operasie om data van corp-000 na winkel-001 te skuif.

mysql> insert into item values ('22000002','Jelly Bean');
Query OK, 1 row affected (0.00 sec)

vm2$> psql -p 5832 -U postgres pgdb_replica -c "select * from item"
 item_id  |   name
----------+-----------
 11000001 | Yummy Gum
 22000002 | Jelly Bean
(2 rows)

Om 'n stootbewerking uit te voer om data van winkel-001 na corp-000 te skuif, voeg ons 'n rekord in die sale_transaction-tabel in en verifieer dat replikasie voltooi is.

Die resultaat.

Ons sien 'n suksesvolle opstelling van tweerigting-replikasie van die voorbeeldtabelle tussen die MySQL- en PostgreSQL-databasisse. Voer die volgende stappe uit om replikasie vir nuwe gebruikerstabelle op te stel. Ons skep byvoorbeeld tabel t1 en stel sy replikasiereëls soos volg op. Ons stel dus slegs replikasie van corp-000 na winkel-001 op.

mysql> create table  t1 (no integer);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into sym_channel (channel_id,create_time,last_update_time) 
values ('t1',current_timestamp,current_timestamp);
Query OK, 1 row affected (0.01 sec)

mysql> insert into sym_trigger (trigger_id, source_table_name,channel_id,
last_update_time, create_time) values ('t1', 't1', 't1', current_timestamp,
current_timestamp);
Query OK, 1 row affected (0.01 sec)

mysql> insert into sym_trigger_router (trigger_id, router_id,
Initial_load_order, create_time,last_update_time) values ('t1',
'corp-2-store-1', 1, current_timestamp,current_timestamp);
Query OK, 1 row affected (0.01 sec)

Die konfigurasie word dan in kennis gestel van die skemaverandering, dit wil sê die byvoeging van 'n nuwe tabel, deur die simadmin-opdrag te gebruik met die sinc-triggers-argument, wat die snellers herskep om by die tabeldefinisies te pas. Send-skema word uitgevoer om skemaveranderings na winkel-001 te stuur, en tabel t1 word gerepliseer.

vm1$> ./symadmin -e corp-000 --node=001 sync-triggers    
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1

Voordele van SymmetricDS

Maklike installasie en konfigurasie, insluitend 'n klaargemaakte stel lêers met parameters vir die skep van 'n skema met drie of twee nodusse.
Cross-platform databasisse en platform onafhanklikheid, insluitend bedieners, skootrekenaars en mobiele toestelle.
Repliseer enige databasis na enige ander databasis plaaslik, op die WAN of in die wolk.
Vermoë om optimaal te werk met 'n paar databasisse of 'n paar duisend vir maklike replikasie.
Betaalde weergawe met GUI en uitstekende ondersteuning.

Nadele van SymmetricDS

U moet die reëls en rigting van replikasie op die opdragreël handmatig definieer via SQL-stellings om die katalogustabelle te laai, wat ongerieflik kan wees.
Die opstel van baie tabelle vir replikasie kan vervelig wees, tensy jy skrifte gebruik om SQL-stellings te skep wat die reëls en rigting van replikasie definieer.
Daar is te veel inligting in die logs, en soms moet jy die loglêer skoonmaak sodat dit nie te veel spasie opneem nie.

Opsomming van SimmetrieseDS

SymmetricDS laat jou toe om tweerigtingreplikasie tussen twee, drie of selfs 'n paar duisend nodusse op te stel om lêers te repliseer en te sinchroniseer. Dit is 'n unieke hulpmiddel wat baie take op sy eie verrig, soos outomatiese herstel van data na 'n lang stilstand op 'n nodus, veilige en doeltreffende kommunikasie tussen nodusse oor HTTPS, outomatiese konflikbestuur gebaseer op 'n stel reëls, ens. SymmetricDS repliseer tussen enige databasisse kan dit dus vir 'n wye verskeidenheid scenario's gebruik word, insluitend migrasie, opgradering, verspreiding, filtering en datatransformasie oor platforms heen.

Die voorbeeld is gebaseer op die amptenaar vinnige gids deur SymmetricDS. IN gebruikers gids Beskryf in detail die verskillende konsepte betrokke by die opstel van replikasie met SymmetricDS.

Bron: will.com