Replikimi i kryqëzuar midis PostgreSQL dhe MySQL

Unë do të përshkruaj replikimin e kryqëzuar midis PostgreSQL dhe MySQL, si dhe metodat për vendosjen e riprodhimit të kryqëzuar midis dy serverëve të bazës së të dhënave. Në mënyrë tipike, bazat e të dhënave të përsëritura të kryqëzuara quhen homogjene dhe është një metodë e përshtatshme për të lëvizur nga një server RDBMS në tjetrin.

Bazat e të dhënave PostgreSQL dhe MySQL përgjithësisht konsiderohen relacionale, por me shtesa shtesë ato ofrojnë aftësi NoSQL. Këtu do të diskutojmë përsëritjen midis PostgreSQL dhe MySQL nga një këndvështrim relacional i DBMS.

Ne nuk do të përshkruajmë të gjithë funksionimin e brendshëm, vetëm parimet bazë në mënyrë që të merrni një ide të konfigurimit të riprodhimit midis serverëve të bazës së të dhënave, avantazheve, kufizimeve dhe rasteve të përdorimit.

Në mënyrë tipike, riprodhimi ndërmjet dy serverëve identikë të bazës së të dhënave bëhet ose në modalitetin binar ose duke përdorur pyetje midis një masteri (a.k.a. botuesi, masteri ose aktiv) dhe një skllav (pabonues, gatishmëri ose pasiv). Qëllimi i përsëritjes është të sigurojë një kopje në kohë reale të bazës së të dhënave kryesore në anën skllav. Në këtë rast, të dhënat transferohen nga master në slave, pra nga aktiv në pasiv, sepse replikimi kryhet vetëm në një drejtim. Por ju mund të konfiguroni përsëritjen midis dy bazave të të dhënave në të dy drejtimet, në mënyrë që të dhënat të transferohen nga skllav në master në një konfigurim aktiv-aktive. E gjithë kjo, duke përfshirë replikimin kaskadë, është e mundur midis dy ose më shumë serverëve identikë të bazës së të dhënave. Konfigurimi aktiv-aktiv ose aktiv-pasiv varet nga nevoja, disponueshmëria e aftësive të tilla në konfigurimin fillestar ose përdorimi i zgjidhjeve të konfigurimit të jashtëm dhe shkëmbimet ekzistuese.

Konfigurimi i përshkruar është i mundur midis serverëve të ndryshëm të bazës së të dhënave. Serveri mund të konfigurohet që të pranojë të dhëna të përsëritura nga një server tjetër i bazës së të dhënave dhe të ruajë ende fotografi në kohë reale të të dhënave të përsëritura. MySQL dhe PostgreSQL ofrojnë shumicën e këtyre konfigurimeve brenda ose përmes shtesave të palëve të treta, duke përfshirë metodat e regjistrit binar, mbylljen e diskut dhe metodat e bazuara në deklarata dhe rreshta.

Replikimi i kryqëzuar midis MySQL dhe PostgreSQL nevojitet për një migrim një herë nga një server i bazës së të dhënave në tjetrin. Këto baza të të dhënave përdorin protokolle të ndryshme, kështu që nuk është e mundur të lidhen drejtpërdrejt. Për të vendosur shkëmbimin e të dhënave, mund të përdorni një mjet të jashtëm me burim të hapur, për shembull pg_chameleon.

Çfarë është pg_kameleon

pg_chameleon është një sistem replikimi nga MySQL në PostgreSQL në Python 3. Ai përdor bibliotekën me burim të hapur mysql-replication, gjithashtu në Python. Imazhet e rreshtave nxirren nga tabelat MySQL dhe ruhen si objekte JSONB në bazën e të dhënave PostgreSQL, dhe më pas deshifrohen nga funksioni pl/pgsql dhe riprodhohen në bazën e të dhënave PostgreSQL.

Karakteristikat e pg_kameleon

Skema të shumta MySQL nga i njëjti grup mund të përsëriten në një objektiv të vetëm të bazës së të dhënave PostgreSQL në një konfigurim një-në-shumë
Emrat e skemës së burimit dhe objektivit nuk mund të jenë të njëjtë.
Të dhënat e riprodhimit mund të merren nga një kopje e kaskadës së MySQL.
Tabelat që nuk mund të përsëriten ose të prodhojnë gabime janë të përjashtuara.
Çdo funksion replikimi kontrollohet nga demonët.
Kontrolloni nëpërmjet parametrave të bazuar në YAML dhe skedarëve të konfigurimit.

Shembull

mikpritës
vm1
vm2

Versioni i OS
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Versioni i serverit DB
MySQL 5.7.26
PostgreSQL 10.5

Porta DB
3306
5433

IP adresa
192.168.56.102
192.168.56.106

Për të filluar, përgatitni të gjithë komponentët e nevojshëm për të instaluar pg_chameleon. Ky shembull instalon Python 3.6.8, i cili krijon dhe aktivizon mjedisin virtual.

$> 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

Pas instalimit të suksesshëm të Python3.6, duhet të plotësoni kërkesat e mbetura, si krijimi dhe aktivizimi i një mjedisi virtual. Për më tepër, moduli pip përditësohet në versionin më të fundit dhe përdoret për të instaluar pg_chameleon. Komandat e mëposhtme instalojnë qëllimisht pg_chameleon 2.0.9, megjithëse versioni i fundit është 2.0.10. Kjo është e nevojshme për të shmangur gabimet e reja në versionin e përditësuar.

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

Më pas thërrasim pg_chameleon (kameleoni është një komandë) me argumentin set_configuration_files për të aktivizuar pg_chameleon dhe për të krijuar drejtoritë e paracaktuar dhe skedarët e konfigurimit.

(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

Tani krijojmë një kopje të config-example.yml si default.yml në mënyrë që të bëhet skedari i konfigurimit të paracaktuar. Një skedar konfigurimi mostër për këtë shembull është dhënë më poshtë.

$> 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:

Skedari i konfigurimit në këtë shembull është një skedar shembull pg_chameleon me modifikime të vogla për t'iu përshtatur mjediseve burimore dhe objektive, dhe më poshtë është një pasqyrë e seksioneve të ndryshme të skedarit të konfigurimit.

Në skedarin e konfigurimit default.yml ekziston një seksion i cilësimeve globale, ku mund të menaxhoni cilësime të tilla si vendndodhjen e skedarit të kyçjes, vendndodhjen e regjistrave, periudhën e ruajtjes për regjistrat, etj. Më pas vjen seksioni i tejkalimit të tipit, ku një grup rregullash për tejkalimin e llojeve gjatë replikimit. Shembulli është i paracaktuar për një rregull mbizotërues të tipit që konverton tinyint(1) në një vlerë boolean. Në seksionin tjetër, ne specifikojmë detajet e lidhjes me bazën e të dhënave të synuar. Në rastin tonë, kjo është një bazë të dhënash PostgreSQL, e caktuar pg_conn. Në seksionin e fundit, ne tregojmë të dhënat e burimit, domethënë parametrat e lidhjes së bazës së të dhënave burimore, skemën e hartës midis bazave të të dhënave të burimit dhe objektivit, tabelat që duhet të anashkalohen, kohën e pritjes, kujtesën, madhësinë e paketës. Vini re se "burimet" është shumës, që do të thotë se ne mund të shtojmë baza të dhënash të shumëfishta burimesh në një bazë të dhënash të vetme objektive për të vendosur një konfigurim shumë-për-një.

Shembulli i bazës së të dhënave world_x përmban 4 tabela me rreshta që komuniteti MySQL ofron si shembuj. Mund të shkarkohet këtu. Baza e të dhënave të mostrës vjen si një arkiv tar dhe i ngjeshur me udhëzime për krijimin dhe importimin e rreshtave.

Në bazat e të dhënave MySQL dhe PostgreSQL, krijohet një përdorues i veçantë me të njëjtin emër usr_replica. Në MySQL, i jepen të drejta shtesë leximi për të gjitha tabelat e përsëritura.

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;

Në anën PostgreSQL, krijohet një bazë të dhënash db_replica që do të pranojë ndryshime nga baza e të dhënave MySQL. Përdoruesi usr_replica në PostgreSQL konfigurohet automatikisht si pronar i dy skemave, pgworld_x dhe sch_chameleon, të cilat përmbajnë përkatësisht tabelat e përsëritura aktuale dhe tabelat e drejtorisë së replikimit. Argumenti create_replica_schema është përgjegjës për konfigurimin automatik, siç do ta shihni më poshtë.

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

Baza e të dhënave MySQL është konfiguruar me disa ndryshime parametrash për ta përgatitur atë për riprodhim siç tregohet më poshtë. Ju do të duhet të rinisni serverin e bazës së të dhënave që ndryshimet të hyjnë në fuqi.

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

Tani është e rëndësishme të kontrolloni lidhjen me të dy serverët e bazës së të dhënave në mënyrë që të mos ketë probleme gjatë ekzekutimit të komandave pg_chameleon.

Në nyjen PostgreSQL:

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

Në nyjen MySQL:

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

Tre komandat e ardhshme pg_chameleon (kameleon) përgatisin mjedisin, shtojnë burimin dhe inicializojnë replikën. Argumenti create_replica_schema te pg_chameleon krijon një skemë të paracaktuar (sch_chameleon) dhe një skemë riprodhimi (pgworld_x) në bazën e të dhënave PostgreSQL, siç kemi diskutuar tashmë. Argumenti add_source shton një bazë të dhënash burimore në konfigurim duke lexuar skedarin e konfigurimit (default.yml), dhe në rastin tonë është mysql, dhe init_replica inicializon konfigurimin bazuar në parametrat në skedarin e konfigurimit.

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

Dalja e këtyre tre komandave tregon qartë se ato janë ekzekutuar me sukses. Çdo përplasje ose gabim sintaksor raportohet në mesazhe të thjeshta dhe të qarta me sugjerime se si të rregullohet problemi.

Më në fund, ne fillojmë replikimin duke përdorur start_replica dhe marrim një mesazh suksesi.

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

Statusi i replikimit mund të kërkohet duke përdorur argumentin show_status dhe gabimet mund të shihen duke përdorur argumentin show_errors.

Result.

Siç kemi thënë tashmë, çdo funksion replikimi kontrollohet nga demonët. Për t'i parë ato, ne kërkojmë tabelën e procesit me komandën Linux ps, siç tregohet më poshtë.

Result.

Replikimi nuk konsiderohet i konfiguruar derisa ta testojmë në kohë reale, siç tregohet më poshtë. Ne krijojmë një tabelë, futim disa regjistrime në bazën e të dhënave MySQL dhe thërrasim argumentin sync_tables në pg_chameleon për të përditësuar demonët dhe për të replikuar tabelën me të dhënat në bazën e të dhënave PostgreSQL.

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.

Për të konfirmuar rezultatet e testit, ne kërkojmë tabelën nga baza e të dhënave PostgreSQL dhe nxjerrim rreshtat.

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

Nëse po bëjmë një migrim, komandat e mëposhtme pg_chameleon do të jenë fundi i tij. Komandat duhet të ekzekutohen pasi të jemi të sigurt se rreshtat e të gjitha tabelave të synuara janë përsëritur dhe rezultati do të jetë një bazë e të dhënave PostgreSQL e migruar mjeshtërisht pa referenca në bazën e të dhënave burimore ose skemën e riprodhimit (sch_chameleon).

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

Nëse dëshironi, mund të përdorni komandat e mëposhtme për të fshirë skemën origjinale të konfigurimit dhe replikimit.

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

Përparësitë e pg_kameleon

Konfigurim dhe konfigurim i lehtë.
Zgjidheni lehtësisht dhe identifikoni anomalitë me mesazhe të qarta gabimi.
Tabelat speciale shtesë mund t'i shtohen replikimit pas inicializimit pa ndryshuar pjesën tjetër të konfigurimit.
Është e mundur të konfiguroni bazat e të dhënave të shumëfishta burimore për një bazë të dhënash të vetme objektiv, dhe kjo është shumë e dobishme nëse jeni duke kombinuar të dhëna nga një ose më shumë baza të dhënash MySQL në një bazë të dhënash të vetme PostgreSQL.
Ju nuk keni nevojë të përsërisni tabelat e zgjedhura.

Disavantazhet e pg_kameleon

Mbështetet vetëm me MySQL 5.5 e lart si burim dhe PostgreSQL 9.5 e lart si bazë të dhënash të synuar.
Çdo tabelë duhet të ketë një çelës primar ose unik, përndryshe tabelat inicializohen gjatë procesit init_replica por nuk përsëriten.
Replikimi me një drejtim - vetëm nga MySQL në PostgreSQL. Prandaj, është i përshtatshëm vetëm për qarkun "aktiv-pasiv".
Burimi mund të jetë vetëm një bazë të dhënash MySQL dhe mbështetja për një bazë të dhënash PostgreSQL si burim është vetëm eksperimentale dhe me kufizime (mësoni më shumë këtu)

Rezultatet për pg_kameleon

Metoda e riprodhimit në pg_chameleon është e shkëlqyeshme për të migruar një bazë të dhënash nga MySQL në PostgreSQL. Dobësitë e rëndësishme është se përsëritja është vetëm njëkahëshe, kështu që profesionistët e bazës së të dhënave nuk kanë gjasa të dëshirojnë ta përdorin atë për ndonjë gjë tjetër përveç migrimit. Por problemi i përsëritjes në një drejtim mund të zgjidhet me një mjet tjetër me burim të hapur - SymmetricDS.

Lexoni më shumë në dokumentacionin zyrtar këtu. Ndihma e linjës së komandës mund të gjendet këtu.

Pasqyrë e SymmetricDS

SymmetricDS është një mjet me burim të hapur që përsërit çdo bazë të dhënash në çdo bazë të dhënash tjetër të zakonshme: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird dhe shembuj të tjerë të bazës së të dhënave cloud, p.sh. Redshift, dhe Azure, etj. Karakteristikat e disponueshme: sinkronizimi i bazës së të dhënave dhe skedarëve, riprodhimi i bazës së të dhënave me shumë master, sinkronizimi i filtruar, transformimi dhe të tjera. Ky është një mjet Java dhe kërkon një lëshim standard të JRE ose JDK (versioni 8.0 ose më i lartë). Këtu, ndryshimet e të dhënave për shkaktarët në bazën e të dhënave burimore mund të regjistrohen dhe dërgohen në bazën e të dhënave të duhur të synuar në formën e grupeve.

Karakteristikat e SymmetricDS

Mjeti është i pavarur nga platforma, që do të thotë se dy ose më shumë baza të dhënash të ndryshme mund të shkëmbejnë të dhëna.
Bazat e të dhënave relacionale sinkronizohen duke përdorur të dhënat e ndryshimit të të dhënave, ndërsa bazat e të dhënave të bazuara në sistemin e skedarëve përdorin sinkronizimin e skedarëve.
Replikimi i dyanshëm duke përdorur metodat Push dhe Pull bazuar në një grup rregullash.
Transferimi i të dhënave është i mundur përmes rrjeteve të sigurta dhe me gjerësi të ulët.
Rikuperimi automatik kur nyjet rifillojnë funksionimin pas një dështimi dhe zgjidhja automatike e konfliktit.
API shtesë të përputhshme dhe të fuqishme me renë kompjuterike.

Shembull

SymmetricDS mund të konfigurohet në një nga dy mënyrat:
Një nyje master (prind) që koordinon në mënyrë qendrore riprodhimin e të dhënave midis dy nyjeve skllav (fëmijë) dhe komunikimi midis nyjeve fëmijë ndodh vetëm përmes prindit.
Një nyje aktive (Nyja 1) mund të komunikojë për replikim me një nyje tjetër aktive (Nyja 2) pa një ndërmjetës.

Në të dyja opsionet, shkëmbimi i të dhënave ndodh duke përdorur Push dhe Pull. Në këtë shembull do të shqyrtojmë një konfigurim aktiv-aktive. Do të duhej shumë kohë për të përshkruar të gjithë arkitekturën, kështu që bëni kërkimin tuaj. udhëheqjapër të mësuar më shumë rreth pajisjes SymmetricDS.

Instalimi i SymmetricDS është shumë i thjeshtë: shkarkoni versionin me burim të hapur të skedarit zip prandaj dhe nxirre ku te duash. Tabela më poshtë ofron informacione rreth vendndodhjes së instalimit dhe versionit të SymmetricDS në këtë shembull, si dhe versionet e bazës së të dhënave, versionet Linux, adresat IP dhe portat për të dy nyjet.

mikpritës
vm1
vm2

Versioni i OS
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Versioni i serverit DB
MySQL 5.7.26
PostgreSQL 10.5

Porta DB
3306
5832

IP adresa
192.168.1.107
192.168.1.112

Versioni SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9

Rruga e instalimit SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

Emri i nyjës SymmetricDS
korp-000
dyqan-001

Këtu ne instalojmë SymmetricDS në /usr/local/symmetric-server-3.9.20 dhe aty do të ruhen nëndrejtori dhe skedarë të ndryshëm. Ne jemi të interesuar në nëndrejtoritë e mostrave dhe motorëve. Drejtoria e mostrave përmban skedarë të konfigurimit të shembujve me vetitë e nyjeve, si dhe shembuj të skripteve SQL për të filluar shpejt.

Në drejtorinë e mostrave shohim tre skedarë konfigurimi me vetitë e nyjeve - emri tregon natyrën e nyjes në një skemë të caktuar.

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

SymmetricDS ka të gjithë skedarët e nevojshëm të konfigurimit për një dizajn bazë me 3 nyje (opsioni 1), dhe të njëjtat skedarë mund të përdoren për një dizajn me 2 nyje (opsioni 2). Kopjoni skedarin e kërkuar të konfigurimit nga drejtoria e mostrave në motorët në hostin vm1. Rezulton kështu:

$> 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

Kjo nyje në konfigurimin SymmetricDS quhet corp-000 dhe lidhja e bazës së të dhënave trajtohet nga drejtuesi mysql jdbc, i cili përdor vargun e lidhjes më sipër dhe kredencialet e hyrjes. Ne lidhemi me bazën e të dhënave replica_db dhe tabelat do të krijohen gjatë krijimit të skemës. sync.url tregon se ku duhet kontaktuar nyja për sinkronizim.

Nyja 2 në host vm2 është konfiguruar si store-001 dhe pjesa tjetër është specifikuar në skedarin node.properties më poshtë. Node store-001 drejton bazën e të dhënave PostgreSQL dhe pgdb_replica është baza e të dhënave të riprodhimit. register.url lejon host vm2 të kontaktojë hostin vm1 dhe të marrë detajet e konfigurimit prej tij.

$> 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

Shembulli i përfunduar SymmetricDS përmban parametra për vendosjen e riprodhimit të dyanshëm midis dy serverëve të bazës së të dhënave (dy nyje). Hapat e mëposhtëm kryhen në host vm1 (corp-000), i cili do të krijojë një skemë shembulli me 4 tabela. Më pas ekzekutimi i create-sym-tables me komandën symadmin krijon tabela direktorie ku do të ruhen rregullat dhe drejtimi i replikimit ndërmjet nyjeve. Më në fund, të dhënat e mostrës ngarkohen në tabela.

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

Në shembull, tabelat e artikullit dhe item_selling_price konfigurohen automatikisht për t'u përsëritur nga corp-000 në store-001, dhe tabelat e shitjes (sale_transaction dhe sale_return_line_item) konfigurohen automatikisht për t'u përsëritur nga dyqani-001 në corp-000. Tani krijojmë një skemë në bazën e të dhënave PostgreSQL në host vm2 (store-001) për ta përgatitur atë për të marrë të dhëna nga corp-000.

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

Sigurohuni që të kontrolloni që baza e të dhënave MySQL në vm1 të ketë tabela shembuj dhe tabela të katalogut SymmetricDS. Vini re se tabelat e sistemit SymmetricDS (të parashtesuara me sym_) janë aktualisht të disponueshme vetëm në nyjen corp-000 sepse aty kemi ekzekutuar komandën create-sym-tables dhe do të menaxhojmë replikimin. Dhe në bazën e të dhënave në node store-001 do të ketë vetëm 4 tabela shembull pa të dhëna.

Të gjitha. Mjedisi është gati për të ekzekutuar proceset e serverit Sym në të dy nyjet siç tregohet më poshtë.

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

Regjistrimet e regjistrit dërgohen në një skedar të regjistrit të sfondit (symmetric.log) në dosjen e regjistrave në drejtorinë ku është instaluar SymmetricDS, si dhe në daljen standarde. Serveri Sym tani mund të inicohet në node store-001.

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

Nëse ekzekutoni procesin e serverit sym në hostin vm2, ai gjithashtu do të krijojë tabela të katalogut SymmetricDS në bazën e të dhënave PostgreSQL. Nëse ekzekutoni procesin e serverit Sym në të dy nyjet, ato koordinohen me njëri-tjetrin për të replikuar të dhënat nga corp-000 në store-001. Nëse pas disa sekondash kërkojmë të gjitha 4 tabelat në të dyja anët, do të shohim që përsëritja ishte e suksesshme. Ose mund të dërgoni bootstrap në node store-001 nga corp-000 me komandën e mëposhtme.

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

Në këtë pikë, një rekord i ri futet në tabelën e artikujve në bazën e të dhënave MySQL në node corp-000 (host: vm1), dhe mund të kontrolloni përsëritjen e tij në bazën e të dhënave PostgreSQL në node store-001 (host: vm2). Ne shohim një operacion Pull për të lëvizur të dhënat nga corp-000 në store-001.

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)

Për të kryer një operacion Push për të lëvizur të dhënat nga dyqani-001 në corp-000, ne futim një rekord në tabelën sale_transaction dhe verifikojmë që përsëritja është e suksesshme.

Result.

Ne shohim konfigurimin e suksesshëm të përsëritjes së dyanshme të tabelave të shembujve midis bazave të të dhënave MySQL dhe PostgreSQL. Për të konfiguruar përsëritjen për tabelat e përdoruesve të rinj, ndiqni këto hapa: Ne krijojmë tabelën t1 për shembull dhe konfigurojmë rregullat e riprodhimit të saj si më poshtë. Në këtë mënyrë ne konfigurojmë vetëm replikimin nga corp-000 në store-001.

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)

Konfigurimi më pas njoftohet për ndryshimin e skemës, domethënë shtimin e një tabele të re, duke përdorur komandën symadmin me argumentin sync-triggers, i cili rikrijon nxitësit për të hartuar përkufizimet e tabelës. send-schema ekzekutohet për të dërguar ndryshimet e skemës në node store-001 dhe konfigurohet replikimi i tabelës t1.

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

Përfitimet e SymmetricDS

Instalim dhe konfigurim i lehtë, duke përfshirë një grup të gatshëm skedarësh me parametra për krijimin e një qarku me tre nyje ose me dy nyje.
Bazat e të dhënave ndër-platformë dhe pavarësia e platformës, duke përfshirë serverët, laptopët dhe pajisjet mobile.
Repliko çdo bazë të dhënash në çdo bazë të dhënash tjetër në nivel lokal, në WAN ose në cloud.
Mundësia e punës optimale me disa baza të dhënash ose disa mijëra për replikim të përshtatshëm.
Versioni i paguar me GUI dhe mbështetje të shkëlqyer.

Disavantazhet e SymmetricDS

Ju duhet të përcaktoni manualisht rregullat dhe drejtimin e përsëritjes në vijën e komandës përmes deklaratave SQL për të ngarkuar tabelat e katalogut, gjë që mund të jetë e papërshtatshme.
Vendosja e shumë tabelave për përsëritje mund të jetë e lodhshme nëse nuk përdorni skripta për të krijuar deklarata SQL që përcaktojnë rregullat dhe drejtimin e replikimit.
Ka shumë informacion që regjistrohet në regjistra dhe ndonjëherë ju duhet të rregulloni skedarin e regjistrit në mënyrë që të mos zërë shumë hapësirë.

Rezultatet për SymmetricDS

SymmetricDS ju lejon të konfiguroni përsëritjen e dyanshme midis dy, tre apo edhe disa mijëra nyjeve për të replikuar dhe sinkronizuar skedarët. Ky është një mjet unik që kryen në mënyrë të pavarur shumë detyra, të tilla si rikuperimi automatik i të dhënave pas një periudhe të gjatë ndërprerjeje në një nyje, shkëmbimi i sigurt dhe efikas i të dhënave ndërmjet nyjeve nëpërmjet HTTPS, menaxhimi automatik i konflikteve bazuar në një sërë rregullash, etj. SymmetricDS kryen riprodhimi midis çdo baze të dhënash, prandaj, mund të përdoret për një shumëllojshmëri të gjerë skenarësh, duke përfshirë migrimin, migrimin, shpërndarjen, filtrimin dhe transformimin e të dhënave nëpër platforma.

Shembulli bazohet tek zyrtari udhëzues i shpejtë nga SymmetricDS. NË Manuali i perdoruesit Përshkruan në detaje konceptet e ndryshme të përfshira në vendosjen e replikimit me SymmetricDS.

Burimi: www.habr.com