Voi vorbi în linii mari despre replicația încrucișată între PostgreSQL și MySQL, precum și despre metodele de configurare a replicației între cele două servere de baze de date. De obicei, bazele de date implicate în replicația încrucișată sunt considerate omogene, iar acesta este un mod convenabil de a trece de pe un server de SGBD relațional pe altul.
Bazele de date PostgreSQL și MySQL sunt considerate relaționale, dar cu extensii suplimentare oferă capacități NoSQL. Aici vom discuta despre replicația între PostgreSQL și MySQL, din perspectiva SGBD-urilor relaționale.
Nu vom descrie toată complexitatea internă, ci doar principiile de bază, astfel încât să aveți o idee despre configurarea replicației între serverele de baze de date, avantajele, limitările și scenariile de utilizare.
De obicei, replicația între două servere de baze de date identice se realizează fie în modul binar, fie prin interogări între nodul principal (cunoscut și sub numele de publisher, master sau activ) și nodul secundar (subscriber, stand-by sau pasiv). Scopul replicației este de a oferi, în timp real, o copie a bazei de date principale pe partea nodului secundar. În acest sens, datele sunt transmise de la nodul principal la nodul secundar, adică de la activ la pasiv, deoarece replicația se realizează întotdeauna într-o singură direcție. Totuși, se poate configura replicația între două baze de date în ambele sensuri, astfel încât datele să fie transmise de la nodul secundar la nodul principal în configurația „activ-activ”. Toate acestea, inclusiv replicația în cascadă, sunt posibile între două sau mai multe servere de baze de date identice. Configurația „activ-activ” sau „activ-pasiv” depinde de nevoie, disponibilitatea acestor posibilități în configurația inițială sau utilizarea soluțiilor externe pentru configurare și compromisiunile existente.
Configurația descrisă este posibilă între diferite servere de baze de date. Un server poate fi configurat pentru a primi date replicate de la un alt server de baze de date și, în același timp, pentru a păstra instantanee ale datelor replicate în timp real. MySQL și PostgreSQL oferă majoritatea acestor configurații fie pe cont propriu, fie prin extensii externe, incluzând metodele de jurnal binar, blocarea discului și metodele bazate pe operatori și șiruri.
Replicația încrucișată între MySQL și PostgreSQL este necesară pentru migrarea unică de la un server de baze de date la altul. Aceste baze de date folosesc protocoale diferite, așa că nu pot fi legate direct. Pentru a stabili schimbul de date, se poate folosi un instrument extern open-source, cum ar fi pg_chameleon.
Ce este pg_chameleon
pg_chameleon este un sistem de replicare de la MySQL la PostgreSQL scris în Python 3. Acesta utilizează biblioteca open-source mysql-replication, tot pe Python. Imaginile rândurilor sunt extrase din tabelele MySQL și salvate ca obiecte JSONB în baza de date PostgreSQL, apoi sunt dezvăluite prin funcția pl/pgsql și reproduse în baza de date PostgreSQL.
Funcționalitățile pg_chameleon
Mai multe scheme MySQL dintr-un singur cluster pot fi replicate într-o singură bază de date țintă PostgreSQL cu o configurație „unu la multe”
Numele schemei sursă și țintă nu pot coincide.
Datele de replicare pot fi extrase dintr-o replică în cascadă MySQL.
Tabelele care nu pot fi replicate sau care generează erori sunt excluse.
Fiecare funcție de replicare este gestionată de demonii.
Control prin intermediul parametrilor și fișierelor de configurare bazate pe YAML.
Exemplu
Gazdă
vm1
vm2
Versiunea OS
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64
Versiunea serverului DB
MySQL 5.7.26
PostgreSQL 10.5
Portul DB
3306
5433
Adresă IP
192.168.56.102
192.168.56.106
Pentru a începe, pregătiți toate componentele necesare pentru instalarea pg_chameleon. În acest exemplu, este instalat Python 3.6.8, care creează un mediu virtual și îl activează.
$> 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 altinstallDupă instalarea cu succes a Python 3.6, trebuie să îndepliniți celelalte cerințe, cum ar fi crearea și activarea mediu virtual. În plus, modulul pip este actualizat la cea mai recentă versiune și este utilizat pentru instalarea pg_chameleon. În comenzile de mai jos, se instalează intenționat pg_chameleon 2.0.9, deși ultima versiune este 2.0.10. Acest lucru este necesar pentru a evita erorile noi din versiunea actualizată.
$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9Apoi apelăm pg_chameleon (chameleon — aceasta este comanda) cu argumentul set_configuration_files, pentru a activa pg_chameleon și a crea directoare și fișiere de configurare implicite.
(venv) $> chameleon set_configuration_files
creând directorul /root/.pg_chameleon
creând directorul /root/.pg_chameleon/configuration/
creând directorul /root/.pg_chameleon/logs/
creând directorul /root/.pg_chameleon/pid/
copiind configurația exemplu în /root/.pg_chameleon/configuration//config-example.ymlAcum creăm o copie a config-example.yml ca default.yml, astfel încât să devină fișierul de configurare implicit. Exemplul fișierului de configurare pentru acest exemplu este prezentat mai jos.
$> cat default.yml
---
#setări globale
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 permite utilizatorului să suprascrie conversia implicită a tipului într-unul diferit.
type_override:
"tinyint(1)":
override_to: boolean
override_tables:
- "*"
#conexiune de destinație postgres
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 #sari peste inserțiile în tabela delphis_mediterranea.foo
delete:
- delphis_mediterranea #sari peste ștergerile din schema delphis_mediterranea
update:Fișierul de configurare în acest exemplu este un model de fișier cu pg_chameleon, cu modificări minore conform mediilor sursă și destinație, iar mai jos se oferă o prezentare generală a diferitelor secțiuni ale fișierului de configurare.
În fișierul de configurare default.yml există o secțiune de setări globale, unde se pot gestiona setări precum locația fișierului de blocare, locația jurnalelor, perioada de păstrare a jurnalelor etc. Apoi urmează secțiunea de suprascriere a tipurilor, unde sunt specificate un set de reguli pentru suprascrierea tipurilor în timpul replicării. În exemplul implicit se folosește o regulă de suprascriere care transformă tinyint(1) în boolean. În următoarea secțiune specificăm detaliile de conectare la baza de date țintă. În cazul nostru, aceasta este baza de date PostgreSQL, numită pg_conn. În ultima secțiune, indicăm datele sursă, adică parametrii de conectare ai bazei de date sursă, schema de mapare a bazelor de date sursă și țintă, tabelele care trebuie ocolite, timpul de așteptare, memoria, dimensiunea lotului. Observați că „sources” este specificat la plural, ceea ce înseamnă că putem adăuga mai multe baze de date sursă pentru una singură țintă, pentru a configura o configurație de tip „multe la unul”.
Baza de date world_x din exemplu conține 4 tabele cu rânduri, pe care comunitatea MySQL le oferă ca exemplu. Aceasta poate fi încărcată . Exemplul bazei de date este furnizat sub formă de arhivă tar comprimată cu instrucțiuni pentru crearea și importul rândurilor.
În bazele de date MySQL și PostgreSQL se creează un utilizator special cu același nume usr_replica. În MySQL, acesta primește drepturi suplimentare de citire asupra tuturor tabelelor replicate.
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;Pe partea PostgreSQL se creează baza de date db_replica, care va primi modificările din baza de date MySQL. Utilizatorul usr_replica în PostgreSQL este configurat automat ca proprietar al celor două scheme pgworld_x și sch_chameleon, care conțin tabelele replicate efective și tabelele cu directoarele de replicare, respectiv. Configurarea automată este gestionată de argumentul create_replica_schema, așa cum veți vedea mai jos.
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASEBaza de date MySQL este configurată cu modificări ale unor parametri, pentru a o pregăti pentru replicare, așa cum este ilustrat mai jos. Va trebui să reporniți serverul de baze de date pentru ca modificările să intre în vigoare.
$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1Acum este important să verificați conexiunea la ambele servere de baze de date, pentru a evita problemele în timpul executării comenzilor pg_chameleon.
Pe nodul PostgreSQL:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_xPe nodul MySQL:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaUrmătoarele trei comenzi pg_chameleon (chameleon) pregătesc mediul, adaugă sursa și inițializează replica. Argumentul create_replica_schema în pg_chameleon creează schema implicită (sch_chameleon) și schema de replicare (pgworld_x) în baza de date PostgreSQL, așa cum am menționat anterior. Argumentul add_source adaugă baza de date sursă în configurație, citind fișierul de configurație (default.yml), iar inițializarea replicii se face pe baza parametrilor din fișierul de configurație.
$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debugRezultatele acestor trei comenzi indică în mod clar finalizarea lor cu succes. Toate erorile sau problemele de sintaxă sunt indicate prin mesaje simple și clare, cu sugestii pentru corectarea problemelor.
În cele din urmă, să lansăm replicarea folosind start_replica și să obținem un mesaj de finalizare cu succes.
$> chameleon start_replica --config default --source mysql
output: Pornirea procesului de replicare pentru sursa mysqlStarea replicării poate fi solicitată cu ajutorul argumentului show_status, iar erorile pot fi vizualizate prin argumentul show_errors.
Așa cum am spus, fiecare funcție de replicare este gestionată de demoni. Pentru a le vizualiza, vom solicita tabelul de procese cu comanda Linux ps, așa cum este prezentat mai jos.
Replicarea nu este considerată configurată până când nu o testăm în timp real, așa cum este prezentat mai jos. Creăm un tabel, inserăm câteva înscrieri în baza de date MySQL și apelăm argumentul sync_tables din pg_chameleon pentru a actualiza demonii și a replica tabelul cu înscrierile în baza de date 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
Procesul de sincronizare a tabelului pentru sursa mysql a început.Pentru a confirma rezultatele testului, solicităm tabelul din baza de date PostgreSQL și afișăm rândurile.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | one
2 | twoDacă efectuam migrarea, următoarele comenzi pg_chameleon vor marca finalizarea acesteia. Comenzile trebuie executate după ce ne asigurăm că rândurile din toate tabelele țintă au fost replicate, iar rezultatul va fi o bază de date PostgreSQL transferată cu succes, fără referințe la baza de date sau schema de replicare originală (sch_chameleon).
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugOpțional, următoarele comenzi pot elimina configurația originală și schema de replicare.
$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debugAvantajele pg_chameleon
Configurare și setare simplă.
Depanare convenabilă și identificare a anomaliilor cu mesaje de eroare clare.
În replicare pot fi adăugate tabele speciale suplimentare după inițializare, fără a schimba restul configurației.
Puteți configura mai multe baze de date sursă pentru o singură destinație, ceea ce este foarte convenabil atunci când combinați date din una sau mai multe baze de date MySQL într-o singură bază de date PostgreSQL.
Puteți alege să nu replicați tabelele selectate.
Dezavantajele pg_chameleon
Este compatibil doar cu MySQL 5.5 și versiuni superioare ca sursă și PostgreSQL 9.5 și versiuni superioare ca bază de date destinație.
Fiecare tabel trebuie să aibă o cheie primară sau unică, altfel tabelele sunt inițializate în timpul procesului init_replica, dar nu sunt replicate.
Replicarea unidirecțională - doar din MySQL în PostgreSQL. De aceea, este potrivită doar pentru schema „activ-pasiv”.
Baza de date sursă poate fi doar MySQL, iar suportul pentru baza de date PostgreSQL ca sursă este doar experimental și cu limitări (aflați mai multe )
Concluziile despre pg_chameleon
Metoda de replicare din pg_chameleon este excelentă pentru migrarea unei baze de date din MySQL în PostgreSQL. Un dezavantaj semnificativ este că replicarea este doar unidirecțională, așa că specialiștii în baze de date probabil că nu vor dori să o folosească pentru altceva decât migrarea. Dar problema replicării unidirecționale poate fi rezolvată cu un alt instrument open-source - SymmetricDS.
Citiți mai multe în documentația oficială . Puteți găsi ajutorul pentru linia de comandă .
Prezentare generală a SymmetricDS
SymmetricDS este un instrument open-source care replică orice bază de date în orice altă bază de date populară: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird și alte instanțe cloud de baze de date, cum ar fi Redshift și Azure etc. Funcții disponibile: sincronizarea bazelor de date și fișierelor, replicarea mai multor baze de date master, sincronizarea filtrată, transformarea și altele. Este un instrument pe Java și necesită o versiune standard JRE sau JDK (versiunea 8.0 sau mai recentă). Aici puteți înregistra modificările datelor prin intermediul trigger-elor în baza de date sursă și le puteți direcționa către baza de date destinație corespunzătoare sub formă de pachete.
Funcționalitățile SymmetricDS
Instrumentul nu depinde de platformă, adică două sau mai multe baze de date diferite pot schimba date.
Baze de date relaționale sunt sincronizate prin înregistrarea modificării datelor, iar bazele de date bazate pe sisteme de fișiere utilizează sincronizarea fișierelor.
Replicare bidirecțională folosind metode Push și Pull pe baza unui set de reguli.
Transmisia datelor se poate efectua prin rețele securizate și rețele cu lățimi de bandă scăzută.
Recuperare automată la repornirea nodurilor după o eroare și rezolvare automată a conflictelor.
Compatibilitate cu cloud-ul și API-uri de extensie eficiente.
Exemplu
SymmetricDS poate fi configurat în una dintre cele două variante:
Nodul principal (părinte) care coordonează central replicarea datelor între două noduri secundare (fii), iar schimbul de date între nodurile fiice se realizează doar prin intermediul părintelui.
Nodul activ (nodul 1) poate schimba date pentru replicare cu un alt nod activ (nodul 2) fără un intermediar.
În ambele variante, schimbul de date se face prin Push și Pull. În acest exemplu, vom analiza configurația „activ-activ”. Este prea lung să descriem întreaga arhitectură, așa că verificați , pentru a afla mai multe despre dispozitivul SymmetricDS.
Instalarea SymmetricDS este foarte simplă: descărcați versiunea open-source zip a fișierului și extrageți-o unde doriți. Tabelul de mai jos oferă detalii despre locația de instalare și versiunea SymmetricDS în acest exemplu, precum și versiuni ale bazelor de date, versiuni Linux, adrese IP și porturi pentru ambele noduri.
Gazdă
vm1
vm2
Versiunea OS
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64
Versiunea serverului DB
MySQL 5.7.26
PostgreSQL 10.5
Portul DB
3306
5832
Adresă IP
192.168.1.107
192.168.1.112
Versiunea SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9
Calea de instalare SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20
Numele nodului SymmetricDS
corp-000
store-001
Aici instalăm SymmetricDS în /usr/local/symmetric-server-3.9.20, iar aici vor fi stocate diferite directoare și fișiere încorporate. Ne interesează directoarele încorporate samples și engines. În directorul samples se află exemple de fișiere de configurare cu proprietăți de nod, precum și exemple de scripturi SQL pentru a începe rapid demonstrația.
În directorul samples vedem trei fișiere de configurare cu proprietăți de nod — numele arată caracterul nodului în cadrul unei scheme anume.
corp-000.properties
store-001.properties
store-002.propertiesSymmetricDS are toate fișierele de configurare necesare pentru o schemă de bază cu 3 noduri (varianta 1), iar aceleași fișiere pot fi folosite pentru o schemă cu 2 noduri (varianta 2). Copiem fișierul de configurare necesar din directorul samples în engines pe gazda vm1. Așadar:
$> 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=000Acest nod în configurația SymmetricDS se numește corp-000, iar conexiunea la baza de date este procesată de driverul mysql jdbc, care folosește șirul de conectare specificat mai sus și acreditivele de autentificare. Ne conectăm la baza de date replica_db, iar în timpul creării schemei vor fi create tabelele. sync.url arată locul de legătură cu nodul pentru sincronizare.
Nodul 2 de pe gazda vm2 este configurat ca store-001, iar restul este specificat în fișierul node.properties, care este prezentat mai jos. Nodul store-001 utilizează baza de date PostgreSQL, iar pgdb_replica este baza de date pentru replicare. registration.url permite gazdei vm2 să contacteze gazda vm1 și să obțină detalii despre configurație.
$> 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=001Exemplul complet de SymmetricDS conține parametrii pentru configurarea replicării bidirecționale între două servere de baze de date (două noduri). Pașii de mai jos sunt executați pe gazda vm1 (corp-000), care va crea un exemplu de schemă cu 4 tabele. Apoi, executarea comenzii create-sym-tables cu symadmin va crea tabelele de catalog, unde vor fi stocate regulile și direcția replicării între noduri. În final, vor fi încărcate datele de exemplu în tabele.
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 exemplu, tabelele item și item_selling_price sunt configurate automat pentru replicare din corp-000 în store-001, iar tabelele sale (sale_transaction și sale_return_line_item) sunt configurate automat pentru replicare din store-001 în corp-000. Acum creăm schema în baza de date PostgreSQL pe gazda vm2 (store-001) pentru a o pregăti să primească date de la corp-000.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xmlAsigură-te că în baza de date MySQL pe vm1 există exemple de tabele și tabele de catalog pentru SymmetricDS. Observați că tabelele de sistem SymmetricDS (cu prefixul sym_) sunt acum disponibile doar pe nodul corp-000, deoarece acolo am executat comanda create-sym-tables și vom gestiona replicarea. De asemenea, în baza de date de pe nodul store-001 vor fi doar 4 tabele de exemplu fără date.
Totul. Mediu este pregătit pentru a rula procesele serverului sym pe ambele noduri, așa cum este prezentat mai jos.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &Jurnalele sunt trimise într-un fișier de logare în fundal (symmetric.log) în folderul de log-uri din directorul unde este instalat SymmetricDS, precum și în ieșirea standard. Serverul sym poate fi acum inițiat pe nodul store-001.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &Dacă se rulează procesul server sym pe gazda vm2, acesta va crea tabelele directorului SymmetricDS și în baza de date PostgreSQL. Dacă se rulează procesul server sym pe ambele noduri, acestea se vor coordona între ele pentru a replica datele de la corp-000 la store-001. Dacă după câteva secunde cerem toate cele 4 tabele de ambele părți, vom vedea că replicarea a fost efectuată cu succes. Sau putem trimite o încărcătură inițială pe nodul store-001 din corp-000 folosind următoarea comandă.
vm1$> ./symadmin --engine corp-000 reload-node 001În acest moment, o nouă înregistrare este inserată în tabela item din baza de date MySQL de pe nodul corp-000 (gazdă: vm1), iar replica poate fi verificată în baza de date PostgreSQL de pe nodul store-001 (gazdă: vm2). Observăm operația Pull pentru a muta datele din corp-000 în store-001.
mysql> insert into item values ('22000002','Jelly Bean');
Interogare OK, 1 rând afectat (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 rânduri)Pentru a efectua operația Push pentru a muta datele din store-001 în corp-000, inserăm o înregistrare în tabela sale_transaction și verificăm că replicarea a fost efectuată.
Observăm configurarea reușită a replicării bidirecționale între tabelele exemple între bazele de date MySQL și PostgreSQL. Pentru a configura replicarea pentru tabelele noi ale utilizatorilor, efectuează următorii pași. Creăm tabela t1 pentru exemplu și configurăm regulile de replicare astfel. Așadar, configurăm doar replicarea din corp-000 în store-001.
mysql> create table t1 (no integer);
Interogare OK, 0 rânduri afectate (0.01 sec)mysql> insert into sym_channel (channel_id,create_time,last_update_time)
values ('t1',current_timestamp,current_timestamp);
Interogare OK, 1 rând afectat (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);
Interogare OK, 1 rând afectat (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);
Interogare OK, 1 rând afectat (0.01 sec)Apoi, configurația primește o notificare despre schimbarea schemei, adică adăugarea unei noi tabele, prin comanda symadmin cu argumentul sync-triggers, care recreează declanșatoarele pentru a se potrivi definițiilor tabelelor. Este executată comanda send-schema pentru a trimite modificările schemei la nodul store-001, iar replicarea tabelei t1 este configurată.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Avantajele SymmetricDS
Instalare și configurare simplă, inclusiv un set gata de fișiere cu parametrii pentru crearea schemei cu trei sau două noduri.
Interoperabilitate între baze de date și independență de platformă, incluzând servere, laptopuri și dispozitive mobile.
Replicarea oricărei baze de date în orice altă bază de date local, în WAN sau în cloud.
Capacitatea de a funcționa optim cu o pereche de baze de date sau chiar câteva mii pentru o replicare convenabilă.
Versiune plătită cu interfață grafică și suport excelent.
Dezavantajele SymmetricDS
Trebuie să definești manual în linia de comandă regulile și direcția replicării prin operatori SQL pentru a încărca tabelele de catalog, ceea ce poate fi incomod.
Configurarea multor tabele pentru replicare poate fi obositoare, dacă nu folosești scripturi pentru a crea operatori SQL care definesc regulile și direcția replicării.
În loguri se adună prea multe informații, iar uneori trebuie să organizezi fișierul de log pentru a nu ocupa prea mult spațiu.
Concluzii despre SymmetricDS
SymmetricDS permite configurarea replicării bidirecționale între două, trei și chiar câteva mii de noduri, pentru a efectua replicarea și sincronizarea fișierelor. Este un instrument unic care automatizează multe sarcini, de exemplu, recuperarea automată a datelor după o perioadă lungă de inactivitate a nodului, schimbul de date sigur și eficient între noduri prin HTTPS, gestionarea automată a conflictelor pe baza unui set de reguli etc. SymmetricDS efectuează replicarea între orice baze de date, așa că poate fi utilizat pentru cele mai diverse scenarii, inclusiv migrare, actualizare de versiune, distribuție, filtrare și transformare a datelor pe diferite platforme.
Exemplul a fost creat pe baza documentației oficiale pentru SymmetricDS. În sunt descrise în detaliu diverse concepte legate de configurarea replicării cu ajutorul SymmetricDS.
Sursa: habr.com
