Jeg skal skissere kryssreplikering mellom PostgreSQL og MySQL, samt metoder for å sette opp kryssreplikering mellom de to databaseserverne. Vanligvis kalles kryssreplikerte databaser homogene, og det er en praktisk metode for å flytte fra en RDBMS-server til en annen.
PostgreSQL- og MySQL-databaser anses generelt som relasjonelle, men med tilleggsutvidelser tilbyr de NoSQL-funksjoner. Her vil vi diskutere replikering mellom PostgreSQL og MySQL fra et relasjonelt DBMS-perspektiv.
Vi vil ikke beskrive hele det indre arbeidet, bare de grunnleggende prinsippene slik at du får en ide om å konfigurere replikering mellom databaseservere, fordeler, begrensninger og brukstilfeller.
Vanligvis utføres replikering mellom to identiske databaseservere enten i binær modus eller ved å bruke spørringer mellom en master (a.k.a. utgiver, master eller aktiv) og en slave (abonnent, standby eller passiv). Hensikten med replikering er å gi en sanntidskopi av masterdatabasen på slavesiden. I dette tilfellet overføres data fra master til slave, det vil si fra aktiv til passiv, fordi replikering bare utføres i én retning. Men du kan sette opp replikering mellom to databaser i begge retninger, slik at data overføres fra slave til master i en aktiv-aktiv konfigurasjon. Alt dette, inkludert kaskadereplikering, er mulig mellom to eller flere identiske databaseservere. Aktiv-aktiv eller aktiv-passiv konfigurasjon avhenger av behov, tilgjengelighet av slike evner i den første konfigurasjonen eller bruk av eksterne konfigurasjonsløsninger og eksisterende avveininger.
Den beskrevne konfigurasjonen er mulig mellom forskjellige databaseservere. Serveren kan konfigureres til å akseptere replikerte data fra en annen databaseserver og fortsatt opprettholde sanntids øyeblikksbilder av de replikerte dataene. MySQL og PostgreSQL tilbyr de fleste av disse konfigurasjonene internt eller gjennom tredjepartsutvidelser, inkludert binære loggmetoder, disklåsing og setnings- og radbaserte metoder.
Kryssreplikering mellom MySQL og PostgreSQL er nødvendig for en engangsmigrering fra en databaseserver til en annen. Disse databasene bruker forskjellige protokoller, så det er ikke mulig å koble dem direkte. For å etablere datautveksling kan du bruke et eksternt åpen kildekodeverktøy, for eksempel pg_chameleon.
Hva er pg_chameleon
pg_chameleon er et replikeringssystem fra MySQL til PostgreSQL i Python 3. Det bruker åpen kildekode mysql-replikeringsbiblioteket, også i Python. Radbilder trekkes ut fra MySQL-tabeller og lagres som JSONB-objekter i PostgreSQL-databasen, og dekrypteres deretter med pl/pgsql-funksjonen og reproduseres i PostgreSQL-databasen.
Funksjoner av pg_chameleon
Flere MySQL-skjemaer fra samme klynge kan replikeres til en enkelt mål-PostgreSQL-database i en en-til-mange-konfigurasjon
Kilde- og målskjemanavnet kan ikke være det samme.
Replikeringsdata kan hentes fra en kaskadekoplet MySQL-replika.
Tabeller som ikke kan replikere eller produsere feil, er ekskludert.
Hver replikeringsfunksjon styres av demoner.
Kontroll via YAML-baserte parametere og konfigurasjonsfiler.
Eksempel
Vert
vm1
vm2
OS -versjon
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64
DB-serverversjon
MySQL 5.7.26
PostgreSQL 10.5
DB-port
3306
5433
IP-adresse
192.168.56.102
192.168.56.106
For å begynne, klargjør alle nødvendige komponenter for å installere pg_chameleon. Dette eksemplet installerer Python 3.6.8, som oppretter og aktiverer det virtuelle miljøet.
$> 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 altinstallEtter vellykket installasjon av Python3.6, må du fullføre de gjenværende kravene, for eksempel å opprette og aktivere et virtuelt miljø. I tillegg oppdateres pip-modulen til siste versjon og brukes til å installere pg_chameleon. Kommandoene nedenfor installerer med vilje pg_chameleon 2.0.9, selv om den nyeste versjonen er 2.0.10. Dette er nødvendig for å unngå nye feil i den oppdaterte versjonen.
$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9Vi kaller deretter pg_chameleon (kameleon er en kommando) med argumentet set_configuration_files for å aktivere pg_chameleon og lage standardkataloger og konfigurasjonsfiler.
(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.ymlNå lager vi en kopi av config-example.yml som default.yml slik at den blir standard konfigurasjonsfil. Et eksempel på konfigurasjonsfil for dette eksemplet er gitt nedenfor.
$> 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:Konfigurasjonsfilen i dette eksemplet er en eksempel pg_chameleon-fil med mindre modifikasjoner for å passe kilde- og målmiljøene, og nedenfor er en oversikt over de forskjellige delene av konfigurasjonsfilen.
I standard.yml-konfigurasjonsfilen er det en seksjon med globale innstillinger, der du kan administrere innstillinger som plassering av låsefilen, plassering av logger, lagringsperiode for logger osv. Deretter kommer seksjonen for typeoverstyring, der et sett med regler for overstyring av typer under replikering. Eksemplet har som standard en typeoverstyrende regel som konverterer tinyint(1) til en boolsk verdi. I neste avsnitt spesifiserer vi tilkoblingsdetaljene til måldatabasen. I vårt tilfelle er dette en PostgreSQL-database, betegnet pg_conn. I den siste delen angir vi kildedataene, det vil si tilkoblingsparametrene til kildedatabasen, tilordningsskjemaet mellom kilde- og måldatabasene, tabeller som må hoppes over, ventetid, minne, pakkestørrelse. Merk at "kilder" er flertall, noe som betyr at vi kan legge til flere kildedatabaser til en enkelt måldatabase for å sette opp en mange-til-en-konfigurasjon.
Eksempeldatabasen world_x inneholder 4 tabeller med rader som MySQL-fellesskapet tilbyr som eksempler. Den kan lastes ned . Eksempeldatabasen kommer som et tar og komprimert arkiv med instruksjoner for å opprette og importere rader.
I MySQL- og PostgreSQL-databaser opprettes en spesiell bruker med samme navn usr_replica. I MySQL gis den ekstra leserettigheter til alle replikerte tabeller.
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;På PostgreSQL-siden opprettes en db_replica-database som vil akseptere endringer fra MySQL-databasen. Brukeren usr_replica i PostgreSQL konfigureres automatisk som eier av to skjemaer, pgworld_x og sch_chameleon, som inneholder henholdsvis de faktiske replikerte tabellene og replikeringskatalogtabellene. Argumentet create_replica_schema er ansvarlig for automatisk konfigurasjon, som du vil se nedenfor.
postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASEMySQL-databasen er konfigurert med noen parameterendringer for å forberede den for replikering som vist nedenfor. Du må starte databaseserveren på nytt for at endringene skal tre i kraft.
$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1Nå er det viktig å sjekke tilkoblingen til begge databaseserverne slik at det ikke er noen problemer når du kjører pg_chameleon-kommandoene.
På PostgreSQL-noden:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_xPå MySQL-noden:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaDe neste tre kommandoene pg_chameleon (kameleon) forbereder miljøet, legg til kilden og initialiser replikaen. Argumentet create_replica_schema til pg_chameleon oppretter et standardskjema (sch_chameleon) og et replikeringsskjema (pgworld_x) i PostgreSQL-databasen, som vi allerede har diskutert. Argumentet add_source legger til en kildedatabase til konfigurasjonen ved å lese konfigurasjonsfilen (default.yml), og i vårt tilfelle er det mysql, og init_replica initialiserer konfigurasjonen basert på parameterne i konfigurasjonsfilen.
$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debugUtdataene fra disse tre kommandoene indikerer tydelig at de ble utført vellykket. Eventuelle krasj eller syntaksfeil rapporteres i enkle, klare meldinger med tips om hvordan du kan fikse problemet.
Til slutt starter vi replikering ved å bruke start_replica og mottar en suksessmelding.
$> chameleon start_replica --config default --source mysql
output: Starting the replica process for source mysqlReplikeringsstatus kan spørres ved å bruke show_status-argumentet, og feil kan vises ved å bruke show_errors-argumentet.
Som vi allerede har sagt, styres hver replikeringsfunksjon av demoner. For å se dem, spør vi prosesstabellen med Linux ps-kommandoen, som vist nedenfor.
Replikering anses ikke som konfigurert før vi tester det i sanntid, som vist nedenfor. Vi lager en tabell, setter inn et par poster i MySQL-databasen og kaller sync_tables-argumentet i pg_chameleon for å oppdatere daemonene og replikere tabellen med postene til PostgreSQL-databasen.
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.For å bekrefte testresultatene spør vi tabellen fra PostgreSQL-databasen og sender ut radene.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | one
2 | twoHvis vi gjør en migrering, vil følgende pg_chameleon-kommandoer være slutten på det. Kommandoene må utføres etter at vi er sikre på at radene i alle måltabeller har blitt replikert, og resultatet vil være en pent migrert PostgreSQL-database uten referanser til kildedatabasen eller replikeringsskjemaet (sch_chameleon).
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugOm ønskelig kan du bruke følgende kommandoer for å slette den opprinnelige konfigurasjonen og replikeringsskjemaet.
$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debugFordeler med pg_chameleon
Enkel oppsett og konfigurasjon.
Feilsøk og identifiser uregelmessigheter enkelt med klare feilmeldinger.
Ytterligere spesialtabeller kan legges til replikering etter initialisering uten å endre resten av konfigurasjonen.
Det er mulig å konfigurere flere kildedatabaser for en enkelt måldatabase, og dette er veldig nyttig hvis du kombinerer data fra en eller flere MySQL-databaser til en enkelt PostgreSQL-database.
Du trenger ikke å replikere de valgte tabellene.
Ulemper med pg_chameleon
Støttes kun med MySQL 5.5 og nyere som kilde og PostgreSQL 9.5 og nyere som måldatabase.
Hver tabell må ha en primær eller unik nøkkel, ellers initialiseres tabellene under init_replica-prosessen, men blir ikke replikert.
Enveis replikering - kun fra MySQL til PostgreSQL. Derfor er den bare egnet for den "aktive-passive" kretsen.
Kilden kan kun være en MySQL-database, og støtte for en PostgreSQL-database som kilde er kun eksperimentell og med begrensninger (les mer )
Resultater for pg_chameleon
Replikeringsmetoden i pg_chameleon er flott for å migrere en database fra MySQL til PostgreSQL. Den betydelige ulempen er at replikering bare er enveis, så databasefagfolk vil neppe vil bruke den til noe annet enn migrering. Men problemet med enveisreplikering kan løses med et annet åpen kildekodeverktøy - SymmetricDS.
Les mer i den offisielle dokumentasjonen . Kommandolinjehjelp kan bli funnet .
Oversikt over SymmetricDS
SymmetricDS er et åpen kildekodeverktøy som replikerer enhver database til en hvilken som helst annen vanlig database: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird og andre skydatabaseforekomster, f.eks. Redshift og Azure, etc. Tilgjengelige funksjoner: database- og filsynkronisering, multi-master databasereplikering, filtrert synkronisering, transformasjon og andre. Dette er et Java-verktøy og krever en standardversjon av JRE eller JDK (versjon 8.0 eller høyere). Her kan dataendringer til utløsere i kildedatabasen registreres og sendes til riktig måldatabase i form av batcher.
Symmetriske DS-funksjoner
Verktøyet er plattformuavhengig, noe som betyr at to eller flere forskjellige databaser kan utveksle data.
Relasjonsdatabaser synkroniseres ved hjelp av dataendringsposter, mens filsystembaserte databaser bruker filsynkronisering.
Toveis replikering ved bruk av Push- og Pull-metoder basert på et sett med regler.
Dataoverføring er mulig over sikre nettverk med lav båndbredde.
Automatisk gjenoppretting når noder gjenopptar driften etter en feil og automatisk konfliktløsning.
Cloud-kompatible og kraftige utvidelses-APIer.
Eksempel
SymmetricDS kan konfigureres i ett av to alternativer:
En master (overordnet) node som sentralt koordinerer datareplikering mellom to slave (barn) noder, og kommunikasjon mellom underordnede noder skjer bare gjennom den overordnede.
En aktiv node (Node 1) kan kommunisere for replikering med en annen aktiv node (Node 2) uten en mellommann.
I begge alternativene skjer datautveksling ved hjelp av Push og Pull. I dette eksemplet vil vi vurdere en aktiv-aktiv konfigurasjon. Det vil ta for lang tid å beskrive hele arkitekturen, så gjør din forskning. for å lære mer om SymmetricDS-enheten.
Å installere SymmetricDS er veldig enkelt: last ned open source-versjonen av zip-filen og ta den ut hvor du vil. Tabellen nedenfor gir informasjon om installasjonsplasseringen og versjonen av SymmetricDS i dette eksemplet, samt databaseversjonene, Linux-versjonene, IP-adressene og portene for begge nodene.
Vert
vm1
vm2
OS -versjon
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64
DB-serverversjon
MySQL 5.7.26
PostgreSQL 10.5
DB-port
3306
5832
IP-adresse
192.168.1.107
192.168.1.112
Symmetrisk DS-versjon
Symmetrisk DS 3.9
Symmetrisk DS 3.9
SymmetricDS installasjonsbane
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20
Symmetrisk DS nodenavn
corp-000
butikk-001
Her installerer vi SymmetricDS i /usr/local/symmetric-server-3.9.20, og ulike underkataloger og filer vil bli lagret der. Vi er interessert i prøvene og underkatalogene for motorer. Eksempelkatalogen inneholder eksempler på konfigurasjonsfiler med nodeegenskaper, samt eksempler på SQL-skript for å komme raskt i gang.
I prøvekatalogen ser vi tre konfigurasjonsfiler med nodeegenskaper - navnet viser arten av noden i et bestemt skjema.
corp-000.properties
store-001.properties
store-002.propertiesSymmetricDS har alle nødvendige konfigurasjonsfiler for en grunnleggende 3-node design (alternativ 1), og de samme filene kan brukes for en 2-node design (alternativ 2). Kopier den nødvendige konfigurasjonsfilen fra sample-katalogen til motorer på vm1-verten. Det blir slik:
$> 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=000Denne noden i SymmetricDS-konfigurasjonen kalles corp-000, og databasetilkoblingen håndteres av mysql jdbc-driveren, som bruker tilkoblingsstrengen ovenfor og påloggingsinformasjonen. Vi kobler til replica_db-databasen og tabeller vil bli opprettet under oppretting av skjema. sync.url viser hvor du skal kontakte noden for synkronisering.
Node 2 på vert vm2 er konfigurert som store-001 og resten er spesifisert i node.properties-filen nedenfor. Node store-001 kjører PostgreSQL-databasen og pgdb_replica er replikeringsdatabasen. registration.url lar verten vm2 kontakte verten vm1 og motta konfigurasjonsdetaljer fra den.
$> 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=001Det ferdige SymmetricDS-eksemplet inneholder parametere for å sette opp toveis replikering mellom to databaseservere (to noder). Trinnene nedenfor utføres på host vm1 (corp-000), som vil lage et eksempelskjema med 4 tabeller. Å kjøre create-sym-tables med kommandoen symadmin oppretter katalogtabeller der reglene og retningen for replikering mellom noder vil bli lagret. Til slutt lastes eksempeldata inn i tabellene.
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.sqlI eksemplet konfigureres vare- og varesalgspris-tabellene automatisk til å replikere fra butikk-000 til butikk-001, og salgstabellene (salgstransaksjon og salgsreturlinje) er automatisk konfigurert til å replikere fra butikk-001 til butikk-000. Nå lager vi et skjema i PostgreSQL-databasen på host vm2 (store-001) for å forberede det til å motta data fra corp-000.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xmlSørg for å sjekke at MySQL-databasen på vm1 har eksempeltabeller og SymmetricDS-katalogtabeller. Merk at SymmetricDS-systemtabellene (prefikset med sym_) for øyeblikket bare er tilgjengelige på node corp-000 fordi det er der vi kjørte kommandoen create-sym-tables og skal administrere replikering. Og i databasen på node store-001 vil det bare være 4 eksempeltabeller uten data.
Alle. Miljøet er klart til å kjøre sym-serverprosesser på begge noder som vist nedenfor.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &Loggoppføringer sendes til en bakgrunnsloggfil (symmetric.log) i loggmappen i katalogen der SymmetricDS er installert, samt til standardutdata. Sym-serveren kan nå startes på node store-001.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &Hvis du kjører sym-serverprosessen på vm2-verten, vil den også lage SymmetricDS-katalogtabeller i PostgreSQL-databasen. Hvis du kjører sym-serverprosessen på begge nodene, koordinerer de med hverandre for å replikere data fra corp-000 til store-001. Hvis vi etter noen sekunder spør alle 4 tabellene på begge sider, vil vi se at replikeringen var vellykket. Eller du kan sende bootstrap til node store-001 fra corp-000 med følgende kommando.
vm1$> ./symadmin --engine corp-000 reload-node 001På dette tidspunktet settes en ny post inn i elementtabellen i MySQL-databasen på node corp-000 (vert: vm1), og du kan sjekke replikeringen til PostgreSQL-databasen på node-lager-001 (vert: vm2). Vi ser en Pull-operasjon for å flytte data fra corp-000 til 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)For å utføre en Push-operasjon for å flytte data fra store-001 til corp-000, setter vi inn en post i sale_transaction-tabellen og bekrefter at replikering er vellykket.
Vi ser det vellykkede oppsettet av toveis replikering av eksempeltabellene mellom MySQL- og PostgreSQL-databaser. Følg disse trinnene for å konfigurere replikering for nye brukertabeller: Vi lager for eksempel tabell t1 og konfigurerer replikeringsreglene som følger. På denne måten konfigurerer vi kun replikering fra corp-000 til 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)Konfigurasjonen blir deretter varslet om skjemaendringen, det vil si tilføyelse av en ny tabell, ved å bruke symadmin-kommandoen med sync-triggers-argumentet, som gjenskaper triggerne for å kartlegge tabelldefinisjonene. send-schema utføres for å sende skjemaendringer til node store-001, og replikering av tabell t1 er konfigurert.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Fordeler med SymmetricDS
Enkel installasjon og konfigurasjon, inkludert et ferdig sett med filer med parametere for å lage en krets med tre noder eller to noder.
Databaser på tvers av plattformer og plattformuavhengighet, inkludert servere, bærbare datamaskiner og mobile enheter.
Repliker enhver database til en hvilken som helst annen database lokalt, på WAN eller i skyen.
Mulighet for optimalt arbeid med et par databaser eller flere tusen for praktisk replikering.
Betalt versjon med GUI og utmerket støtte.
Ulemper med SymmetricDS
Du må manuelt definere reglene og retningen for replikering på kommandolinjen gjennom SQL-setninger for å laste katalogtabeller, noe som kan være upraktisk.
Å sette opp mange tabeller for replikering kan være kjedelig med mindre du bruker skript til å lage SQL-setninger som definerer reglene og retningen for replikering.
Det er for mye informasjon som registreres i loggene, og noen ganger må du rydde opp i loggfilen slik at den ikke tar for mye plass.
Resultater for SymmetricDS
SymmetricDS lar deg sette opp toveis replikering mellom to, tre eller til og med flere tusen noder for å replikere og synkronisere filer. Dette er et unikt verktøy som selvstendig utfører mange oppgaver, som automatisk datagjenoppretting etter lang tids nedetid på en node, sikker og effektiv datautveksling mellom noder via HTTPS, automatisk konflikthåndtering basert på et sett med regler osv. SymmetricDS utfører replikering mellom alle databaser, derfor kan den brukes til en lang rekke scenarier, inkludert migrering, migrering, distribusjon, filtrering og transformasjon av data på tvers av plattformer.
Eksemplet er basert på tjenestemannen av SymmetricDS. I Beskriver i detalj de ulike konseptene som er involvert i å sette opp replikering med SymmetricDS.
Kilde: www.habr.com