Krusteniskā replikācija starp PostgreSQL un MySQL

Es sniegšu vispārīgu pārskatu par krustreplicāciju starp PostgreSQL un MySQL, kā arī par iestatīšanas metodēm krustreplicācijai starp šīm divām datubāzu serveriem. Parasti datubāzes krustreplicācijā tiek uzskatītas par homogēnām, un tas ir ērts veids, kā pāriet no viena relāciju DB servera uz citu.

PostgreSQL un MySQL datubāzes tiek uzskatītas par relāciju, taču ar papildu paplašinājumiem tās piedāvā iespējas NoSQL. Šeit mēs apspriedīsim replicēšanu starp PostgreSQL un MySQL, no relāciju DB skatupunkta.

Mēs nepiedāvāsim detalizētu iekšējo informāciju, tikai pamata principus, lai jūs iegūtu priekšstatu par replicēšanas iestatīšanu starp datubāzu serveriem, priekšrocībām, ierobežojumiem un lietošanas scenārijiem.

Parasti replicēšana starp diviem identiskiem datubāzu serveriem tiek veikta vai nu binārā režīmā, vai izmantojot vaicājumus starp vadības mezglu (kas ir izdevējs, galvenais vai aktīvais) un sekotāju (abonents, gaidītājs vai pasīvais). Replicēšanas mērķis ir nodrošināt reāllaika galveno datubāzi sekotāja pusē. Dati tiek pārsūtīti no vadītāja uz sekotāju, tātad no aktīvā uz pasīvo, jo replicēšana tiek veikta tikai vienā virzienā. Tomēr ir iespējams iestatīt replicēšanu starp divām datubāzēm abos virzienos, lai dati tiktu pārsūtīti no sekotāja uz vadītāju aktīvo-aktīvo konfigurācijā. Viss tas, tostarp kaskādes replicēšana, ir iespējama starp diviem vai vairākiem identiskiem datubāzu serveriem. Aktīvo-aktīvo vai aktīvu-pasīvo konfigurācija ir atkarīga no vajadzībām, pieejamības šādām iespējām sākotnējā konfigurācijā vai no ārējo risinājumu izmantošanas iestatīšanai un esošajiem kompromisiem.

Aprakstītā konfigurācija ir iespējama starp dažādiem datubāzu serveriem. Serveri var iestatīt, lai saņemtu replikētus datus no cita datubāzu servera, vienlaikus saglabājot replikējamo datu reālās laika attēlus. MySQL un PostgreSQL piedāvā lielāko daļu no šīm konfigurācijām paši vai ar trešo pušu paplašinājumiem, tostarp binārā žurnāla, diska bloķēšanas un operatoru un rindu bāzes metodēm.

Krusta replikācija starp MySQL un PostgreSQL ir nepieciešama vienreizējai migrācijai no viena datubāzu servera uz citu. Šīs datubāzes izmanto atšķirīgus protokolus, tāpēc tās nevar tieši savienot. Lai izveidotu datu apmaiņu, varat izmantot ārēju atvērtā koda rīku, piemēram, pg_chameleon.

Kas ir pg_chameleon

pg_chameleon ir replikācijas sistēma no MySQL uz PostgreSQL, kas izstrādāta Python 3 valodā. Tajā tiek izmantota atvērtā koda bibliotēka mysql-replication, kas arī ir uz Python. Rindu attēli tiek izvilkti no MySQL tabulām un saglabāti kā JSONB objekti PostgreSQL datubāzē, pēc tam tos atšifrē pl/pgSQL funkcija un reproducē PostgreSQL datubāzē.

pg_chameleon iespējas

Vairākas MySQL shēmas no viena klastera var replikēt vienā mērķa PostgreSQL datubāzē ar konfigurāciju "viens pret daudziem".
Sākotnes un mērķa shēmu nosaukumi nedrīkst sakrist.
Replikācijas datus var izvilkt no MySQL kaskādes replikācijas.
Tabulas, kuras nevar replikēt vai kurām rodas kļūdas, tiek izslēgtas.
Katru replikācijas funkciju pārvalda demoni.
Kontrole, izmantojot parametrus un konfigurācijas failus, kas balstīti uz YAML.

uzbrukumam

Host
vm1
vm2

OS versija
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

DB servera versija
MySQL 5.7.26
PostgreSQL 10.5

DB ports
3306
5433

IP adrese
192.168.56.102
192.168.56.106

Pirms uzsākat, sagatavojiet visus nepieciešamos komponentus pg_chameleon uzstādīšanai. Šajā piemērā ir instalēta Python 3.6.8, kas rada virtuālo vidi un aktivizē to.

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

Pēc veiksmīgas Python3.6 uzstādīšanas ir jāizpilda pārējās prasības, piemēram, jāizveido un jāaktivē virtuāla vide. Turklāt pip modulis tiek atjaunināts uz jaunāko versiju un tiek izmantots pg_chameleon uzstādīšanai. Zemāk norādītajās komandās tiek mērķtiecīgi instalēta pg_chameleon 2.0.9, lai gan jaunākā versija ir 2.0.10. Tas tiek darīts, lai izvairītos no jaunām kļūdām atjaunotajā versijā.

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

Pēc tam mēs izsaucam pg_chameleon (chameleon ir komanda) ar argumentu set_configuration_files, lai aktivizētu pg_chameleon un izveidotu noklusējuma konfigurācijas katalogus un failus.

(venv) $> chameleon set_configuration_files
izveido katalogu /root/.pg_chameleon
izveido katalogu /root/.pg_chameleon/configuration/
izveido katalogu /root/.pg_chameleon/logs/
izveido katalogu /root/.pg_chameleon/pid/
kopē konfigurācijas piemēru uz /root/.pg_chameleon/configuration//config-example.yml

Tagad mēs veidojam config-example.yml kopiju kā default.yml, lai tā kļūtu par noklusējuma konfigurācijas failu. Zemāk ir paraugs konfigurācijas faila šim piemēram.

$> cat default.yml
---
#globālās iestatījumi
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 ļauj lietotājam pārdefinēt noklusējuma tipu pārvēršanu citā.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

#postgres mērķa savienojums
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 #izlaiž ievades tabulā delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #izlaiž dzēšanas operācijas shēmā delphis_mediterranea
      update:

Šī piemēra konfigurācijas fails ir paraugs failam ar pg_chameleon, kam ir nelielas izmaiņas attiecībā pret avota un mērķa vidēm, un zemāk ir sniegts dažādu konfigurācijas faila daļu pārskats.

Konfigurācijas failā default.yml ir globālo iestatījumu daļa, kurā varat pārvaldīt tādas iestatījumu lietas kā bloķēšanas faila atrašanās vieta, loģu atrašanās vieta, loģu glabāšanas periods utt. Tālāk ir iestatījumu pārvietošanas daļa (type override), kurā ir norādīts noteikumu kopums, kā pārdefinēt tipus replikācijas laikā. Noklusējuma piemērā tiek izmantots pārvietošanas noteikums, kas pārvērš tinyint(1) par loģisko vērtību. Nākamajā daļā norādiet savienojuma detaļas uz mērķa datu bāzi. Mūsu gadījumā tā ir PostgreSQL datu bāze, ko apzīmē pg_conn. Pēdējā daļā norādām avota datus, proti, avota datu bāzes savienojuma parametrus, avota un mērķa datu bāzes shēmas saskaņošanu, tabulas, kuras jāizlaiž, gaidīšanas laiku, atmiņu, pakotnes lielumu. Ievērojiet, ka „sources“ ir norādīts daudzskaitlī, t.i., mēs varam pievienot vairākas avota datu bāzes vienai mērķa datu bāzei, lai pielāgotu konfigurāciju „daudzi uz vienu“.

Datubāze world_x piemērā satur 4 tabulas ar rindām, kuras MySQL kopiena piedāvā kā piemēru. To var lejupielādēt šeit. Piemēra datubāze tiek piegādāta kā tar un saspiests archives ar instrukcijām rindas izveidei un importēšanai.

MySQL un PostgreSQL datubāzēs tiek izveidots īpašs lietotājs ar vienādu nosaukumu usr_replica. MySQL viņam piešķir papildu tiesības lasīt visas replikējamas tabulas.

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;

PostgreSQL pusē tiek izveidota datubāze db_replica, kas pieņems izmaiņas no MySQL datubāzes. Lietotājs usr_replica PostgreSQL automātiski tiek iestatīts kā divu shēmu pgworld_x un sch_chameleon īpašnieks, kuras satur attiecīgi faktiskās replikētās tabulas un replikācijas katalogu tabulas. Automātisko konfigurāciju nodrošina arguments create_replica_schema, kā jūs redzēsit zemāk.

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

MySQL datubāze tiek konfigurēta, mainot dažus parametrus, lai to sagatavotu replikācijai, kā parādīts zemāk. Būs nepieciešams restartēt datubāzu serveri, lai izmaiņas stātos spēkā.

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

Šobrīd ir svarīgi pārbaudīt savienojumu ar abiem datubāzu serveriem, lai izpildot komandas pg_chameleon neradītu problēmas.

PostgreSQL mezglā:

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

MySQL mezglā:

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

Nākamās trīs pg_chameleon (chameleon) komandas sagatavo vidi, pievieno avotu un inicializē replikāciju. Arguments create_replica_schema pg_chameleon izveido noklusējuma shēmu (sch_chameleon) un replikācijas shēmu (pgworld_x) PostgreSQL datubāzē, kā jau tika minēts. Arguments add_source pievieno avota datubāzi konfigurācijai, izlasot konfigurācijas failu (default.yml), un mūsu gadījumā tas ir mysql, bet init_replica inicializē konfigurāciju, balstoties uz parametriem konfigurācijas failā.

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

Šo trīs komandu izvadē redzams to veiksmīgas izpildes apliecinājums. Visas kļūdas vai sintaksiskas kļūdas tiek norādītas vienkāršos un saprotamos ziņojumos ar ieteikumiem problēmu novēršanai.

Visbeidzot, uzsāksim replikāciju, izmantojot start_replica, un saņemsim ziņojumu par veiksmīgu izpildi.

$> chameleon start_replica --config default --source mysql 
izvade: Replikācijas procesa uzsākšana avotam mysql

Replikācijas statusu var pieprasīt, izmantojot argumentu show_status, bet kļūdas var apskatīt, izmantojot argumentu show_errors.

Rezultāts.

Kā jau minējām, katru replikācijas funkciju pārvalda dēmoni. Lai tos apskatītu, pieprasīsim procesu tabulu ar Linux komandu ps, kā parādīts zemāk.

Rezultāts.

Replikācija netiek uzskatīta par iestatītu, līdz to neesam pārbaudījuši reālajā laikā, kā parādīts zemāk. Mēs izveidojam tabulu, ievietojam pāris ierakstus MySQL datubāzē un izmantojam argumentu sync_tables, lai atjauninātu dēmonus un replikētu tabulu ar ierakstiem PostgreSQL datubāzē.

mysql> create table t1 (n1 int primary key, n2 varchar(10));
Vaicājums apstiprināts, 0 rindu ietekmēts (0.01 sek)
mysql> insert into t1 values (1,'one');
Vaicājums apstiprināts, 1 rinda ietekmēta (0.00 sek)
mysql> insert into t1 values (2,'two');
Vaicājums apstiprināts, 1 rinda ietekmēta (0.00 sek)

$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Sync tables process for source mysql started.

Lai apstiprinātu testa rezultātus, pieprasām tabulu no PostgreSQL datubāzes un izvadām rindas.

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

Ja mēs veicam migrāciju, šīs komandas pg_chameleon būs tās pabeigšana. Komandas jāizpilda pēc tam, kad mēs esam pārliecinājušies, ka visas mērķa tabulu rindas ir replikētas, un rezultātā būs rūpīgi pārnesta PostgreSQL datubāze bez atsaucēm uz sākotnējo datubāzi vai replikācijas shēmu (sch_chameleon).

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

Pēc vēlēšanās, sekojošās komandas var izdzēst oriģinālo konfigurāciju un replikācijas shēmu.

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

pg_chameleon priekšrocības

Vienkārša uzstādīšana un konfigurācija.
Uzņēmīgas un saprotamas kļūdu ziņojumu novēršana un anomāliju noteikšana.
Replikācijai var pievienot papildu speciālas tabulas pēc inicializēšanas, nemainot pārējo konfigurāciju.
Ir iespējams iestatīt vairākas avota datu bāzes vienai mērķa datu bāzei, un tas ir ļoti ērti, ja apvienojat datus no vienas vai vairākām MySQL datu bāzēm vienā PostgreSQL datu bāzē.
Izvēlētās tabulas var nereplicēt.

pg_chameleon trūkumi

Atbalsts ir tikai MySQL 5.5 vai jaunākām versijām kā avotam un PostgreSQL 9.5 vai jaunākām versijām kā mērķa datu bāzei.
Katram tabulā jābūt primārajam vai unikālajam atslēga, pretējā gadījumā tabulas tiek inicializētas init_replica procesā, bet netiek replikētas.
Vienvirziena replikācija — tikai no MySQL uz PostgreSQL. Tādēļ tā ir piemērota tikai 'aktīvā-pasīvā' shēmai.
Avots var būt tikai MySQL datu bāze, bet PostgreSQL datu bāzes atbalsts kā avots ir tikai eksperiments ar ierobežojumiem (uzziniet vairāk šeit)

Secinājumi par pg_chameleon

Replikācijas metode pg_chameleon lieliski der MySQL datu bāzes migrēšanai uz PostgreSQL. Būtisks trūkums ir tas, ka replikācija ir tikai vienvirziena, tāpēc datu speciālisti, visticamāk, nevēlēsies to izmantot nekam citam, kā tikai migrācijai. Taču vienvirziena replikācijas problēmu var atrisināt ar vēl vienu atvērtā koda rīku — SymmetricDS.

Sīkāk lasiet oficiālajā dokumentācijā šeit. Komandlīnijas rokasgrāmatu var atrast šeit.

SymmetricDS pārskats

SymmetricDS — tas ir atvērtā koda rīks, kas replikē jebkuru datu bāzi uz jebkuru citu populāru datu bāzi: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird un citas mākoņa datu bāzes instancē, piemēram, Redshift un Azure utt. Pieejamās funkcijas: datu un failu sinhronizācija, vairāku vadošo datu bāzu replikācija, filtrēta sinhronizācija, pārveidošana un citas. Tas ir Java rīks, un nepieciešama standarta JRE vai JDK izdošana (versijas 8.0 vai jaunākas). Šeit var reģistrēt datu izmaiņas uz trigeriem avota datu bāzē un nosūtīt tos attiecīgajā mērķa datu bāzē pakotnēs.

SymmetricDS iespējas

Rīks nav atkarīgs no platformas, tas ir, divas vai vairākas dažādas datu bāzes var apmainīties ar datiem.
Relatīvās datu bāzes tiek sinhronizētas, izmantojot datu izmaiņu ierakstus, bet failu sistēmu datu bāzes izmanto failu sinhronizāciju.
Divvirzienu replikācija, izmantojot Push un Pull metodes, pamatojoties uz noteikumu kopu.
Datu pārsūtīšana ir iespējama aizsargātās un zema caurlaidspējas tīklos.
Automātiska atjaunošana, atsākot mezglu darbu pēc kļūdes, un automātiska konfliktu risināšana.
Saderība ar mākoņiem un efektīvi paplašinājumi API.

uzbrukumam

SymmetricDS var konfigurēt divos variantos:
Vadošais (vecāks) mezgls, kas centralizēti koordinē datu replikāciju starp diviem pakārtotajiem (bērnu) mezgliem, un datu apmaiņa starp bērnu mezgliem notiek tikai caur vecāko.
Aktīvs mezgls (mezgls 1) var apmainīties ar datiem replikācijai ar citu aktīvo mezglu (mezgls 2) bez starpnieka.

Abos variantos datu apmaiņa notiek ar Push un Pull. Šajā piemērā aplūkosim konfigurāciju "aktīvs-aktīvs". Pilnīga arhitektūras aprakstīšana ir pārāk gara, tāpēc izpētiet rokasgrāmatu, lai uzzinātu vairāk par SymmetricDS ierīci.

Instalēt SymmetricDS ir ļoti viegli: lejupielādējiet atvērtā koda zip failu no šejienes un izvelciet to, kur vien vēlaties. Zemāk esošajā tabulā sniegta informācija par instalācijas vietu un versijām SymmetricDS šajā piemērā, kā arī datu bāzu versijas, Linux versijas, IP adreses un ostas abiem mezgliem.

Host
vm1
vm2

OS versija
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

DB servera versija
MySQL 5.7.26
PostgreSQL 10.5

DB ports
3306
5832

IP adrese
192.168.1.107
192.168.1.112

SymmetricDS versija
SymmetricDS 3.9
SymmetricDS 3.9

SymmetricDS instalācijas ceļš
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

SymmetricDS mezgla nosaukums
corp-000
store-001

Šeit mēs instalējam SymmetricDS vietā /usr/local/symmetric-server-3.9.20, un šeit tiks glabāti dažādi apakšdirektoriji un faili. Mūs interesē apakšdirektoriji samples un engines. Direktīva samples satur konfidenciālo failu piemērus ar mezga īpašībām, kā arī SQL skriptu piemērus ātrai demonstrācijas uzsākšanai.

Direktorijā samples redzam trīs konfidenciālo failu piemērus ar mezga īpašībām — nosaukums norāda uz mezga raksturu noteiktā shēmā.

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

SymmetricDS ir visi nepieciešamie konfigurācijas faili pamata shēmai ar 3 mezgliem (variants 1), un tos pašus failus var izmantot 2 mezglu shēmā (variants 2). Nokopējam nepieciešamo konfigurācijas failu no samples direktorijas uz engines vietā vm1. Tas izskatās šādi:

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

Šis mezgls SymmetricDS konfigurācijā tiek dēvēts par corp-000, un pieslēgšanos datu bāzei apstrādā mysql jdbc draiveris, kas izmanto iepriekš norādīto savienojuma virkni un pieslēgšanās akreditīvus. Mēs pieslēdzamies datu bāzei replica_db, un, veidojot shēmu, tiks izveidotas tabulas. sync.url norāda saiti uz mezglu sinhronizācijai.

Mezgls 2 uz vm2 hosta tiek konfigurēts kā store-001, bet pārējais ir norādīts node.properties failā, kurš ir dots zemāk. Mezgls store-001 izmanto PostgreSQL datu bāzi, bet pgdb_replica ir datu bāze replikācijai. registration.url ļauj vm2 hostam sazināties ar vm1 hostu un iegūt no tā konfigurācijas detaļas.

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

Gatavais SymmetricDS piemērs satur parametrus, lai konfigurētu divvirzienu replikāciju starp divām datu bāzu serveriem (diviem mezgliem). Zemāk norādītie soļi tiek veikti uz vm1 hosta (corp-000), kas izveidos shēmas piemēru ar 4 tabulām. Pēc tam komandai create-sym-tables, ko izpilda symadmin, tiek izveidotas katalogu tabulas, kur tiks glabātas noteikumi un replikācijas virziens starp mezgliem. Visbeidzot, tabulās tiek ielādēti piemēra dati.

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

Piemērā tabulas item un item_selling_price automātiski iestatītas replikācijai no corp-000 uz store-001, bet tabulas sale (sale_transaction un sale_return_line_item) automātiski iestatītas replikācijai no store-001 uz corp-000. Tagad izveidojam shēmu PostgreSQL datu bāzē uz vm2 (store-001), lai sagatavotu to datu pieņemšanai no corp-000.

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

Obligāti jāpārbauda, ka MySQL datu bāzē uz vm1 ir piemēru tabulas un SymmetricDS katalogu tabulas. Ņemiet vērā, ka SymmetricDS sistēmas tabulas (ar prefiksu sym_) šobrīd ir pieejamas tikai mezglā corp-000, jo tur mēs izpildījām komandu create-sym-tables un pārvaldīsim replikāciju. Turklāt datu bāzē uz mezglu store-001 būs tikai 4 piemēru tabulas bez datiem.

Viss. Vide ir gatava servera procesus sym uz abiem mezgliem, kā norādīts zemāk.

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

Reģistrācijas ieraksti tiek nosūtīti uz fonālā žurnāla failu (symmetric.log) žurnāla mapē katalogā, kur ir instalēts SymmetricDS, kā arī standarta izejas datos. Serveri sym tagad var uzsākt mezglā store-001.

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

Ja servera process sym tiek palaists mezglā vm2, tas izveidos SymmetricDS katalogu tabulas arī PostgreSQL datubāzē. Ja servera process sym tiek palaists abos mezglos, tie koordinēs savus darbus, lai replikētu datus no corp-000 uz store-001. Ja pēc dažām sekundēm mēs pieprasīsim visas 4 tabulas abos galos, mēs redzēsim, ka replikācija ir veiksmīgi pabeigta. Vai arī var nosūtīt sākotnējo ielādei uz mezglu store-001 no corp-000 ar nākamo komandu.

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

Šajā posmā tabulā item datubāzē MySQL mezglā corp-000 (hosts: vm1) tiek pievienots jauns ieraksts, un to var pārbaudīt tās replikācijā PostgreSQL datubāzē mezglā store-001 (hosts: vm2). Mēs redzam Pull operāciju, lai pārvietotu datus no corp-000 uz 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)

Lai veiktu Push operāciju, lai pārvietotu datus no store-001 uz corp-000, pievienojam ierakstu tabulā sale_transaction un pārbaudām, vai replikācija ir veikta.

Rezultāts.

Mēs redzam veiksmīgu divvirzienu replikāciju tabulām starp MySQL un PostgreSQL datubāzēm. Lai iestatītu replikāciju jaunām lietotāju tabulām, veicam šādas darbības. Izveidojam tabulu t1 piemēram un konfigurējam tās replikācijas noteikumus šādā veidā. Mēs šādi konfigurējam tikai replikāciju no corp-000 uz 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)

Pēc tam konfigurācija saņem ziņojumu par shēmas izmaiņām, proti, jaunas tabulas pievienošanu, izmantojot komandu symadmin ar argumentu sync-triggers, kas atjauno izsistījus, lai saskaņotu tabulu definīcijas. Tiek veikta send-schema, lai nosūtītu shēmas izmaiņas mezglam store-001, un tabulas t1 replikācija ir iestatīta.

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

SymmetricDS priekšrocības

Vienkārša uzstādīšana un konfigurācija, tostarp gatavs konfigurācijas failu kopums shēmas izveidei ar trim vai diviem mezgliem.
Krusta platformas datubāzu un platformas neatkarība, tostarp serveri, klēpjdatori un mobilās ierīces.
Jebkuras datubāzes replikācija uz jebkuru citu datubāzi vietējā, WAN vai mākoņu vidē.
Optimizēta darbība ar divu datubāzu pāri vai vairākiem tūkstošiem ērtai replikācijai.
Maksas versija ar grafisko saskarni un lielisku atbalstu.

SymmetricDS trūkumi

Jādefinē manuāli komandrindā replikācijas noteikumi un virziens, izmantojot SQL operatorus katalogu tabulu ielādei, kas dažreiz ir neērti.
Daudz tabulu konfigurēšana replikācijai var būt nogurdinoša, ja netiek izmantoti skripti SQL operatoru veidošanai, kas nosaka replikācijas noteikumus un virzienu.
Logos tiek ierakstīta pārāk liela informācijas apjoms, un dažreiz ir jākārt to, lai logs neaizņemtu pārāk daudz vietas.

Secinājumi par SymmetricDS

SymmetricDS ļauj iestatīt divvirzienu replikāciju starp diviem, trim un pat vairākiem tūkstošiem mezglu, lai veiktu replikāciju un sinhronizētu failus. Tas ir unikāls rīks, kas pats veic daudzas darbības, piemēram, automātisku datu atjaunošanu pēc ilgstošas dīkstāves mezglā, drošu un efektīvu datu apmaiņu starp mezgliem pa HTTPS, automātisku konfliktu pārvaldību, pamatojoties uz noteikumu kopumu utt. SymmetricDS veic replikāciju starp jebkurām datubāzēm, tāpēc to var izmantot visdažādākajiem scenārijiem, tostarp migrācijai, pārejai uz jaunu versiju, izplatīšanai, filtrēšanai un datu pārveidošanai dažādās platformās.

Piemērs izveidots, pamatojoties uz oficiālo īso rokasgrāmatu par SymmetricDS. Tajā lietotāja rokasgrāmatā sīki aprakstīti dažādi jēdzieni, kas saistīti ar replikācijas iestatīšanu, izmantojot SymmetricDS.

Avots: habr.com