Krydsreplikation mellem PostgreSQL og MySQL

Jeg vil kort fortælle om krydsreplikering mellem PostgreSQL og MySQL, samt metoder til opsætning af krydsreplikering mellem disse to databaseservere. Krydsreplikerede databaser omtales almindeligvis som homogene databaser, og dette er en bekvem metode til at migrere fra en RDBMS-server til en anden.

PostgreSQL- og MySQL-databaser betragtes traditionelt som relationelle, men med yderligere udvidelser tilbyder de NoSQL-funktioner. Her vil vi diskutere replikering mellem PostgreSQL og MySQL fra et relationel databasestyringsperspektiv.

Vi vil ikke beskrive alt det interne, kun de grundlæggende principper, så du får en idé om opsætning af replikering mellem databaseservere, fordele, begrænsninger og use cases.

Typisk udføres replikering mellem to identiske databaseservere enten i binær tilstand eller ved forespørgsler mellem en master (alias udgiver, master eller aktiv) og en slave (abonnent, standby eller passiv). Formålet med replikering er at give en kopi i realtid af masterdatabasen på standby-siden. I dette tilfælde overføres data fra master til slave, det vil sige fra aktiv til passiv, fordi replikering kun udføres i én retning. Men du kan opsætte replikering mellem de to databaser i begge retninger, så data overføres fra slaven til masteren i en aktiv-aktiv konfiguration. Alt dette, inklusive kaskadereplikering, er muligt mellem to eller flere identiske databaseservere. Aktiv-aktiv eller aktiv-passiv konfiguration afhænger af behovet, tilgængeligheden af ​​sådanne kapaciteter i den indledende konfiguration eller brugen af ​​eksterne tuning-løsninger og eksisterende handel -offs.

Den beskrevne konfiguration er mulig mellem forskellige databaseservere. Serveren kan konfigureres til at modtage replikerede data fra en anden databaseserver og stadig bevare øjebliksbilleder i realtid af de replikerede data. MySQL og PostgreSQL tilbyder de fleste af disse konfigurationer indbygget eller gennem tredjepartsudvidelser, inklusive binære logmetoder, disklåse og sætnings- og rækkebaserede metoder.

Krydsreplikering mellem MySQL og PostgreSQL er nødvendig for en engangsmigrering fra en databaseserver til en anden. Disse databaser bruger forskellige protokoller, så du kan ikke linke dem direkte. For at lette dataudvekslingen kan du bruge et eksternt open source-værktøj, såsom pg_chameleon.

Hvad er pg_chameleon

pg_chameleon er et replikeringssystem fra MySQL til PostgreSQL i Python 3. Det bruger mysql-replikerings open source-biblioteket, også i Python. Rækkebilleder hentes fra MySQL-tabeller og gemmes som JSONB-objekter i PostgreSQL-databasen og afkodes derefter af pl/pgsql-funktionen og afspilles i PostgreSQL-databasen.

Funktioner af pg_chameleon

Flere MySQL-skemaer fra den samme klynge kan replikeres til en enkelt PostgreSQL-måldatabase med en en-til-mange-konfiguration
Kilde- og målskemanavnene kan ikke være de samme.
Replikeringsdata kan hentes fra en MySQL kaskadereplika.
Tabeller, der ikke kan replikere eller generere fejl, er udeladt.
Hver replikeringsfunktion styres af dæmoner.
Styr med parametre og konfigurationsfiler baseret på YAML.

Eksempel

Vært
vm1
vm2

OS version
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Database server version
MySQL 5.7.26
PostgreSQL 10.5

DB port
3306
5433

IP-adresse
192.168.56.102
192.168.56.106

Forbered først alle de nødvendige komponenter til installation af pg_chameleon. Dette eksempel har Python 3.6.8 installeret, som skaber et virtuelt miljø og aktiverer det.

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

Når Python3.6 er installeret med succes, skal resten af ​​kravene opfyldes, såsom oprettelse og aktivering af et virtuelt miljø. Desuden er pip-modulet opdateret til den nyeste version og bruges til at installere pg_chameleon. Kommandoerne nedenfor installerer med vilje pg_chameleon 2.0.9, selvom den seneste version er 2.0.10. Dette er nødvendigt for at undgå nye fejl i den opdaterede version.

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

Vi kalder derefter pg_chameleon (chameleon er en kommando) med set_configuration_files-argumentet for at aktivere pg_chameleon og oprette standard konfigurationsmapper og -filer.

(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.yml

Vi laver nu en kopi af config-example.yml som default.yml, så det bliver standardkonfigurationsfilen. Et eksempel på konfigurationsfil til dette eksempel findes 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:

Konfigurationsfilen i dette eksempel er et eksempel på en pg_chameleon-fil med mindre ændringer for at matche kilde- og målmiljøet, og nedenfor er en oversigt over de forskellige sektioner af konfigurationsfilen.

Standard.yml-konfigurationsfilen har en sektion med globale indstillinger (globale indstillinger), hvor du kan kontrollere indstillinger såsom placeringen af ​​låsefilen, placeringen af ​​logfilerne, lagringsperioden for logfilerne osv. Dernæst kommer typetilsidesættelsen afsnit, hvor de fastsatte regler for tilsidesættelse af typer under replikering. Standardeksemplet bruger en typetilsidesættelsesregel, der konverterer tinyint(1) til en boolesk. I næste afsnit specificerer vi detaljerne om tilslutning til måldatabasen. I vores tilfælde er dette en PostgreSQL-database, betegnet som pg_conn. I det sidste afsnit specificerer vi kildedataene, det vil sige forbindelsesparametrene for kildedatabasen, kortlægningsskemaet for kilde- og måldatabaserne, tabeller, der skal springes over, timeout, hukommelse, pakkestørrelse. Bemærk, at "kilder" er flertal, hvilket betyder, at vi kan tilføje flere kildedatabaser til det samme mål for at opsætte en mange-til-en-konfiguration.

World_x-databasen i eksemplet indeholder 4 tabeller med rækker, som MySQL-fællesskabet foreslår til eksemplet. Den kan downloades her. Eksempeldatabasen kommer som et tjære- og komprimeret arkiv med instruktioner til oprettelse og import af strenge.

En speciel bruger med samme navn usr_replica oprettes i MySQL- og PostgreSQL-databaserne. MySQL giver den yderligere læseadgang til alle replikerede 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 oprettes en db_replica-database, som vil acceptere ændringer fra MySQL-databasen. Usr_replica-brugeren i PostgreSQL konfigureres automatisk som ejer af de to skemaer pgworld_x og sch_chameleon, som indeholder henholdsvis de faktiske replikerede tabeller og replikeringskatalogtabeller. Argumentet create_replica_schema er ansvarlig for automatisk konfiguration, 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 DATABASE

MySQL-databasen er konfigureret med nogle ændringer for at gøre den klar til replikering som vist nedenfor. Du skal genstarte databaseserveren for at ændringerne træder i kraft.

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

Nu er det vigtigt at kontrollere forbindelsen til begge databaseservere, så der ikke er problemer, når du udfører pg_chameleon-kommandoerne.

På PostgreSQL-noden:

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

På MySQL node:

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

De næste tre pg_chameleon (chameleon) kommandoer forbereder miljøet, tilføjer kilden og initialiser replikaen. Argumentet create_replica_schema til pg_chameleon opretter et standardskema (sch_chameleon) og et replikeringsskema (pgworld_x) i PostgreSQL-databasen, som vi sagde. Argumentet add_source tilføjer en kildedatabase til konfigurationen ved at læse konfigurationsfilen (default.yml), som i vores tilfælde er mysql, og init_replica initialiserer konfigurationen baseret på indstillingerne i konfigurationsfilen.

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

Outputtet af disse tre kommandoer viser tydeligt deres succes. Alle fejl eller syntaksfejl er angivet i enkle og forståelige meddelelser med tip til, hvordan man løser problemer.

Til sidst starter vi replikering med start_replica og får en succesbesked.

$> chameleon start_replica --config default --source mysql 
output: Starting the replica process for source mysql

Replikeringsstatus kan forespørges med show_status-argumentet, og fejl kan ses med show_errors-argumentet.

Resultatet.

Som vi allerede har sagt, styrer dæmoner hver replikeringsfunktion. For at se dem, forespørg procestabellen med Linux ps-kommandoen, som vist nedenfor.

Resultatet.

Replikering betragtes ikke som konfigureret, før vi tester det i realtid, som vist nedenfor. Vi opretter en tabel, indsætter et par poster i MySQL-databasen og kalder sync_tables-argumentet i pg_chameleon for at opdatere dæmonerne og replikere tabellen med posterne 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 at validere testresultaterne forespørger vi tabellen fra PostgreSQL-databasen og udlæser rækkerne.

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

Hvis vi migrerer, vil følgende pg_chameleon-kommandoer være slutningen af ​​migreringen. Kommandoerne skal køres, efter at vi har verificeret, at rækkerne i alle måltabeller er blevet replikeret, hvilket resulterer i en pænt migreret PostgreSQL-database uden referencer til kildedatabasen eller replikeringsskemaet (sch_chameleon).

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

Du kan valgfrit slette den originale konfiguration og replikeringsskema med følgende kommandoer.

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

Fordele ved pg_chameleon

Nem opsætning og konfiguration.
Praktisk fejlfinding og uregelmæssig registrering med klare fejlmeddelelser.
Yderligere specialtabeller kan tilføjes til replikering efter initialisering uden at ændre resten af ​​konfigurationen.
Det er muligt at opsætte flere kildedatabaser til én måldatabase, og det er meget praktisk, hvis du flette data fra en eller flere MySQL-databaser til en PostgreSQL-database.
Du kan vælge ikke at replikere valgte tabeller.

Ulemper ved pg_chameleon

Kun understøttet med MySQL 5.5 og nyere som kilde og PostgreSQL 9.5 og nyere som måldatabase.
Hver tabel skal have en primær eller unik nøgle, ellers initialiseres tabellerne i init_replica-processen, men ikke replikeres.
Envejsreplikering - kun fra MySQL til PostgreSQL. Derfor er den kun egnet til den aktiv-passive ordning.
Kilden kan kun være en MySQL-database, og understøttelse af en PostgreSQL-database som kilde er kun eksperimentel og begrænset (læs mere her)

Totaler for pg_chameleon

Replikeringsmetoden i pg_chameleon er fantastisk til at migrere en database fra MySQL til PostgreSQL. Den store ulempe er, at replikering kun er én vej, så databaseprofessionelle vil næppe vil bruge det til andet end migrering. Men problemet med envejsreplikering kan løses med et andet open source-værktøj - SymmetricDS.

Læs mere i den officielle dokumentation her. Kommandolinjehjælp kan findes her.

Oversigt over SymmetricDS

SymmetricDS er et open source-værktøj, der replikerer enhver database til enhver anden almindelig database: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird og andre cloud-databaseinstanser, for eksempel Redshift, og Azure osv. Tilgængelige funktioner: database- og filsynkronisering, multi-master databasereplikering, filtreret synkronisering, transformation og andre. Dette er et Java-værktøj og kræver standardudgivelsen JRE eller JDK (version 8.0 eller nyere). Her kan du registrere dataændringer på triggere i kildedatabasen og sende dem til den tilsvarende måldatabase som batches.

Symmetrisk DS-kapacitet

Værktøjet er platformsuafhængigt, hvilket betyder, at to eller flere forskellige databaser kan udveksle data.
Relationelle databaser synkroniseres ved at registrere dataændringer, og databaser baseret på filsystemer bruger filsynkronisering.
Tovejsreplikering ved hjælp af push- og pull-metoder baseret på et sæt regler.
Datatransmission er mulig over sikre netværk og netværk med lav båndbredde.
Automatisk gendannelse ved genoptagelse af drift af noder efter en fejl og automatisk konfliktløsning.
Cloud-kompatible og effektive udvidelses-API'er.

Eksempel

SymmetricDS kan konfigureres på en af ​​to måder:
En master (forælder) node, der centralt koordinerer datareplikering mellem to slave (under) noder, og dataudveksling mellem børn noder udføres kun gennem forælderen.
En aktiv node (node ​​1) kan kommunikere til replikering med en anden aktiv node (node ​​2) uden en mellemmand.

I begge muligheder sker dataudveksling ved hjælp af Push og Pull. I dette eksempel vil vi overveje den aktive-aktive konfiguration. Det er for langt til at beskrive hele arkitekturen, så undersøg lederskabfor at lære mere om SymmetricDS-apparatet.

Det er nemt at installere SymmetricDS: download open source zip-filen dermed og udtræk det, hvor du vil. Følgende tabel viser installationsplaceringen og versionen af ​​SymmetricDS i dette eksempel, samt databaseversioner, Linux-versioner, IP-adresser og porte for begge noder.

Vært
vm1
vm2

OS version
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Database server version
MySQL 5.7.26
PostgreSQL 10.5

DB port
3306
5832

IP-adresse
192.168.1.107
192.168.1.112

Symmetrisk DS-version
Symmetrisk DS 3.9
Symmetrisk DS 3.9

SymmetricDS installationssti
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

SymmetricDS værtsnavn
Corp-000
butik-001

Her installerer vi SymmetricDS i /usr/local/symmetric-server-3.9.20 og forskellige undermapper og filer vil blive gemt der. Vi er interesserede i undermapper prøver og motorer. Samplemappen indeholder eksempler på konfigurationsfiler med nodeegenskaber samt eksempler på SQL-scripts til hurtigt at starte demoen.

I prøvebiblioteket ser vi tre konfigurationsfiler med nodeegenskaber - navnet viser arten af ​​noden i et bestemt skema.

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

SymmetricDS har alle de nødvendige konfigurationsfiler til et grundlæggende 3 node skema (mulighed 1), og de samme filer kan bruges til et 2 node skema (mulighed 2). Kopier den påkrævede konfigurationsfil fra prøvebiblioteket til motorer på vm1-værten. Det bliver sådan her:

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

Denne node kaldes corp-000 i SymmetricDS-konfigurationen, og databaseforbindelsen håndteres af mysql jdbc-driveren, som bruger forbindelsesstrengen ovenfor og login-legitimationsoplysninger. Vi opretter forbindelse til replica_db-databasen, og tabeller vil blive oprettet under skemaoprettelse. sync.url viser linket til den node, der skal synkroniseres.

Node 2 på vært vm2 er konfigureret som store-001, og resten er angivet i filen node.properties nedenfor. Store-001-noden kører PostgreSQL-databasen, og pgdb_replica er databasen, der skal replikeres. registration.url tillader vm2-værten at kontakte vm1-værten og få konfigurationsdetaljer 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=001

Det færdige SymmetricDS-eksempel indeholder muligheder for opsætning af to-vejs replikering mellem to databaseservere (to noder). Trinene nedenfor udføres på vært vm1 (corp-000), som vil oprette et eksempelskema med 4 tabeller. Udførelse af create-sym-tables med kommandoen symadmin opretter derefter mappetabeller, hvor reglerne og retningen for replikering mellem noder vil blive gemt. Til sidst indlæses prøvedataene i tabellerne.

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

I eksemplet er vare- og varesalgspris-tabellerne automatisk konfigureret til at replikere fra corp-000 til butik-001, og salgstabellerne (salgstransaktion og salgsreturlinjepost) er automatisk konfigureret til at replikere fra butik-001 til virksomhed-000. Vi opretter nu et skema i PostgreSQL-databasen på vært vm2 (store-001) for at forberede det til at modtage data fra corp-000.

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

Sørg for at kontrollere, at MySQL-databasen på vm1 har eksempeltabeller og en SymmetricDS-katalogtabel. Bemærk, at SymmetricDS-systemtabellerne (med præfiks med sym_) i øjeblikket kun er tilgængelige på corp-000 noden, fordi det er der, vi kørte create-sym-tables kommandoen og vil administrere replikering. Og i databasen på store-001 noden vil der kun være 4 eksempeltabeller uden data.

Alle. Miljøet er klar til at køre sym-serverprocesser på begge noder som vist nedenfor.

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

Logposter sendes til baggrundslogfilen (symmetric.log) i logmappen i det bibliotek, hvor SymmetricDS er installeret, samt til standardoutputtet. Sym-serveren kan nu startes på store-001 noden.

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

Hvis du kører sym-serverprocessen på vm2-værten, vil den også oprette SymmetricDS-katalogtabellerne i PostgreSQL-databasen. Hvis du kører sym-serverprocessen på begge noder, vil de koordinere med hinanden for at replikere data fra corp-000 til store-001. Hvis vi efter et par sekunder forespørger på alle 4 tabeller på begge sider, vil vi se, at replikeringen var vellykket. Eller du kan sende bootstrap til store-001 fra corp-000 med følgende kommando.

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

På dette tidspunkt indsættes en ny post i elementtabellen i MySQL-databasen på node corp-000 (vært: vm1) og kan kontrolleres for replikering til PostgreSQL-databasen på node store-001 (vært: vm2). Vi ser en Pull-operation for at 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 at udføre en push-operation for at flytte data fra store-001 til corp-000, indsætter vi en post i sale_transaction-tabellen og verificerer, at replikering er gennemført.

Resultatet.

Vi ser en vellykket opsætning af to-vejs replikering af eksempeltabellerne mellem MySQL- og PostgreSQL-databaserne. Udfør følgende trin for at konfigurere replikering for nye brugertabeller. Vi opretter f.eks. tabel t1 og opsætter dens replikeringsregler som følger. Så vi opsætter 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)

Konfigurationen får derefter besked om skemaændringen, dvs. tilføjelsen af ​​en ny tabel, ved at bruge symadmin-kommandoen med sync-triggers-argumentet, som genskaber triggerne, så de matcher tabeldefinitionerne. Send-skema køres for at sende skemaændringer til store-001, og tabel t1 replikeres.

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

Fordele ved SymmetricDS

Nem installation og konfiguration, inklusive et færdiglavet sæt filer med parametre til oprettelse af et skema med tre eller to noder.
Cross-platform databaser og platform uafhængighed, herunder servere, bærbare computere og mobile enheder.
Repliker enhver database til enhver anden database lokalt, på WAN eller i skyen.
Evne til at arbejde optimalt med et par databaser eller flere tusinde for nem replikering.
Betalt version med GUI og fremragende support.

Ulemper ved SymmetricDS

Du skal manuelt definere reglerne og retningen for replikering på kommandolinjen via SQL-sætninger for at indlæse katalogtabellerne, hvilket kan være ubelejligt.
Det kan være besværligt at opsætte mange tabeller til replikering, medmindre du bruger scripts til at oprette SQL-sætninger, der definerer reglerne og retningen for replikering.
Der er for meget information i logfilerne, og nogle gange skal du rydde op i logfilen, så den ikke fylder for meget.

Sammenfatning af Symmetrisk DS

SymmetricDS giver dig mulighed for at opsætte to-vejs replikering mellem to, tre eller endda flere tusinde noder for at replikere og synkronisere filer. Det er et unikt værktøj, der udfører mange opgaver på egen hånd, såsom automatisk gendannelse af data efter lang nedetid på en node, sikker og effektiv kommunikation mellem noder over HTTPS, automatisk konflikthåndtering baseret på et sæt regler osv. SymmetricDS replikerer mellem alle databaser, derfor kan den bruges til en lang række scenarier, herunder migrering, opgradering, distribution, filtrering og datatransformation på tværs af platforme.

Eksemplet er baseret på embedsmanden hurtig guide af SymmetricDS. I brugermanual Beskriver i detaljer de forskellige koncepter, der er involveret i opsætning af replikering med SymmetricDS.

Kilde: www.habr.com