Kryssreplikering mellom PostgreSQL og MySQL

Eg vil kort forklara kryssreplikasjon mellom PostgreSQL og MySQL, samt metodar for å setja opp kryssreplikasjon mellom desse to databassservene. Vanlegvis vert databasar i kryssreplikasjon kalla homogene, og dette er ein praktisk metode for å flytta frå ein relasjonsdb-server til ein annan.

Databasane PostgreSQL og MySQL vert ofte rekna som relasjonsdatabasar, men med tilleggselement kan dei tilby moglegheiter for NoSQL. Her vil vi diskutera replikasjon mellom PostgreSQL og MySQL frå perspektivet til relasjonsdatabasar.

Vi vil ikkje beskriva heile den indre funksjonen, berre dei grunnleggjande prinsippa slik at du får eit innblikk i oppsetjing av replikasjon mellom databasserver, fordelar, begrensningar og bruksfelt.

Vanlegvis vert replikasjonen mellom to identiske databasservarar utført anten i binærmodus eller gjennom spørringar mellom det ledande noden (som også er utgjevar, hovud- eller aktiv) og det følgande (abonnent, ventande eller passiv). Målet med replikasjon er å gi ein sanntidskopi av hovuddataserverdien på den følgjande sidan. Her vert data sendt frå det leie til det følgjande, det vil seie frå aktiv til passiv, fordi replikasjonen vert utført berre i éin retning. Men det er mogleg å setja opp replikasjon mellom to databasar i begge retningar, slik at data vert sendt frå det følgjande til det leie i ein «aktiv-aktiv» konfigurasjon. Alt dette, inkludert kaskadereplikasjon, er mogleg mellom to eller fleire identiske databasservarar. Konfigurasjonen «aktiv-aktiv» eller «aktiv-passiv» avhenger av behov, tilgjengelegheit av slike moglegheiter i den opprinnelege konfigurasjonen, eller bruken av eksterne løysingar for oppsetjing og eksisterande kompromiss.

Den beskrevne konfigurasjonen er mogleg mellom forskjellige databasservarar. Ein server kan setjast opp for å motta replikerte data frå ein annan databasserver og samtidig oppbevara bilete av replikerte data i sanntid. MySQL og PostgreSQL tilbyr dei fleste av desse konfigurasjonane sjølv eller med hjelp av tredjepartsutvidingar, inkludert metodar for binærlogg, diskblokkeringsmetodar og metodar basert på operatørar og strenger.

Kryssreplika er nødvendig mellom MySQL og PostgreSQL for en engangs migrering fra en database-server til en annen. Disse databasene bruker forskjellige protokoller, så de kan ikke kobles direkte. For å etablere datadeling kan man bruke et eksternt open source-verktøy, som pg_chameleon.

Hva er pg_chameleon

pg_chameleon er et replikeringssystem fra MySQL til PostgreSQL basert på Python 3. Det benytter et open source-bibliotek, mysql-replication, også skrevet i Python. Rader ekstraheres fra MySQL-tabeller og lagres som JSONB-objekter i PostgreSQL-databasen, før de dekodes med pl/pgsql-funksjoner og gjengis i PostgreSQL-databasen.

Muligheter med pg_chameleon

Flere MySQL-skjemaer fra én klynge kan replikeres til én mål-PostgreSQL-database med en «én-til-mange» konfigurasjon.
Navnene på kilde- og målskjema kan ikke være identiske.
Replikasjonsdata kan hentes fra en kaskadereplika av MySQL.
Tabeller som ikke kan replikeres eller gir feil, ekskluderes.
Hver replikasjonsfunksjon styres av demoner.
Kontroll via parametere og konfigurasjonsfiler i YAML-format.

Eksempel

Vært
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 å komme i gang, forbered alle nødvendige komponenter for å installere pg_chameleon. I dette eksemplet er Python 3.6.8 installert, som oppretter 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

Etter vellykket installasjon av Python 3.6, må man oppfylle de øvrige kravene, som å opprette og aktivere et virtuelt miljø. I tillegg oppdateres pip-modulen til den nyeste versjonen og brukes til å installere pg_chameleon. I kommandoene nedenfor installeres bevisst pg_chameleon versjon 2.0.9, selv om den siste versjonen er 2.0.10. Dette gjøres 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.9

Deretter kaller vi pg_chameleon (chameleon er kommandoen) med argumentet set_configuration_files for å aktivere pg_chameleon og opprette kataloger og standard konfigurasjonsfiler.

(venv) $> chameleon set_configuration_files
oppretter katalog /root/.pg_chameleon
oppretter katalog /root/.pg_chameleon/configuration/
oppretter katalog /root/.pg_chameleon/logs/
oppretter katalog /root/.pg_chameleon/pid/
kopierer konfigurasjonseksempelet til /root/.pg_chameleon/configuration/config-example.yml

Vi oppretter nå en kopi av config-example.yml som default.yml, slik at det blir konfigurasjonsfilen som brukes som standard. Et eksempel på konfigurasjonsfil for dette eksemplet er vist nedenfor.

$> cat default.yml
---
# globale innstillinger
pid_dir: '~/.pg_chameleon/pid/'
log_dir: '~/.pg_chameleon/logs/'
log_dest: fil
log_level: info
log_days_keep: 10
rollbar_key: ''
rollbar_env: ''

# type_override lar brukeren overstyre standard typekonvertering til en annen.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

# postgres måltilkobling
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 #hopper innsetting på tabellen delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #hopper sletting på skjemaet delphis_mediterranea
      update:

Konfigurasjonsfilen i dette eksemplet er en mal for pg_chameleon med små endringer i henhold til kilde- og målmiljøene, og en oversikt over de ulike seksjonene i konfigurasjonsfilen er vist nedenfor.

I konfigurasjonsfilen default.yml er det en seksjon for globale innstillinger (global settings), hvor du kan administrere innstillinger som plasseringen av låsefilen, loggplasseringen, loggoppbevaringsperioden osv. Deretter følger seksjonen for typeoverstyring (type override), hvor det angis et sett med regler for å overstyre typer under replikering. I standardeksempelet brukes en typeoverstyringsregel som konverterer tinyint(1) til boolsk verdi. I neste seksjon angir vi tilkoblingsdetaljene for mål-databasen. I vårt tilfelle er dette PostgreSQL-databasen, betegnet som pg_conn. I den siste seksjonen gir vi innstillingsdataene for kildene, dvs. tilkoblingsparametrene for kilde-databasen, skjemaoppsett for kilde- og mål-databasene, tabeller som skal hoppes over, ventetid, minne, og pakkestørrelse. Merk at "sources" er angitt i flertall, noe som betyr at vi kan legge til flere kilde-databaser for en enkelt mål-database for å konfigurere et "mange-til-en" oppsett.

Verdatabase world_x i eksempelet inneheld 4 tabeller med rader som MySQL-samfunnet tilbyr som eksempel. Den kan lastes ned. her. Eksempelverdadata kommer som en tar og komprimert arkiv med instruksjoner for å opprette og importere rader.

I MySQL- og PostgreSQL-databaser opprettes en spesialbruker med samme navn usr_replica. I MySQL får denne brukeren ekstra rettigheter til å lese 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 database db_replica, som skal motta endringer fra MySQL-databasen. Brukeren usr_replica i PostgreSQL konfigureres automatisk som eier av de to skjemaene pgworld_x og sch_chameleon, som inneholder henholdsvis de faktiske replikerte tabellene og tabellene med replikeringskataloger. Den automatiske konfigurasjonen styres av argumentet create_replica_schema, 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 konfigureres med endringer av noen parametere 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 = 1

Det er nå viktig å sjekke tilkoblingen til begge databaser, slik at det ikke oppstår problemer når pg_chameleon-kommandoene kjøres.

På PostgreSQL-noden:

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

På MySQL-noden:

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

De følgende tre pg_chameleon (chameleon) kommandoene forbereder miljøet, legger til kilden og initierer replikasjonen. Argumentet create_replica_schema i pg_chameleon lager standard skjema (sch_chameleon) og replikaschema (pgworld_x) i PostgreSQL-databasen, som vi allerede har nevnt. Argumentet add_source legger til kilde-databasen i konfigurasjonen, leser konfigurasjonsfilen (default.yml), og i vårt tilfelle er dette mysql, mens init_replica initialiserer konfigurasjonen basert på parametrene i konfigurasjonsfilen.

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

Utslippingene fra disse tre kommandoene indikerer tydelig deres vellykkede gjennomføring. Eventuelle feil eller syntaksfeil vises med klare og forståelige meldinger som gir tips til hvordan man kan løse problemene.

Til slutt, la oss starte replikeringen med start_replica og motta en melding om vellykket gjennomføring.

$> chameleon start_replica --config default --source mysql 
output: Starter replikasjonsprosessen for kilde mysql

Status på replikasjonen kan forespørres med argumentet show_status, mens feil kan vises ved hjelp av argumentet show_errors.

Resultat.

Som nevnt tidligere, administreres hver replikasjonsfunksjon av demoner. For å se dem, kan vi forespørre prosesslisten med kommandoen Linux ps, som vist nedenfor.

Resultat.

Replikasjon anses ikke som konfigurert før vi tester den i sanntid, som vist nedenfor. Vi oppretter en tabell, setter inn et par poster i MySQL-databasen og kaller argumentet sync_tables i pg_chameleon for å oppdatere demonene 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
Synkroniserer tabeller prosess for kilde mysql startet.

For å bekrefte testresultatene, forespør vi tabellen fra PostgreSQL-databasen og viser radene.

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

Hvis vi utfører migrasjon, vil de følgende kommandoene fra pg_chameleon avslutte den. Kommandoene må utføres etter at vi har bekreftet at radene fra alle måltabeller er blitt replikert, og resultatet vil være en pent overført PostgreSQL-database uten referanser til den opprinnelige databasen eller replikasjonsoppsettet (sch_chameleon).

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

Ved ønske kan de følgende kommandoene brukes til å slette den opprinnelige konfigurasjonen og replikasjonsoppsettet.

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

Fordeler med pg_chameleon

Enkel innstilling og konfigurasjon.
Brukervennlig feilsøking og identifisering av anomalier med forståelige feilmeldinger.
Det er mulig å legge til flere spesielle tabeller til replikasjonen etter initiering, uten å endre den øvrige konfigurasjonen.
Du kan konfigurere flere kilder for én målbase, noe som er veldig praktisk når du samler data fra én eller flere MySQL-databaser i én PostgreSQL-database.
Valgte tabeller trenger ikke å replikeres.

Ulemper med pg_chameleon

Støttes kun med MySQL 5.5 og høyere som kilde og PostgreSQL 9.5 og høyere som mål database.
Hver tabell må ha en primærnøkkel eller unik nøkkel, ellers initialiseres tabellene i init_replica-prosessen, men replikeres ikke.
Enveisreplikering — bare fra MySQL til PostgreSQL. Derfor passer det bare for en «aktiv-passiv»-ordning.
Kilden kan bare være en MySQL-database, og støtte for PostgreSQL som kilde er bare eksperimentell og med begrensninger (finn ut mer her)

Sammendrag av pg_chameleon

Replikasjonsmetoden i pg_chameleon passer utmerket for migrering av databaser fra MySQL til PostgreSQL. En betydelig ulempe er at replikeringen er ensrettet, så databasespesialister vil trolig ikke ønske å bruke den til noe annet enn migrering. Men problemet med enveisreplikering kan løses med et annet åpen kildekode-verktøy — SymmetricDS.

Les mer i den offisielle dokumentasjonen her. Kommandolinjehjelp kan finnes her.

Oversikt over SymmetricDS

SymmetricDS er et åpen kildekode-verktøy som replikerer enhver database til enhver annen vanlig database: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird og andre skybaserte DB-forekomster, som Redshift og Azure, osv. Tilgjengelige funksjoner: synkronisering av databaser og filer, replikering av flere ledende databaser, filtrert synkronisering, transformasjon og mer. Det er et Java-verktøy, og det kreves en standardversjon av JRE eller JDK (versjon 8.0 eller høyere). Her kan du registrere datamodifikasjoner ved hjelp av triggere i kildedatabasen og sende dem til den tilsvarende måldatabasen i form av pakker.

Funksjoner i SymmetricDS

Verktøyet er plattformuavhengig, noe som betyr at to eller flere forskjellige databaser kan utveksle data.
Relasjonsdatabaser synkroniseres ved å registrere datamodifikasjoner, mens filbaserte databaser bruker filsynkronisering.
Toveisreplikering ved bruk av Push- og Pull-metoder basert på et regelsett.
Data transmission is possible over secure networks and networks with low bandwidth.
Automatic recovery upon the resumption of node operations after a failure and automatic conflict resolution.
Compatibility with the cloud and efficient API extensions.

Eksempel

SymmetricDS can be configured in one of two ways:
A primary node that centrally coordinates data replication between two secondary nodes, and data exchange between secondary nodes occurs only through the primary.
An active node (node 1) can exchange data for replication with another active node (node 2) without a mediator.

In both configurations, data exchange occurs via Push and Pull. In this example, we will consider the 'active-active' configuration. Describing the entire architecture takes too long, so please review veiledningen, to learn more about the SymmetricDS device.

Installing SymmetricDS is very simple: download the open-source version zip file herfrå and extract it wherever you like. The table below provides information on the installation location and version of SymmetricDS in this example, as well as database versions, Linux versions, IP addresses, and ports for both nodes.

Vært
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

SymmetricDS Version
SymmetricDS 3.9
SymmetricDS 3.9

SymmetricDS Installation Path
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

SymmetricDS Node Name
corp-000
store-001

Here we install SymmetricDS in /usr/local/symmetric-server-3.9.20, and various nested directories and files will be stored here. We are interested in the nested directories samples and engines. The samples directory contains example configuration files with node properties as well as example SQL scripts for quickly starting the demonstration.

In the samples directory, we see three configuration files with node properties—the name indicates the nature of the node in a specific schema.

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

SymmetricDS has all the necessary configuration files for a basic 3-node schema (option 1), and the same files can be used for a 2-node schema (option 2). We copy the required configuration file from the samples directory to the engines on host vm1. It looks like this:

$> 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 noden i SymmetricDS-konfigurasjonen kalles corp-000, og tilkoblingen til databasen håndteres av mysql jdbc-driveren, som bruker tilkoblingsstrengen nevnt ovenfor og påloggingslegitimasjonen. Vi kobler til databasen replica_db, og under opprettelsen av skjemaet vil tabeller bli opprettet. sync.url viser tilkoblingspunktet til noden for synkronisering.

Nod 2 på verten vm2 er konfigurert som store-001, og det resterende er angitt i node.properties-filen, som er inkludert nedenfor. Nod store-001 kjører PostgreSQL-databasen, og pgdb_replica er databasen for replikasjon. registration.url lar verten vm2 kontakte verten vm1 og få konfigurasjonsdetaljene derfra.

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

Et ferdig eksempel på SymmetricDS inneholder parametere for å konfigurere toveiskommunikasjon mellom to databaseservere (to noder). Stegene nedenfor utføres på verten vm1 (corp-000), som vil opprette et eksempel skjema med 4 tabeller. Deretter vil kjøringen av create-sym-tables-kommandoen symadmin opprette katalogtabeller der regler og retningslinjer for replikasjon mellom nodene 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.sql

I eksemplet er tabellene item og item_selling_price automatisk konfigurert for replikasjon fra corp-000 til store-001, mens tabellene sale (sale_transaction og sale_return_line_item) automatisk er konfigurert for replikasjon fra store-001 til corp-000. Nå oppretter vi skjemaet i PostgreSQL-databasen på verten vm2 (store-001) for å forberede det på å motta data fra corp-000.

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

Det er avgjørende å sjekke at det finnes eksempler på tabeller og katalogtabeller for SymmetricDS i MySQL-databasen på vm1. Legg merke til at de systematiske tabellene for SymmetricDS (med prefikset sym_) nå er tilgjengelige bare på noden corp-000, fordi vi der utførte kommandoen create-sym-tables og vil administrere replikasjonen. I databasen på noden store-001 vil det bare være 4 eksemplartabeller uten data.

Alt er klart. Miljøet er klart til å kjøre sym serverprosesser på begge nodene, som vist nedenfor.

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

Loggfilene sendes til filen for bakgrunnslogger (symmetric.log) i logg-mappen i katalogen der SymmetricDS er installert, samt til standard utdata. Serveren sym kan nå initieres på noden store-001.

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

Hvis serverprosessen sym kjøres på vertsdatamaskinen vm2, vil den også opprette SymmetricDS katalogtabeller i PostgreSQL-databasen. Hvis serverprosessen sym kjøres på begge nodene, vil de koordinere seg med hverandre for å replikere data fra corp-000 til store-001. Hvis vi etter noen sekunder spør etter alle 4 tabeller på begge sider, vil vi se at replikasjonen er gjennomført vellykket. Alternativt kan vi sende en initial opplasting til noden store-001 fra corp-000 med følgende kommando.

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

I dette trinnet settes en ny oppføring inn i item-tabellen i MySQL-databasen på noden corp-000 (vert: vm1), og vi kan sjekke replikasjonen til PostgreSQL-databasen på noden store-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 Push-operasjonen for å flytte data fra store-001 til corp-000 setter vi inn en oppføring i sale_transaction-tabellen og sjekker at replikasjonen er utført.

Resultat.

Vi ser en vellykket oppsett av toveis replikasjon av eksempel-tabeller mellom MySQL- og PostgreSQL-databaser. For å sette opp replikasjon for nye brukertabeller, utfører vi følgende trinn. Vi oppretter tabellen t1 som eksempel og setter opp replikasjonsreglene på følgende måte. Slik setter vi opp replikasjonen kun 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)

Deretter får konfigurasjonen et varsel om endring av skjemaet, som er å legge til en ny tabell, ved hjelp av kommandoen symadmin med argumentet sync-triggers, som gjenoppretter triggere for å matche definisjonene av tabeller. send-schema kjøres for å sende skjemaendringene til noden store-001, og replikeringen av tabellen t1 er konfigurert.

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

Fordeler med SymmetricDS

Enkel installasjon og konfigurasjon, inkludert et ferdig sett med filer med parametere for å opprette skjema med tre eller to noder.
Kryssplattformdatabaser og plattformuavhengighet, inkludert servere, bærbare datamaskiner og mobile enheter.
Replikering av enhver database til enhver annen database lokalt, i WAN eller i skyen.
Mulighet for optimal drift med et par databaser eller flere tusen for enkel replikering.
Betalingsversjon med grafisk grensesnitt og utmerket støtte.

Ulemper med SymmetricDS

Manuelt må man definere replikasjonsregler og retning gjennom SQL-operatører for å laste katalogtabeller, noe som kan være upraktisk.
Å sette opp mange tabeller for replikering kan være slitsomt hvis man ikke bruker skript for å opprette SQL-operatører som definerer replikasjonsreglene og retning.
Loggene inneholder for mye informasjon, og noen ganger må man rydde opp i loggfilen for å unngå at den tar for mye plass.

Oppsummering av SymmetricDS

SymmetricDS lar deg konfigurere toveisreplikering mellom to, tre og til og med flere tusen noder for å utføre replikering og synkronisere filer. Dette er et unikt verktøy som selvstendig utfører mange oppgaver, for eksempel automatisk gjenoppretting av data etter lang tid med nedetid på en node, sikker og effektiv datautveksling mellom noder via HTTPS, automatisk konfliktstyring basert på et sett med regler, osv. SymmetricDS utfører replikering mellom hvilke som helst databaser, så det kan brukes til ulike scenarier, inkludert migrering, oppgradering til en ny versjon, distribusjon, filtrering og konvertering av data på forskjellige plattformer.

Eksempelet er basert på den offisielle korte veiledningen til SymmetricDS. I brukermanualen detaljert beskrivelse av forskjellige begreper knyttet til konfigurasjon av replikering med SymmetricDS.

Kilde: habr.com