Voi sublinia replicarea încrucișată între PostgreSQL și MySQL, precum și metodele de configurare a replicării încrucișate între cele două servere de baze de date. De obicei, bazele de date replicate încrucișate sunt numite omogene și este o metodă convenabilă de a trece de la un server RDBMS la altul.
Bazele de date PostgreSQL și MySQL sunt în general considerate relaționale, dar cu extensii suplimentare oferă capabilități NoSQL. Aici vom discuta despre replicarea dintre PostgreSQL și MySQL dintr-o perspectivă DBMS relațională.
Nu vom descrie întreaga funcționare interioară, ci doar principiile de bază, astfel încât să vă faceți o idee despre configurarea replicării între serverele de baze de date, avantaje, limitări și cazuri de utilizare.
În mod obișnuit, replicarea între două servere de baze de date identice se face fie în mod binar, fie folosind interogări între un master (a.k.a. editor, master sau activ) și un slave (abonat, standby sau pasiv). Scopul replicării este de a oferi o copie în timp real a bazei de date master pe partea slave. În acest caz, datele sunt transferate de la master la slave, adică de la activ la pasiv, deoarece replicarea se realizează doar într-o singură direcție. Dar puteți configura replicarea între două baze de date în ambele direcții, astfel încât datele să fie transferate de la slave la master într-o configurație activ-activ. Toate acestea, inclusiv replicarea î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, de disponibilitatea unor astfel de capabilități în configurația inițială sau de utilizarea soluțiilor de configurare externe și de compromisurile existente.
Configurația descrisă este posibilă între diferite servere de baze de date. Serverul poate fi configurat să accepte date replicate de la un alt server de bază de date și să mențină în continuare instantanee în timp real ale datelor replicate. MySQL și PostgreSQL oferă majoritatea acestor configurații interne sau prin extensii terțe, inclusiv metode binare de jurnal, blocarea discului și metode bazate pe instrucțiuni și rânduri.
Replicarea încrucișată între MySQL și PostgreSQL este necesară pentru o migrare unică de la un server de baze de date la altul. Aceste baze de date folosesc protocoale diferite, deci nu este posibil să le conectați direct. Pentru a stabili un schimb de date, puteți utiliza un instrument extern open source, de exemplu pg_chameleon.
Ce este pg_chameleon
pg_chameleon este un sistem de replicare de la MySQL la PostgreSQL în Python 3. Utilizează biblioteca open source mysql-replication, tot în Python. Imaginile rând sunt extrase din tabelele MySQL și stocate ca obiecte JSONB în baza de date PostgreSQL, apoi decriptate de funcția pl/pgsql și reproduse în baza de date PostgreSQL.
Caracteristicile pg_chameleon
Mai multe scheme MySQL din același cluster pot fi replicate într-o singură bază de date PostgreSQL țintă într-o configurație unu-la-mulți
Numele schemei sursă și țintă nu pot fi aceleași.
Datele de replicare pot fi preluate dintr-o replică MySQL în cascadă.
Sunt excluse tabelele care nu pot replica sau produce erori.
Fiecare funcție de replicare este controlată de daemoni.
Control prin parametrii bazați pe YAML și fișierele de configurare.
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
Port DB
3306
5433
Adresa IP
192.168.56.102
192.168.56.106
Pentru a începe, pregătiți toate componentele necesare pentru a instala pg_chameleon. Acest exemplu instalează Python 3.6.8, care creează și activează mediul 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 altinstallDupă instalarea cu succes a Python3.6, trebuie să îndepliniți cerințele rămase, cum ar fi crearea și activarea unui mediu virtual. În plus, modulul pip este actualizat la cea mai recentă versiune și folosit pentru a instala pg_chameleon. Comenzile de mai jos instalează în mod intenționat pg_chameleon 2.0.9, deși cea mai recentă versiune este 2.0.10. Acest lucru este necesar pentru a evita noi erori în 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 este o comandă) cu argumentul set_configuration_files pentru a activa pg_chameleon și a crea directoare implicite și fișiere de configurare.
(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.ymlAcum creăm o copie a config-example.yml ca default.yml, astfel încât să devină fișierul de configurare implicit. Un exemplu de fișier de configurare pentru acest exemplu este furnizat mai jos.
$> 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:Fișierul de configurare din acest exemplu este un exemplu de fișier pg_chameleon cu modificări minore pentru a se potrivi mediilor sursă și țintă, iar mai jos este 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 puteți gestiona setări precum locația fișierului de blocare, locația jurnalelor, perioada de stocare a jurnalelor etc. Urmează secțiunea de înlocuire a tipului, unde un set de reguli pentru suprascrierea tipurilor în timpul replicării. Exemplul este implicit la o regulă de suprascriere a tipului care convertește tinyint(1) într-o valoare booleană. În secțiunea următoare, specificăm detaliile conexiunii la baza de date țintă. În cazul nostru, aceasta este o bază de date PostgreSQL, denumită pg_conn. În ultima secțiune, indicăm datele sursă, adică parametrii de conectare ai bazei de date sursă, schema de mapare între bazele de date sursă și țintă, tabele care trebuie sărite, timpul de așteptare, memoria, dimensiunea pachetului. Rețineți că „surse” este plural, ceea ce înseamnă că putem adăuga mai multe baze de date sursă la o singură bază de date țintă pentru a configura o configurație multi-la-unu.
Baza de date exemplu world_x conține 4 tabele cu rânduri pe care comunitatea MySQL le oferă ca exemple. Poate fi descărcat . Eșantionul de bază de date vine ca o arhivă tar și comprimată cu instrucțiuni pentru crearea și importarea rândurilor.
În bazele de date MySQL și PostgreSQL, este creat un utilizator special cu același nume usr_replica. În MySQL, i se acordă drepturi de citire suplimentare pentru toate tabelele 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, este creată o bază de date db_replica care va accepta modificări din baza de date MySQL. Utilizatorul usr_replica din PostgreSQL este configurat automat ca proprietar a două scheme, pgworld_x și sch_chameleon, care conțin tabelele replicate reale și, respectiv, tabelele directorului de replicare. Argumentul create_replica_schema este responsabil pentru configurarea automată, după 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 unele modificări ale parametrilor pentru a o pregăti pentru replicare, așa cum se arată mai jos. Va trebui să reporniți serverul bazei 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, astfel încât să nu existe probleme la rularea 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 (cameleon) pregătesc mediul, adaugă sursa și inițializează replica. Argumentul create_replica_schema pentru pg_chameleon creează o schemă implicită (sch_chameleon) și o schemă de replicare (pgworld_x) în baza de date PostgreSQL, așa cum am discutat deja. Argumentul add_source adaugă o bază de date sursă la configurație citind fișierul de configurare (default.yml), iar în cazul nostru este mysql, iar init_replica inițializează configurația pe baza parametrilor din fișierul de configurare.
$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debugIeșirea acestor trei comenzi indică clar că au fost executate cu succes. Orice blocări sau erori de sintaxă sunt raportate în mesaje simple și clare, cu indicii despre cum să remediați problema.
În cele din urmă, începem replicarea folosind start_replica și primim un mesaj de succes.
$> chameleon start_replica --config default --source mysql
output: Starting the replica process for source mysqlStarea de replicare poate fi interogată folosind argumentul show_status, iar erorile pot fi vizualizate folosind argumentul show_errors.
După cum am spus deja, fiecare funcție de replicare este controlată de demoni. Pentru a le vizualiza, interogăm tabelul de proces cu comanda Linux ps, așa cum se arată mai jos.
Replicarea nu este considerată configurată până când nu o testăm în timp real, așa cum se arată mai jos. Creăm un tabel, inserăm câteva înregistrări în baza de date MySQL și apelăm argumentul sync_tables în pg_chameleon pentru a actualiza demonii și a replica tabelul cu înregistrările î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
Sync tables process for source mysql started.Pentru a confirma rezultatele testului, interogăm tabelul din baza de date PostgreSQL și scoatem rândurile.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | one
2 | twoDacă facem o migrare, următoarele comenzi pg_chameleon vor fi sfârșitul acesteia. Comenzile trebuie să fie executate după ce suntem siguri că rândurile tuturor tabelelor țintă au fost replicate, iar rezultatul va fi o bază de date PostgreSQL migrată cu grijă, fără referințe la baza de date sursă sau schema de replicare (sch_chameleon).
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugDacă doriți, puteți utiliza următoarele comenzi pentru a șterge 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 configurare ușoară.
Depanați și identificați cu ușurință anomaliile cu mesaje de eroare clare.
Tabelele speciale suplimentare pot fi adăugate la replicare după inițializare fără a modifica restul configurației.
Este posibil să configurați mai multe baze de date sursă pentru o singură bază de date țintă și acest lucru este foarte util dacă combinați date dintr-una sau mai multe baze de date MySQL într-o singură bază de date PostgreSQL.
Nu trebuie să replicați tabelele selectate.
Dezavantajele pg_chameleon
Acceptat numai cu MySQL 5.5 și versiuni ulterioare ca sursă și PostgreSQL 9.5 și versiuni ulterioare ca bază de date țintă.
Fiecare tabel trebuie să aibă o cheie primară sau unică, altfel tabelele sunt inițializate în timpul procesului init_replica, dar nu sunt replicate.
Replicare unidirecțională - numai de la MySQL la PostgreSQL. Prin urmare, este potrivit doar pentru circuitul „activ-pasiv”.
Sursa poate fi doar o bază de date MySQL, iar suportul pentru o bază de date PostgreSQL ca sursă este doar experimental și cu limitări (aflați mai multe )
Rezultate pentru pg_chameleon
Metoda de replicare din pg_chameleon este excelentă pentru migrarea unei baze de date de la MySQL la PostgreSQL. Dezavantajul semnificativ este că replicarea este doar unidirecțională, așa că este puțin probabil ca profesioniștii în baze de date să vrea să o folosească pentru altceva decât pentru migrare. Dar problema replicării unidirecționale poate fi rezolvată cu un alt instrument open source - SymmetricDS.
Citiți mai multe în documentația oficială . Ajutorul din linia de comandă poate fi găsit .
Prezentare generală a SymmetricDS
SymmetricDS este un instrument open source care reproduce orice bază de date în orice altă bază de date comună: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird și alte instanțe de baze de date în cloud, de exemplu Redshift și Azure, etc. Caracteristici disponibile: sincronizare baze de date și fișiere, replicare a bazei de date multi-master, sincronizare filtrată, transformare și altele. Acesta este un instrument Java și necesită o versiune standard a JRE sau JDK (versiunea 8.0 sau mai mare). Aici, modificările datelor aduse declanșatorilor din baza de date sursă pot fi înregistrate și trimise la baza de date țintă corespunzătoare sub formă de loturi.
Caracteristici SymmetricDS
Instrumentul este independent de platformă, ceea ce înseamnă că două sau mai multe baze de date diferite pot face schimb de date.
Bazele de date relaționale sunt sincronizate folosind înregistrările de modificare a datelor, în timp ce bazele de date bazate pe sisteme de fișiere folosesc sincronizarea fișierelor.
Replicare bidirecțională folosind metode Push și Pull bazate pe un set de reguli.
Transferul de date este posibil prin rețele sigure și cu lățime de bandă redusă.
Recuperare automată atunci când nodurile își reiau funcționarea după o defecțiune și rezolvarea automată a conflictelor.
API-uri de extensie puternice și compatibile cu cloud.
Exemplu
SymmetricDS poate fi configurat în una dintre două opțiuni:
Un nod master (părinte) care coordonează central replicarea datelor între două noduri slave (copil), iar comunicarea între nodurile copil are loc numai prin intermediul părintelui.
Un nod activ (Nodul 1) poate comunica pentru replicare cu un alt nod activ (Nodul 2) fără un intermediar.
În ambele opțiuni, schimbul de date are loc utilizând Push și Pull. În acest exemplu vom lua în considerare o configurație activ-activ. Ar dura prea mult pentru a descrie întreaga arhitectură, așa că faceți-vă cercetarea. pentru a afla mai multe despre dispozitivul SymmetricDS.
Instalarea SymmetricDS este foarte simplă: descărcați versiunea open source a fișierului zip și scoate-l oriunde vrei. Tabelul de mai jos oferă informații despre locația de instalare și versiunea SymmetricDS în acest exemplu, precum și versiunile bazei de date, versiunile Linux, adresele IP și porturile 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
Port DB
3306
5832
Adresa 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
magazin-001
Aici instalăm SymmetricDS în /usr/local/symmetric-server-3.9.20, iar acolo vor fi stocate diverse subdirectoare și fișiere. Suntem interesați de subdirectoarele de mostre și motoare. Directorul de mostre conține exemple de fișiere de configurare cu proprietăți de nod, precum și exemple de scripturi SQL pentru a începe rapid.
În directorul de mostre vedem trei fișiere de configurare cu proprietăți ale nodului - numele arată natura nodului într-o anumită schemă.
corp-000.properties
store-001.properties
store-002.propertiesSymmetricDS are toate fișierele de configurare necesare pentru un design de bază cu 3 noduri (opțiunea 1), iar aceleași fișiere pot fi utilizate pentru un design cu 2 noduri (opțiunea 2). Copiați fișierul de configurare necesar din directorul de mostre în motoarele de pe gazda vm1. Se dovedește așa:
$> 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 din configurația SymmetricDS se numește corp-000, iar conexiunea la baza de date este gestionată de driverul mysql jdbc, care utilizează șirul de conexiune de mai sus și acreditările de conectare. Ne conectăm la baza de date replica_db și tabelele vor fi create în timpul creării schemei. sync.url arată locația conexiunii la nodul pentru sincronizare.
Nodul 2 de pe gazda vm2 este configurat ca store-001, iar restul este specificat în fișierul node.properties de mai jos. Node store-001 rulează baza de date PostgreSQL și pgdb_replica este baza de date de replicare. registration.url permite gazdei vm2 să contacteze gazda vm1 și să primească detalii de configurare de la aceasta.
$> 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 SymmetricDS completat conține parametri pentru configurarea replicării bidirecționale între două servere de baze de date (două noduri). Pașii de mai jos sunt efectuati pe gazda vm1 (corp-000), care va crea un exemplu de schemă cu 4 tabele. Apoi rularea create-sym-tables cu comanda symadmin creează tabele directoare în care vor fi stocate regulile și direcția de replicare între noduri. În cele din urmă, mostrele de date sunt încărcate î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 a se replica de la corp-000 la store-001, iar tabelele de vânzare (sale_transaction și sale_return_line_item) sunt configurate automat pentru a se replica de la magazin-001 la corp-000. Acum creăm o schemă î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.xmlAsigurați-vă că verificați dacă baza de date MySQL de pe vm1 are exemple de tabele și tabele de catalog SymmetricDS. Rețineți că tabelele de sistem SymmetricDS (prefixate cu sym_) sunt în prezent disponibile numai pe nodul corp-000, deoarece acolo am rulat comanda create-sym-tables și vom gestiona replicarea. Și în baza de date de pe nodul store-001 vor exista doar 4 exemple de tabele fără date.
Toate. Mediul este pregătit pentru a rula procesele server sym pe ambele noduri, așa cum se arată mai jos.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &Intrările de jurnal sunt trimise într-un fișier jurnal de fundal (symmetric.log) în folderul jurnal din directorul în care este instalat SymmetricDS, precum și la 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ă rulați procesul de server sym pe gazda vm2, acesta va crea și tabele de catalog SymmetricDS în baza de date PostgreSQL. Dacă rulați procesul de server sym pe ambele noduri, acestea se coordonează între ele pentru a replica datele de la corp-000 la store-001. Dacă după câteva secunde interogăm toate cele 4 tabele pe ambele părți, vom vedea că replicarea a avut succes. Sau puteți trimite bootstrap-ul la nodul store-001 de la corp-000 cu următoarea comandă.
vm1$> ./symadmin --engine corp-000 reload-node 001În acest moment, o nouă înregistrare este inserată în tabelul de articole din baza de date MySQL pe nodul corp-000 (gazdă: vm1) și puteți verifica replicarea acesteia în baza de date PostgreSQL pe nodul magazin-001 (gazdă: vm2). Vedem o operație Pull pentru a muta datele de la corp-000 la 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)Pentru a efectua o operațiune Push pentru a muta datele de la store-001 la corp-000, inserăm o înregistrare în tabelul sale_transaction și verificăm că replicarea are succes.
Vedem configurarea cu succes a replicării în două sensuri a exemplelor de tabele între bazele de date MySQL și PostgreSQL. Pentru a configura replicarea pentru noi tabele de utilizatori, urmați acești pași: De exemplu, creăm tabelul t1 și îi configuram regulile de replicare după cum urmează. În acest fel configuram doar replicarea de la corp-000 la 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)Configurația este apoi notificată cu privire la modificarea schemei, adică adăugarea unui nou tabel, folosind comanda symadmin cu argumentul sync-triggers, care recreează declanșatorii pentru a mapa definițiile tabelului. send-schema este executat pentru a trimite modificări de schemă către nodul store-001, iar replicarea tabelului t1 este configurată.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Beneficiile SymmetricDS
Instalare și configurare ușoară, inclusiv un set gata de fișiere cu parametri pentru crearea unui circuit cu trei sau două noduri.
Baze de date multiplatforme și independență de platformă, inclusiv servere, laptopuri și dispozitive mobile.
Replicați orice bază de date în orice altă bază de date local, pe WAN sau în cloud.
Posibilitatea de a lucra optim cu câteva baze de date sau câteva mii pentru o replicare convenabilă.
Versiune plătită cu GUI și suport excelent.
Dezavantajele SymmetricDS
Trebuie să definiți manual regulile și direcția de replicare pe linia de comandă prin instrucțiuni SQL pentru a încărca tabele de catalog, ceea ce poate fi incomod.
Configurarea multor tabele pentru replicare poate fi plictisitoare dacă nu utilizați scripturi pentru a crea instrucțiuni SQL care definesc regulile și direcția de replicare.
Există prea multe informații care sunt înregistrate în jurnale și, uneori, trebuie să faceți ordine în fișierul jurnal, astfel încât să nu ocupe prea mult spațiu.
Rezultate pentru SymmetricDS
SymmetricDS vă permite să configurați o replicare bidirecțională între două, trei sau chiar câteva mii de noduri pentru a replica și sincroniza fișierele. Acesta este un instrument unic care realizează în mod independent multe sarcini, cum ar fi recuperarea automată a datelor după o perioadă lungă de oprire a unui nod, schimbul de date sigur și eficient între noduri prin HTTPS, gestionarea automată a conflictelor pe baza unui set de reguli etc. SymmetricDS efectuează replicare între orice baze de date, prin urmare, poate fi utilizat pentru o mare varietate de scenarii, inclusiv migrarea, migrarea, distribuția, filtrarea și transformarea datelor pe platforme.
Exemplul se bazează pe oficial de SymmetricDS. ÎN Descrie în detaliu diferitele concepte implicate în configurarea replicării cu SymmetricDS.
Sursa: www.habr.com