Mi mallonge parolos pri krucreplikado inter PostgreSQL kaj MySQL, kaj ankaŭ pri metodoj por agordi krucreplikadon inter ĉi tiuj du datumbazaj serviloj. Kruc-reproduktitaj datumbazoj estas ofte referitaj kiel homogenaj datumbazoj, kaj tio estas oportuna metodo por migri de unu RDBMS-servilo al alia.
PostgreSQL kaj MySQL-datumbazoj estas tradicie konsiderataj interrilataj, sed kun pliaj etendaĵoj ili ofertas NoSQL-kapablojn. Ĉi tie ni diskutos pri reproduktado inter PostgreSQL kaj MySQL el interrilata datumbaza administradperspektivo.
Ni ne priskribos la tutajn internaĵojn, nur la bazajn principojn, por ke vi havu ideon pri agordo de reproduktado inter datumbazaj serviloj, avantaĝoj, limigoj kaj uzkazoj.
Tipe, reproduktado inter du identaj datumbazserviloj estas farita aŭ en binara reĝimo aŭ per demandoj inter majstro (alinome eldonisto, majstro aŭ aktiva) kaj sklavo (abonanto, standby aŭ pasiva). La celo de reproduktado estas disponigi realtempan kopion de la majstra datumbazo sur la ŝancatendoflanko. En ĉi tiu kazo, datumoj estas transdonitaj de majstro al sklavo, tio estas, de aktiva al pasiva, ĉar reproduktado estas farita nur en unu direkto. Sed vi povas agordi reproduktadon inter la du datumbazoj en ambaŭ direktoj, tiel ke datumoj estas transdonitaj de la sklavo al la mastro en aktiva-aktiva agordo. Ĉio ĉi, inkluzive de kaskada reproduktado, eblas inter du aŭ pli identaj datumbazaj serviloj. Aktiv-aktiva aŭ aktiva-pasiva agordo dependas de la bezono, la havebleco de tiaj kapabloj en la komenca agordo aŭ la uzo de eksteraj agordaj solvoj kaj ekzistanta komerco. -offs .
La priskribita agordo eblas inter malsamaj datumbazaj serviloj. La servilo povas esti agordita por ricevi reproduktitajn datenojn de alia datumbaza servilo kaj daŭre reteni realtempajn momentfotojn de la reproduktitaj datenoj. MySQL kaj PostgreSQL ofertas la plej multajn el ĉi tiuj agordoj denaske aŭ per triaj etendaĵoj, inkluzive de binaraj protokolaj metodoj, diskseruroj kaj deklaroj kaj vicaj metodoj.
Kruc-reproduktado inter MySQL kaj PostgreSQL estas necesa por unufoja migrado de unu datumbaza servilo al alia. Ĉi tiuj datumbazoj uzas malsamajn protokolojn, do vi ne povas ligi ilin rekte. Por faciligi interŝanĝon de datumoj, vi povas uzi eksteran malfermfontan ilon, kiel pg_chameleon.
Kio estas pg_kameleono
pg_chameleon estas reprodukta sistemo de MySQL al PostgreSQL en Python 3. Ĝi uzas la mysql-replication malfermfontecan bibliotekon, ankaŭ en Python. Vicbildoj estas prenitaj de MySQL-tabeloj kaj stokitaj kiel JSONB-objektoj en la PostgreSQL-datumbazo, kaj tiam dekoditaj per la pl/pgsql-funkcio kaj reluditaj en la PostgreSQL-datumbazo.
Trajtoj de pg_chameleon
Multoblaj MySQL-skemoj de la sama areto povas esti reproduktitaj al ununura PostgreSQL-cela datumbazo kun unu-al-multa agordo
La fontaj kaj celaj skemnomoj ne povas esti la samaj.
Reproduktaj datumoj povas esti prenitaj de MySQL-kaskada kopio.
Tabeloj kiuj ne povas reprodukti aŭ generi erarojn estas ekskluditaj.
Ĉiu reproduktadfunkcio estas kontrolita de demonoj.
Kontrolu per parametroj kaj agordaj dosieroj bazitaj sur YAML.
Ekzemplo:
Gastiganto
vm1
vm2
OS-versio
CentOS Linukso 7.6 x86_64
CentOS Linukso 7.5 x86_64
Versio de datumbaza servilo
MySQL 5.7.26
PostgreSQL 10.5
DB-haveno
3306
5433
IP-adreso
192.168.56.102
192.168.56.106
Unue, preparu ĉiujn necesajn komponantojn por instali pg_chameleon. Ĉi tiu ekzemplo havas Python 3.6.8 instalita, kiu kreas virtualan medion kaj aktivigas ĝin.
$> 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 altinstallPost kiam Python3.6 estas sukcese instalita, la ceteraj postuloj devas esti kompletigitaj, kiel krei kaj aktivigi virtualan medion. Ankaŭ la pip-modulo estas ĝisdatigita al la plej nova versio kaj uzata por instali pg_chameleon. La subaj komandoj intence instalas pg_chameleon 2.0.9, kvankam la plej nova versio estas 2.0.10. Ĉi tio estas necesa por eviti novajn erarojn en la ĝisdatigita versio.
$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9Ni tiam nomas pg_chameleon (kameleono estas komando) kun la argumento set_configuration_files por ebligi pg_chameleon kaj krei la defaŭltajn agordajn dosierujojn kaj dosierojn.
(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.ymlNi nun faras kopion de config-example.yml kiel default.yml por ke ĝi fariĝu la defaŭlta agorda dosiero. Ekzempla agorda dosiero por ĉi tiu ekzemplo estas provizita malsupre.
$> 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:La agorda dosiero en ĉi tiu ekzemplo estas ekzempla pg_chameleon-dosiero kun etaj modifoj por kongrui kun la fonto kaj cela medioj, kaj sube estas superrigardo de la diversaj sekcioj de la agorda dosiero.
La defaŭlta.yml agorda dosiero havas sekcion de tutmondaj agordoj (tutmondaj agordoj) kie vi povas kontroli agordojn kiel la loko de la ŝlosildosiero, la loko de la protokoloj, la konservadperiodo por la protokoloj, ktp. Poste venas la tipo-anstataŭigo. sekcio, kie la fiksitaj reguloj por superregado de tipoj dum reproduktado. La defaŭlta ekzemplo uzas tipan superregulon, kiu konvertas tinyint(1) al buleano. En la sekva sekcio, ni specifas la detalojn pri konekto al la cela datumbazo. En nia kazo, ĉi tio estas PostgreSQL-datumbazo, indikita kiel pg_conn. En la lasta sekcio, ni specifas la fontajn datumojn, tio estas, la konekto-parametrojn de la fonta datumbazo, la mapan skemon de la fontaj kaj celaj datumbazoj, tabeloj por esti preterlasitaj, tempodaŭro, memoro, paka grandeco. Notu, ke "fontoj" estas pluralo, tio signifas, ke ni povas aldoni plurajn fontajn datumbazojn al la sama celo por agordi mult-al-unu agordon.
La world_x-datumbazo en la ekzemplo enhavas 4 tabelojn kun vicoj, kiujn la MySQL-komunumo sugestas por la ekzemplo. Ĝi povas esti elŝutita . La specimena datumbazo venas kiel gudro kaj kunpremita arkivo kun instrukcioj por krei kaj importi ŝnurojn.
Speciala uzanto kun la sama nomo usr_replica estas kreita en la datumbazoj MySQL kaj PostgreSQL. MySQL donas al ĝi aldonan legan aliron al ĉiuj reproduktitaj tabeloj.
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;Ĉe PostgreSQL-flanko, db_replica datumbazo estas kreita, kiu akceptos ŝanĝojn de la MySQL-datumbazo. La usr_replica uzanto en PostgreSQL estas aŭtomate agordita kiel la posedanto de la du skemoj pgworld_x kaj sch_chameleon, kiuj enhavas la realajn reproduktitajn tabelojn kaj reproduktajn katalogajn tabelojn, respektive. La argumento create_replica_schema respondecas pri aŭtomata agordo, kiel vi vidos sube.
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASELa MySQL-datumbazo estas agordita kun kelkaj ŝanĝoj por igi ĝin preta por reproduktado kiel montrite sube. Vi devos rekomenci la datumbazan servilon por ke la ŝanĝoj efektiviĝu.
$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1Nun gravas kontroli la konekton al ambaŭ datumbazaj serviloj por ke ne estu problemoj dum plenumado de la komandoj pg_chameleon.
Sur la PostgreSQL-nodo:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_xSur MySQL-nodo:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaLa sekvaj tri pg_chameleon (kameleono) komandoj preparas la medion, aldonu la fonton, kaj pravalorigas la kopion. La argumento create_replica_schema al pg_chameleon kreas defaŭltan skemon (sch_chameleon) kaj reproduktan skemon (pgworld_x) en la PostgreSQL-datumbazo, kiel ni diris. La argumento add_source aldonas fontan datumbazon al la agordo legante la agordan dosieron (default.yml), kiu en nia kazo estas mysql, kaj init_replica pravalorigas la agordon surbaze de la agordoj en la agorda dosiero.
$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debugLa eligo de ĉi tiuj tri komandoj klare indikas ilian sukceson. Ĉiuj misfunkciadoj aŭ sintaksaj eraroj estas indikitaj en simplaj kaj kompreneblaj mesaĝoj kun sugestoj pri kiel ripari problemojn.
Fine, ni komencas reproduktadon per start_replica kaj ricevas sukcesan mesaĝon.
$> chameleon start_replica --config default --source mysql
output: Starting the replica process for source mysqlReplika stato povas esti pridemandita per la argumento show_status, kaj eraroj povas esti viditaj per la argumento show_errors.
Kiel ni jam diris, demonoj administras ĉiun reproduktan funkcion. Por vidi ilin, demandu la procezan tabelon per la Linukso ps-komando, kiel montrite sube.
Reproduktado ne estas konsiderata agordita ĝis ni testas ĝin en reala tempo, kiel montrite sube. Ni kreas tabelon, enigas kelkajn rekordojn en la MySQL-datumbazon, kaj vokas la argumenton sync_tables en pg_chameleon por ĝisdatigi la demonojn kaj reprodukti la tabelon kun la rekordoj al la PostgreSQL-datumbazo.
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.Por validigi la testrezultojn, ni pridemandas la tabelon el la PostgreSQL-datumbazo kaj eligas la vicojn.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | one
2 | twoSe ni migras, la sekvaj pg_chameleon-komandoj estos la fino de la migrado. La komandoj devus esti rulitaj post kiam ni kontrolis, ke la vicoj de ĉiuj celtabeloj estas reproduktitaj, rezultigante bonorde migritan PostgreSQL-datumbazon sen referencoj al la fonta datumbazo aŭ reprodukta skemo (sch_chameleon).
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugVi povas laŭvole forigi la originalan agordon kaj reproduktan skemon per la sekvaj komandoj.
$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debugAvantaĝoj de pg_chameleon
Facila agordo kaj agordo.
Konvena problemo-solvado kaj anomalio-detekto kun klaraj erarmesaĝoj.
Pliaj specialaj tabloj povas esti aldonitaj al reproduktado post inicialigo sen ŝanĝi la reston de la agordo.
Eblas agordi plurajn fontajn datumbazojn por unu cela datumbazo, kaj tio estas tre oportuna se vi kunfandas datumojn de unu aŭ pluraj MySQL-datumbazoj en unu PostgreSQL-datumbazon.
Vi povas elekti ne reprodukti elektitajn tabelojn.
Malavantaĝoj de pg_chameleon
Nur subtenata kun MySQL 5.5 kaj pli supre kiel la fonto kaj PostgreSQL 9.5 kaj pli supre kiel la cela datumbazo.
Ĉiu tablo devas havi ĉefan aŭ unikan ŝlosilon, alie la tabeloj estas pravigitaj en la procezo init_replica sed ne reproduktitaj.
Unudirekta reproduktado - nur de MySQL al PostgreSQL. Tial ĝi taŭgas nur por la aktiva-pasiva skemo.
La fonto povas esti nur MySQL-datumbazo, kaj subteno por PostgreSQL-datumbazo kiel fonto estas nur eksperimenta kaj limigita (lernu pli )
Sumoj por pg_chameleon
La reprodukta metodo en pg_chameleon estas bonega por migri datumbazon de MySQL al PostgreSQL. La granda malavantaĝo estas, ke reproduktado estas nur unudirekta, do datumbazaj profesiuloj verŝajne ne volos uzi ĝin por io alia ol migrado. Sed la problemo de unudirekta reproduktado povas esti solvita per alia malfermkoda ilo - SymmetricDS.
Legu pli en la oficiala dokumentaro . Komandlinia helpo troveblas .
Superrigardo de SymmetricDS
SymmetricDS estas malfermfonta ilo kiu reproduktas ajnan datumbazon al iu ajn alia komuna datumbazo: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird kaj aliaj nubaj datumbazoj, ekzemple Redshift, kaj Azure, ktp Disponeblaj funkcioj: datumbazo kaj dosiera sinkronigo, mult-mastra datumbaza reproduktado, filtrita sinkronigo, transformo kaj aliaj. Ĉi tio estas Java ilo kaj postulas la norman eldonon JRE aŭ JDK (versio 8.0 aŭ pli alta). Ĉi tie vi povas registri datumajn ŝanĝojn pri ellasiloj en la fonta datumbazo kaj sendi ilin al la responda cela datumbazo kiel aroj.
SymmetricDS Kapabloj
La ilo estas platformo sendependa, kio signifas, ke du aŭ pli da malsamaj datumbazoj povas interŝanĝi datumojn.
Relaciaj datumbazoj estas sinkronigitaj registrante datenŝanĝojn, kaj datumbazoj bazitaj sur dosiersistemoj uzas dosiersinkronigon.
Dudirekta reproduktado uzante puŝajn kaj tirmetodojn bazitajn sur aro de reguloj.
Transdono de datumoj eblas per sekuraj retoj kaj retoj kun malalta bendolarĝo.
Aŭtomata reakiro kiam nodoj rekomencas post fiasko kaj aŭtomata konflikta solvado.
Nubaj kongruaj kaj efikaj etendaj APIoj.
Ekzemplo:
SymmetricDS povas esti agordita laŭ unu el du manieroj:
Mastro (gepatro) nodo kiu centre kunordigas datenreproduktadon inter du sklavaj (infanaj) nodoj, kaj datumintersanĝo inter infannodoj estas aranĝita nur tra la gepatro.
Aktiva nodo (nodo 1) povas komuniki por reproduktado kun alia aktiva nodo (nodo 2) sen peranto.
En ambaŭ opcioj, datumoj interŝanĝo okazas uzante Push kaj Pull. En ĉi tiu ekzemplo, ni konsideros la aktivan-aktivan agordon. Estas tro longa por priskribi la tutan arkitekturon, do studu por lerni pli pri la aparato SymmetricDS.
Instali SymmetricDS estas facila: elŝutu la malfermfontan zip-dosieron kaj ĉerpi ĝin kie ajn vi volas. La sekva tabelo listigas la installokon kaj version de SymmetricDS en ĉi tiu ekzemplo, same kiel datumbazversiojn, Linuksajn versiojn, IP-adresojn kaj havenojn por ambaŭ nodoj.
Gastiganto
vm1
vm2
OS-versio
CentOS Linukso 7.6 x86_64
CentOS Linukso 7.6 x86_64
Versio de datumbaza servilo
MySQL 5.7.26
PostgreSQL 10.5
DB-haveno
3306
5832
IP-adreso
192.168.1.107
192.168.1.112
SymmetricDS Versio
SimetriaDS 3.9
SimetriaDS 3.9
SymmetricDS-instala vojo
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20
SymmetricDS gastiga nomo
korp-000
vendejo-001
Ĉi tie ni instalas SymmetricDS en /usr/local/symmetric-server-3.9.20 kaj diversaj subdosierujoj kaj dosieroj estos konservitaj tie. Ni interesiĝas pri la subdosierujoj specimenoj kaj motoroj. La dosierujo de specimenoj enhavas ekzemplajn agordajn dosierojn kun nodaj propraĵoj, kaj ankaŭ specimenajn SQL-skriptojn por rapide komenci la demo.
En la dosierujo de specimenoj, ni vidas tri agordajn dosierojn kun nodaj propraĵoj - la nomo montras la naturon de la nodo en aparta skemo.
corp-000.properties
store-001.properties
store-002.propertiesSymmetricDS havas ĉiujn necesajn agordajn dosierojn por baza 3-noda skemo (opcio 1) kaj la samaj dosieroj povas esti uzataj por 2-noda skemo (opcio 2). Kopiu la bezonatan agordan dosieron de la specimena dosierujo al motoroj sur la vm1-gastiganto. Ĝi rezultas jene:
$> 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Ĉi tiu nodo nomiĝas corp-000 en la agordo SymmetricDS kaj la datumbaza konekto estas pritraktata de la mysql jdbc-ŝoforo, kiu uzas la konektan ĉenon supre kaj ensalutantajn akreditaĵojn. Ni konektas al la datumbazo replica_db kaj tabeloj estos kreitaj dum kreado de skemo. sync.url montras la ligon al la nodo por sinkronigi.
Nodo 2 sur gastiganto vm2 estas agordita kiel store-001 kaj la resto estas specifita en la suba dosiero node.properties. La store-001-nodo prizorgas la PostgreSQL-datumbazon, kaj pgdb_replica estas la datumbazo por reprodukti. registration.url permesas al vm2-gastiganto kontakti vm1-gastiganton kaj ricevi agordajn detalojn de ĝi.
$> 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=001La finita SymmetricDS-ekzemplo enhavas opciojn por starigi dudirektan reproduktadon inter du datumbazserviloj (du nodoj). La subaj paŝoj estas faritaj sur gastiganto vm1 (corp-000), kiu kreos specimenan skemon kun 4 tabeloj. Tiam ekzekuti create-sym-tables kun la symadmin komando kreas dosierujan tabelojn kie la reguloj kaj direkto de reproduktado inter nodoj estos stokitaj. Fine, la specimenaj datumoj estas ŝarĝitaj en la tabelojn.
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.sqlEn la ekzemplo, la tabeloj de item kaj item_selling_price estas aŭtomate agorditaj por reprodukti de corp-000 al store-001, kaj la vendotabeloj (sale_transaction kaj sale_return_line_item) estas aŭtomate agorditaj por reprodukti de store-001 al corp-000. Ni nun kreas skemon en la PostgreSQL-datumbazo sur gastiganto vm2 (store-001) por prepari ĝin por ricevi datumojn de corp-000.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xmlNepre kontrolu, ke la MySQL-datumbazo sur vm1 havas specimenajn tabelojn kaj SymmetricDS-katalogon. Notu, ke la SymmetricDS-sistemaj tabeloj (prefiksitaj per sym_) estas nuntempe nur haveblaj sur la corp-000-nodo, ĉar tie ni rulis la komandon create-sym-tables kaj administros reproduktadon. Kaj en la datumbazo ĉe la vendejo-001-nodo estos nur 4 ekzemplaj tabeloj sen datumoj.
Ĉiuj. La medio estas preta ruli sym-servilprocezojn sur ambaŭ nodoj kiel montrite sube.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &Protokolo-enskriboj estas senditaj al la fona protokolo-dosiero (symmetric.log) en la protokolo-dosierujo en la dosierujo kie SymmetricDS estas instalita, same kiel al la norma eligo. La sym-servilo nun povas esti komencita sur la store-001-nodo.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &Se vi rulas la procezon de sym-servilo sur la gastiganto vm2, ĝi kreos la katalogajn tabelojn de SymmetricDS ankaŭ en la datumbazo PostgreSQL. Se vi rulas la procezon de sym-servilo sur ambaŭ nodoj, ili kunordigos unu kun la alia por reprodukti datumojn de corp-000 al store-001. Se post kelkaj sekundoj ni pridemandas ĉiujn 4 tabelojn ambaŭflanke, ni vidos, ke la reproduktado sukcesis. Aŭ vi povas sendi la bootstrap al store-001 de corp-000 per la sekva komando.
vm1$> ./symadmin --engine corp-000 reload-node 001Je ĉi tiu punkto, nova rekordo estas enigita en la eron-tabelon en la MySQL-datumbazon sur nodo corp-000 (gastiganto: vm1) kaj povas esti kontrolita por reproduktado al la PostgreSQL-datumbazo sur nodo-vendejo-001 (gastiganto: vm2). Ni vidas Pull-operacion por movi datumojn de corp-000 al 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)Por fari puŝan operacion por movi datumojn de store-001 al corp-000, ni enmetas rekordon en la sale_transaction-tabelon kaj kontrolas, ke reproduktado estas finita.
Ni vidas sukcesan aranĝon de dudirekta reproduktado de la ekzemplotabeloj inter la datumbazoj MySQL kaj PostgreSQL. Por agordi reproduktadon por novaj uzanttabloj, faru la sekvajn paŝojn. Ni kreas tabelon t1 ekzemple kaj starigas ĝiajn reproduktajn regulojn jene. Do ni starigis nur reproduktadon de corp-000 al 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)La agordo tiam estas sciigita pri la skemŝanĝo, t.e. la aldono de nova tabelo, uzante la symadmin komandon kun la sync-triggers argumento, kiu rekreas la ellasilon por kongrui kun la tabeldifinoj. Send-schema estas rulita por sendi skemajn ŝanĝojn al store-001, kaj tabelo t1 estas reproduktita.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Avantaĝoj de SymmetricDS
Facila instalado kaj agordo, inkluzive de preta aro de dosieroj kun parametroj por krei skemon kun tri aŭ du nodoj.
Transplatformaj datumbazoj kaj platforma sendependeco, inkluzive de serviloj, tekkomputiloj kaj porteblaj aparatoj.
Repliku ajnan datumbazon al iu ajn alia datumbazo loke, sur la WAN aŭ en la nubo.
Kapablo labori optimume kun paro da datumbazoj aŭ pluraj miloj por facila reproduktado.
Pagita versio kun GUI kaj bonega subteno.
Malavantaĝoj de SymmetricDS
Vi devas permane difini la regulojn kaj direkton de reproduktado sur la komandlinio per SQL-deklaroj por ŝargi la katalogajn tabelojn, kio povas esti maloportuna.
Agordi multajn tabelojn por reproduktado povas esti teda krom se vi uzas skriptojn por krei SQL-deklarojn, kiuj difinas la regulojn kaj direkton de reproduktado.
Estas tro da informoj en la protokoloj, kaj foje vi devas purigi la protokolan dosieron por ke ĝi ne okupu tro da spaco.
Resumo de SymmetricDS
SymmetricDS permesas agordi dudirektan reproduktadon inter du, tri aŭ eĉ kelkmil nodoj por reprodukti kaj sinkronigi dosierojn. Ĝi estas unika ilo, kiu plenumas multajn taskojn per si mem, kiel aŭtomata reakiro de datumoj post longa malfunkcio sur nodo, sekura kaj efika komunikado inter nodoj per HTTPS, aŭtomata konflikta administrado surbaze de reguloj, ktp. SymmetricDS replikas inter iuj datumbazoj, tial, ĝi povas esti uzata por ampleksa vario de scenaroj, inkluzive de migrado, ĝisdatigo, distribuo, filtrado kaj datumtransformo trans platformoj.
La ekzemplo baziĝas sur la oficiala de SymmetricDS. EN Priskribas detale la diversajn konceptojn implikitajn en starigado de reproduktado kun SymmetricDS.
fonto: www.habr.com