Replikimi ndërsjellë ndërmjet PostgreSQL dhe MySQL

Do të flas në përgjithësi mbi replikimin e ndërprerë midis PostgreSQL dhe MySQL, si dhe metodologjitë për konfigurimin e këtij lloji të replikimit ndërmjet këtyre dy serverëve të databazës. Zakonisht, databazat në replikimin ndërprerë quhen homogjene, dhe ky është një metodë e përshtatshme për kalimin nga një server i menaxhimit të të dhënave relacional në një tjetër.

Databazat PostgreSQL dhe MySQL konsiderohen zakonisht si relacional, por me zgjerimet e tyre të mëtejshme ato ofrojnë mundësi NoSQL. Këtu do të diskutojmë replikimin midis PostgreSQL dhe MySQL, nga perspektiva e databazave relacionale.

Nuk do të përshkruajmë të gjitha detajet e brendshme, vetëm parimet bazë, në mënyrë që të merrni njëide mbi konfigurimin e replikimit midis serverëve të databazës, përfitimet, kufizimet dhe skenarët e përdorimit.

Zakonisht, replikimi midis dy serverave identikë të bazës së të dhënave kryhet ose në mënyrë binarike, ose përmes kërkesave mes nodit kryesor (publikues, kryesor ose aktiv) dhe atij të dytë (abonent, pritës ose pasiv). Qëllimi i replikimit është të ofrojë në kohë reale një kopje të bazës kryesore të të dhënave në anën e nodit të dytë. Në këtë rast, të dhënat transmetohen nga nodi kryesor te ai i dytë, pra nga aktiv te pasiv, sepse replikimi kryhet vetëm në një drejtim. Megjithatë, mund të konfigurohet replikimi midis dy bazave të të dhënave në të dyja drejtimet, që do të thotë se të dhënat transmetohen nga nodi i dytë te ai kryesor në konfigurimin "aktiv-aktiv". Të gjithë këto, duke përfshirë replikimin kaskad, janë të mundshme mes dy ose më shumë serverave identikë të bazës së të dhënave. Konfigurimi "aktiv-aktiv" ose "aktiv-pasiv" varet nga nevoja, disponueshmëria e këtyre mundësive në konfigurimin fillestar, ose përdorimi i zgjidhjeve të jashtme për konfigurimin dhe kompromiset ekzistuese.

Konfigurimi i përshkruar është i mundshëm midis serverëve të ndryshëm të bazës së të dhënave. Një server mund të konfigurohet për të pranuar të dhënat e riprodhuara nga një server tjetër i bazës së të dhënave dhe në të njëjtën kohë të ruajë kopje të të dhënave që riprodhohen në kohë reale. MySQL dhe PostgreSQL ofrojnë shumicën e këtyre konfigurimeve ose me forcat e tyre ose me ndihmën e zgjerimeve të palëve të treta, duke përfshirë metodat e logarit të dyfishtë, bllokimin e disqeve dhe metodat e bazuara në operatorë dhe rreshta.

Riprodhimi i kryqëzuar midis MySQL dhe PostgreSQL është i nevojshëm për migrimin një herë nga një server i bazës së të dhënave në një tjetër. Këto baza të dhënash përdorin protokollet të ndryshme, prandaj nuk është e mundur t'i lidhni ato drejtpërdrejt. Për të vendosur shkëmbimin e të dhënave, mund të përdorni një mjet të hapur burimi, si pg_chameleon.

Çfarë është pg_chameleon

pg_chameleon është një sistem riprodhimi nga MySQL në PostgreSQL në Python 3. Ai përdor bibliotekën e hapur mysql-replication, gjithashtu në Python. Imazhet e rreshtave nxirren nga tabelat MySQL dhe ruhet si objekte JSONB në bazën e të dhënave PostgreSQL, dhe pastaj dekodohen nga funksioni pl/pgsql dhe riprodhohen në bazën e të dhënave PostgreSQL.

Aftësitë e pg_chameleon

Disa skema MySQL nga një grup mund të replikohen në një bazë të vetme PostgreSQL me konfigurimin "një me shumë"
Emrat e skemave origjinale dhe të destinacionit nuk mund të përputhen.
Të dhënat e replikimit mund të nxirren nga një replikë kaskad MySQL.
Tabelat që nuk mund të replikohen ose krijojnë gabime përjashtohen.
Çdo funksion replikimi menaxhohet nga demonët.
Kontrolli me parametra dhe skedarë konfigurimi në bazë YAML.

Shembuj

Host
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

Porti i DB
3306
5433

IP adresë
192.168.56.102
192.168.56.106

Së pari, përgatitni të gjithë komponentët e nevojshëm për instalimin e pg_chameleon. Në këtë shembull, Python 3.6.8 është instaluar, i cili krijon një ambient virtual dhe e aktivizon atë.

$> 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 installimit të suksesshëm të Python3.6, duhet të kryhen kërkesat e tjera, siç është krijimi dhe aktivizimi i një mjedisi virtual. Përveç kësaj, moduli pip përditësohet në versionin më të fundit dhe përdoret për të instaluar pg_chameleon. Në komandat më poshtë, qëllimisht instalohet pg_chameleon 2.0.9, megjithëse versioni më i fundit është 2.0.10. Kjo bëhet 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

Pastaj, ne thërrasim pg_chameleon (chameleon është komanda) me argumentin set_configuration_files, për të aktivizuar pg_chameleon dhe krijuar direktoret dhe skedarët e konfigurimit me parametrat e paracaktuar.

(venv) $> chameleon set_configuration_files
krijimi i direktorisë /root/.pg_chameleon
krijimi i direktorisë /root/.pg_chameleon/configuration/
krijimi i direktorisë /root/.pg_chameleon/logs/
krijimi i direktorisë /root/.pg_chameleon/pid/
kopjimi i konfigurimit shembuj në /root/.pg_chameleon/configuration//config-example.yml

Tani krijojmë një kopje të config-example.yml si default.yml, që të bëhet skedari i konfigurimit të paracaktuar. Shembulli i skedarit të konfigurimit për këtë rast është dhënë më poshtë.

$> cat default.yml
---
#c 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 lejon përdoruesin të ndryshojë konvertimin e tipit të parazgjedhur në një tjetër.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

#postgres  lidhja e destinacionit
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 ditë'
    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 #bën skip inserimet në tabelën delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #bën skip fshirjet në skemën delphis_mediterranea
      update:

Skedari i konfigurimit në këtë shembull është një model i skedarit pg_chameleon me ndryshime të parëndësishme në përputhje me ambientet origjinale dhe të destinuara, dhe më poshtë jep një përmbledhje të seksioneve të ndryshme të skedarit të konfigurimit.

Në skedarin e konfigurimit default.yml ka një seksion për parametrat globalë (global settings), ku mund të menaxhoni cilësime të tilla si vendndodhja e skedarit të bllokimit, vendndodhja e regjistrimeve, periudha e ruajtjes së regjistrimeve etj. Më pas vjen seksioni për kalimin e llojeve (type override), ku është e përcaktuar një grup rregullash për kalimin e llojeve gjatë replikimit. Në shembullin e paracaktuar përdoret një rregull kalimi tipi që shndërron tinyint(1) në një vlerë logjike. Në seksionin e ardhshëm specifikoni detajet e lidhjes me bazën e të dhënave target. Në rastin tonë, kjo është një bazë të dhënash PostgreSQL, e cila është shënuar si pg_conn. Në seksionin e fundit, specifikoni të dhënat e burimit, domethënë parametrat e lidhjes së bazës së të dhënave burimore, skemën e përputhjes ndërmjet bazës së të dhënave burimore dhe asaj target, tabelat që duhet të kalohen, koha e pritjes, memoria, madhësia e paketës. Vini re se "sources" është e shënuar në shumës, do të thotë se ne mund të shtojmë disa baza të dhënash burimore për një të vetme target, për të konfiguruar një konfigurim "shumë në një".

Baza e të dhënave world_x në shembull përmban 4 tabela me rreshta që komuniteti MySQL ofron si shembull. Ajo mund të shkarkohet këtu. Shembulli i bazës së të dhënave ofrohet në formën e një arkivi tar dhe të kompresuar 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 emrin e njëjtë usr_replica. Në MySQL, atij i jepen të drejta të tjera për të lexuar të gjitha tabulat e replikueshme.

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 e PostgreSQL krijohet një bazë e dhënash db_replica, e cila do të pranojë ndryshimet nga baza e të dhënave MySQL. Përdoruesi usr_replica në PostgreSQL konfigurtohet automatikisht si pronar i dy skemave pgworld_x dhe sch_chameleon, të cilat përmbajnë tabelat reale të replikës dhe tabelat me katalogët e replikës përkatësisht. Konfigurimi automatik bëhet përmes argumentit create_replica_schema, 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

Grupimi i MySQL konfigurohet me ndryshime të disa parametrave për ta përgatitur atë për replikim, siç tregohet më poshtë. Do të nevojitet të riaktivizoni 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, për të siguruar që gjatë ekzekutimit të komandave pg_chameleon të mos ketë probleme.

Në nodin PostgreSQL:

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

Në nodin MySQL :

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

Tre komandat e mëposhtme pg_chameleon (chameleon) përgatisin mjedisin, shtojnë burimin dhe inicializojnë replikën. Argumenti create_replica_schema në pg_chameleon krijon skemën standarde (sch_chameleon) dhe skemën e replikës (pgworld_x) në bazën e të dhënave PostgreSQL, siç e përmendëm më parë. Argumenti add_source shton burimin e bazës së të dhënave në konfigurim, duke lexuar skedarin e konfigurimit (default.yml), dhe në rastin tonë është mysql, ndërsa 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

Të dhënat e këtyre tre komandave me sa duket tregojnë për arritjen e suksesshme të tyre. Të gjitha dështimet ose gabimet sintaksore paraqiten në mesazhe të thjeshta dhe të kuptueshme me sugjerime për korrigjimin e problemeve.

Në fund, le të fillojmë replikimin me start_replica dhe të marrim një mesazh për përfundimin e suksesshëm.

$> chameleon start_replica --config default --source mysql 
output: Duke filluar procesin e replikimit për burimin mysql

Statusi i replikimit mund të kërkohet me argumentin show_status, ndërsa gabimet mund të shihen me argumentin show_errors.

Rezultati.

Siç e përmendëm më parë, çdo funksion replikimi menaxhohet nga demonët. Për të parë ata, do të kërkojmë tabelën e proceseve me komandën Linux ps, siç tregohet më poshtë.

Rezultati.

Replikimi nuk konsiderohet i konfiguruar derisa ta testojmë atë në kohë reale, siç tregohet më poshtë. Krijojmë një tabelë, insertojmë 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 regjistrat 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
Procesi i sinkronizimit të tabelave për burimin mysql ka filluar.

Për të konfirmuar rezultatet e testit, ne kërkojmë tabelën nga baza e të dhënave PostgreSQL dhe e 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 kryejmë migrimin, komandat e ardhshme të pg_chameleon do të përfundojnë atë. Komandat duhet të ekzekutohen pasi të sigurohemi se të gjithë rreshtat e tabelave qëllimore janë replicuar, dhe rezultati do të jetë një bazë të dhënash PostgreSQL e transferuar saktë pa referenca në burimin ose skemën e replikimit (sch_chameleon).

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

Si opsion, komandat e ardhshme mund të përdoren për të fshirë konfigurimin origjinal dhe skemën e replikimit.

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

Përfitimet e pg_chameleon

Konfigurimi dhe vendosja e thjeshtë.
Diagnozë e lehtë dhe identifikim i anomalive me mesazhe gabimesh të qarta.
Të dhëna të veçanta shtesë mund të shtohen në replikim pas inicializimit, pa ndryshuar konfigurimin e mbetur.
Mund të konfiguroni disa baza të dhënash burimore për një të targetuar, dhe kjo është shumë e dobishme kur bashkoni të dhënat nga një ose më shumë baza të dhënash MySQL në një bazë të dhënash PostgreSQL.
Mund të mos replikoni tabelat e zgjedhura.

Disavantazhet e pg_chameleon

Mbështetet vetëm me MySQL 5.5 dhe më lart si burim dhe PostgreSQL 9.5 dhe më lart si bazë të dhënash të targetuar.
Çdo tabelë duhet të ketë një çelës primar ose unik, përndryshe tabelat inicializohen gjatë procesit init_replica, por nuk replikohen.
Replikimi njëanshëm — vetëm nga MySQL në PostgreSQL. Prandaj, përshtatet vetëm për skemën 'aktiv-pasiv'.
Burimi mund të jetë vetëm një bazë të dhënash MySQL, dhe mbështetje për bazën e të dhënave PostgreSQL si burim është vetëm eksperimentale dhe me kufizime (merrni më shumë informacion) këtu)

Përmbledhje për pg_chameleon

Metoda e replikimit në pg_chameleon është shkëlqyer për migrimin e bazës së të dhënave nga MySQL në PostgreSQL. Një mangësi e rëndësishme është se replikimi është vetëm njëanshëm, kështu që specialistët e bazave të dhënash me siguri nuk do të duan ta përdorin atë për diçka tjetër përveç migrimit. Por problemi i replikimit njëanshëm mund të zgjidhet me një mjet tjetër me burim të hapur — SymmetricDS.

Më shumë mund të lexoni në dokumentacionin zyrtar këtu. Ndihmën për komandat në linjë mund ta gjeni këtu.

Përmbledhja e SymmetricDS

SymmetricDS është një vegël open-source që replikohet çdo bazë të dhënash në çdo bazë tjetër të njohur të dhënash: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird dhe ekzemplarë të tjerë të bazave të dhënash në cloud, si Redshift dhe Azure, etj. Veçoritë e disponueshme: sinkronizimi i bazave të të dhënave dhe skedarëve, replikimi i disa burimeve të bazave të dhënash, sinkronizimi i filtruar, transformimi dhe të tjera. Ky është një vegël në Java, dhe kërkon një version standard të JRE ose JDK (versionet 8.0 ose më lart). Këtu mund të regjistrohen ndryshimet e të dhënave nga trigjet në bazën e dhënash burimore dhe t'i drejtohen bazës së dhënash qëllim në formë paketash.

Veçoritë e SymmetricDS

Vegla është e pavarur nga platforma, që do të thotë se dy ose më shumë baza të ndryshme të dhënash mund të shkëmbejnë të dhëna.
Baza të dhënash relacionalë sinkronizohen përmes regjistrimit të ndryshimeve të të dhënave, ndërsa bazat e dhënash që bazohen në sisteme skedarësh përdorin sinkronizimin e skedarëve.
Replikimi dytësor duke përdorur metoda Push dhe Pull të bazuara në një set rregullash.
Transferimi i të dhënave është i mundur përmes rrjetesh të sigurta dhe rrjetesh me kapacitet të ulët kalimi.
Rikuperimi automatik kur nodet rifillojnë punën pas një dështimi dhe zgjidhja automatikisht e konflikteve.
Kompatibilitet me cloud dhe API efikas për zgjatime.

Shembuj

SymmetricDS mund të konfigurohet në një nga dy opsionet:
Një nod të kryesore (prind) që koordinon në mënyrë qendrore replikimin e të dhënave midis dy nodet nënshkruese (fëmijë), dhe shkëmbimi i të dhënave midis nodëve fëmijë ndodh vetëm përmes prindit.
Një nod aktiv (nodi 1) mund të shkëmbejë të dhëna për replikim me një nod tjetër aktiv (nodi 2) pa ndërmjetës.

Në të dy opsionet, shkëmbimi i të dhënave ndodh përmes Push dhe Pull. Në këtë shembull, ne do të shqyrtojmë konfigurimin "aktiv-aktiv". Të përshkruash tërë arkitekturën është shumë e gjatë, prandaj shqyrto një udhëzues, për të mësuar më shumë rreth pajisjes SymmetricDS.

Instalimi i SymmetricDS është shumë i thjeshtë: shkarko versionin open-source të skedarit zip këtu dhe ta nxirrni aty ku dëshironi. Në tabelën më poshtë paraqiten të dhënat për vendndodhjen dhe versionin e SymmetricDS në këtë shembull, si dhe versionet e baza të dhënash, versionet e Linux-it, adresat IP dhe portet për të dy node-t.

Host
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

Porti i DB
3306
5832

IP adresë
192.168.1.107
192.168.1.112

Versioni i SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9

Shtegu i instalimit të SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

Emri i nodit SymmetricDS
corp-000
store-001

Këtu po instalojmë SymmetricDS në /usr/local/symmetric-server-3.9.20, dhe këtu do të ruhen katalogët e ndryshëm dhe skedarët. Na interesojnë katalogët e brendshëm samples dhe engines. Në katalogun samples gjenden shembujt e skedarëve të konfigurimit me atributet e nodit, si dhe shembujt e skriptëve SQL për të filluar shpejtë demonstrimin.

Në katalogun samples shohim tre skedarë konfigurimi me atributet e nodit - emri tregon karakterin e nodit në një skemë të caktuar.

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

Në SymmetricDS ka të gjitha skedarët e nevojshëm të konfigurimit për skemën bazë nga 3 nodë (opsioni 1), dhe të njëjtët skedarë mund të përdoren për skemën nga 2 nodë (opsioni 2). Kthen skedarin e nevojshëm të konfigurimit nga katalogu samples në engines në host-in vm1. Kështu del:

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

Ky kyç i konfigurimit të SymmetricDS quhet corp-000, dhe lidhja me bazën e të dhënave trajtohet nga drejtuesi mysql jdbc, i cili përdor rreshtin e lidhjes të përmendur më sipër dhe kredencialet për hyrje. Ne lidhemi me bazën e të dhënave replica_db dhe gjatë krijimit të skemës do të krijohen tabelat. sync.url tregon vendin e lidhjes me nyjën për sinkronizim.

Nod 2 në hostin vm2 konfigurtohet si store-001, ndërsa pjesa tjetër është e dokumentuar në skedarin node.properties, i cili jepet më poshtë. Nod store-001 përdor një bazë të dhënash PostgreSQL, dhe pgdb_replica është baza e të dhënave për replikim. registration.url lejon hostin vm2 të lidhet me 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 gatshëm i SymmetricDS përmban parametrat për konfigurar replikimin dyanshëm midis dy serverëve të bazës së të dhënave (dy nyjave). Hapat e mëposhtëm ekzekutohen në hostin vm1 (corp-000), e cila do të krijojë një shembull skeme me 4 tabela. Më pas, ekzekutimi i komandës create-sym-tables me symadmin krijon tabelat e katalogut, ku do të ruhen rregullat dhe drejtimi i replikimit midis nyjave. Në fund, në tabela ngarkohet një shembull i të dhënave.

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ë shembullin e tabelave, item dhe item_selling_price janë konfiguruar automatikisht për replikim nga corp-000 në store-001, ndërsa tabelat e shitjes (sale_transaction dhe sale_return_line_item) janë konfiguruar automatikisht për replikim nga store-001 në corp-000. Tani krijojmë një skemë në bazën e të dhënave PostgreSQL në hostin vm2 (store-001), për ta përgatitur atë për pranim të të dhënave nga corp-000.

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

Ne blehni që në databazën MySQL në vm1 ka shembuj të tabelave dhe tabelave të katalogëve të SymmetricDS. Vini re se tabelat sistemike të SymmetricDS (me prefiksin sym_) aktualisht janë të disponueshme vetëm në nyjën corp-000, sepse aty kemi ekzekutuar komandën create-sym-tables dhe do të menaxhojmë replikimin. Po ashtu, në databazën në nyjën store-001 do të ketë vetëm 4 tabela shembuj pa të dhëna.

Gati. Ambienti është gati për të nisur proceset serverike sym në të dy nyjat, siç tregohet më poshtë.

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

Të dhënat e logeve dërgohen në skedarin e logut të prapambetur (symmetric.log) në dosjen e logeve në katalogun ku është instaluar SymmetricDS, si dhe në daljet standarde. Serveri sym tani mund të iniciohet në nyjën store-001.

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

Nëse e aktivizoni procesin e serverit sym në hostin vm2, ai do të krijojë tabelat e katalogut të SymmetricDS gjithashtu në databazën PostgreSQL. Nëse aktivizoni procesin e serverit sym në të dy nodet, ato do të koordinohen me njëra-tjetrën për të riplikuar të dhënat nga corp-000 në store-001. Nëse pas disa sekondash kërkojmë të gjitha 4 tabelat nga të dy anët, do të shohim se riplikimi është kryer me sukses. Ose mund të dërgojmë një ngarkesë fillestare në nodin store-001 nga corp-000 me komandën e ardhshme.

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

Në këtë pikë, në tabelën item në databazën MySQL në nodin corp-000 (host: vm1), shtohet një regjistrim i ri dhe mund të verifikohet riplikimi i saj në databazën PostgreSQL në nodin store-001 (host: vm2). Ne shohim operacionin Pull për të transferuar 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 operacionin Push për transferimin e të dhënave nga store-001 në corp-000, shtoni një regjistrim në tabelën sale_transaction dhe kontrolloni që riplikimi është kryer.

Rezultati.

Ne kemi një konfigurim të suksesshëm të replikimit dypalësh të tabelave ndërmjet bazave të të dhënave MySQL dhe PostgreSQL. Për të ngritur replikimin për tabelat e reja të përdoruesve, ndjekim hapat e mëposhtëm. Krijojmë tabelën t1 për shembull dhe konfigurojmë rregullat e replikimit si vijon. Kështu, 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)

Pastaj, konfigurimi merr një njoftim për ndryshimin e skemës, që do të thotë shtimi i një tabele të re, përmes komandës symadmin me argumentin sync-triggers, i cili ripërqendron trigjerat për të përputhur përkufizimet e tabelave. Kryhet send-schema për të dërguar ndryshimet në skemë në nyjën store-001, dhe replikimi i tabelës t1 është i konfiguruar.

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

Përfitimet e SymmetricDS

Instalimi dhe konfigurimi i thjeshtë, duke përfshirë një set të gatshëm skedash me parametra për krijimin e skemave me tri ose dy nyje.
Kryqplatformësia e bazave të dhënash dhe pavarësia nga platforma të ndryshme, duke përfshirë serverë, laptopë dhe pajisje celulare.
Replika e çdo baze të dhënash në çdo bazë tjetër lokalisht, në WAN ose në cloud.
Mundësia për optimizimin e punës me një grup të vogël bazash të dhënash ose me qindra për replikim të lehtë.
Versioni i paguar me një ndërfaqe grafike dhe mbështetje të shkëlqyer.

Disavantazhet e SymmetricDS

Duhet të përcaktohen manualisht në komandën e linjës rregullat dhe drejtimi i replikimit përmes operatorëve SQL për të ngarkuar tabelat e katalogut, që ndonjëherë është e pakëndshme.
Rregullimi i shumë tabelave për replikim mund të jetë lodhës, nëse nuk përdoren skriptet për të krijuar operatorë SQL që përcaktojnë rregullat dhe drejtimin e replikimit.
Shkruhen shumë informacione në log, dhe ndonjëherë duhet të organizohet skedari i logut që të mos zërë shumë hapësirë.

Përmbledhje mbi SymmetricDS

SymmetricDS lejonë të konfigurojë replikimin dyanshëm midis dy, tre dhe madje shumë mijëra nyjeve, për të realizuar replikimin dhe sinkronizimin e skedareve. Ky është një mjet unik që kryen shumë detyra vetë, si rinovimin automatik të të dhënave pas një pezullimi të gjatë në nyje, ndarjen e sigurt dhe efikase të të dhënave midis nyjeve përmes HTTPS, menaxhimin automatik të konflikteve bazuar në një grup rregullash, etj. SymmetricDS realizon replikimin midis çdo baze të dhënash, kështu që mund të përdoret për një gamë të gjerë skenarësh, duke përfshirë migrimin, kalimin në një version të ri, shpërndarjen, filtrimin dhe transformimin e të dhënave në platformat e ndryshme.

Shembulli është krijuar mbi bazën e zyrtare udhëzuesit të shkurtër për SymmetricDS. Në udhëzuesin e përdoruesit përshkruhen në detaje konceptet e ndryshme të lidhura me konfigurimin e replikimit me SymmetricDS.

Burimi: habr.com