Korsreplikation mellan PostgreSQL och MySQL

Jag kommer att ge en översikt över korsreplication mellan PostgreSQL och MySQL, samt metoder för att konfigurera korsreplication mellan dessa två databasservrar. Vanligtvis kallas databaser i korsreplication homogena, och det är en praktisk metod för att överföra data från en relationsdatabasserver till en annan.

PostgreSQL och MySQL betraktas vanligtvis som relationsdatabaser, men med ytterligare tillägg erbjuder de NoSQL-funktioner. Här kommer vi att diskutera replication mellan PostgreSQL och MySQL utifrån ett relationsdatabassyn.

Vi kommer inte att beskriva hela den interna strukturen, bara de grundläggande principerna, så att du får en uppfattning om hur man konfigurerar replication mellan databasservrar, deras fördelar, begränsningar och användningsscenarier.

Normalt utförs replication mellan två identiska databasservrar antingen i binärt läge eller genom att skicka förfrågningar mellan en primär nod (även kallad utgivare, huvud- eller aktiv nod) och en sekundär nod (abonnent, passiv eller väntande). Syftet med replication är att tillhandahålla en realtidskopi av den primära databasen på den sekundära sidan. Data överförs från den primära till den sekundära, det vill säga från aktiv till passiv, eftersom replication endast utförs i en riktning. Men det är möjligt att konfigurera replication mellan två databaser i båda riktningarna så att data överförs från den sekundära till den primära i en "aktiv-aktiv" konfiguration. Allt detta, inklusive kaskadreplication, är möjligt mellan två eller flera identiska databasservrar. Konfigurationen "aktiv-aktiv" eller "aktiv-passiv" beror på behovet, tillgängligheten av sådana möjligheter i den ursprungliga konfigurationen eller användning av externa lösningar för inställning och befintliga kompromisser.

Den beskrivna konfigurationen är möjlig mellan olika databasservrar. En server kan konfigureras för att ta emot replikerade data från en annan databasserver och samtidigt spara avbilder av de replikerade data i realtid. MySQL och PostgreSQL erbjuder de flesta av dessa konfigurationer antingen själva eller genom tredjepartsersättning, inklusive metoder för binär loggning, diskblockering och metoder som baseras på operatörer och rader.

Korsreplikering mellan MySQL och PostgreSQL behövs för en engångsmigrering från en databasserver till en annan. Dessa databaser använder olika protokoll, så de kan inte kopplas direkt samman. För att möjliggöra datadelning kan man använda ett externt open source-verktyg, som pg_chameleon.

Vad är pg_chameleon

pg_chameleon är ett replikationssystem från MySQL till PostgreSQL byggt på Python 3. Det använder det open source-biblioteket mysql-replication, också skrivet i Python. Rader extraheras från MySQL-tabeller och lagras som JSONB-objekt i PostgreSQL-databasen, och avkodas sedan med funktionen pl/pgsql och återges i PostgreSQL-databasen.

Möjligheter med pg_chameleon

Flera MySQL-scheman från en kluster kan replikeras till en enda måldatabas i PostgreSQL med konfigurationen "ett till många".
Namn på käll- och målscheman får inte vara desamma.
Replikationsdata kan extraheras från en kaskadreplika av MySQL.
Tabeller som inte kan replikeras eller som orsakar fel exkluderas.
Varje replikationsfunktion hanteras av demoner.
Övervakning med hjälp av parametrar och konfigurationsfiler baserade på YAML.

Exempel

Värd
vm1
vm2

OS-version
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

DB-serverversion
MySQL 5.7.26
PostgreSQL 10.5

DB-port
3306
5433

IP-adress
192.168.56.102
192.168.56.106

Börja med att förbereda alla nödvändiga komponenter för att installera pg_chameleon. I detta exempel är Python 3.6.8 installerat, vilket skapar en virtuell miljö och aktiverar den.

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

Efter en framgångsrik installation av Python3.6 behöver man uppfylla övriga krav, som att skapa och aktivera den virtuella miljön. Dessutom uppdateras pip-modulen till den senaste versionen och används för att installera pg_chameleon. I kommandona nedan installerar vi avsiktligt pg_chameleon 2.0.9, även om den senaste versionen är 2.0.10. Detta görs för att undvika nya buggar i den uppdaterade versionen.

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

Sedan anropar vi pg_chameleon (chameleon är kommandot) med argumentet set_configuration_files för att aktivera pg_chameleon och skapa kataloger och konfigurationsfiler enligt standard.

(venv) $> chameleon set_configuration_files
skapar katalog /root/.pg_chameleon
skapar katalog /root/.pg_chameleon/configuration/
skapar katalog /root/.pg_chameleon/logs/
skapar katalog /root/.pg_chameleon/pid/
kopierar konfigurationsexempel till /root/.pg_chameleon/configuration//config-example.yml

Nu skapar vi en kopia av config-example.yml som default.yml, så att den blir standardkonfigurationsfilen. Ett exempel på konfigurationsfil för detta exempel ges nedan.

$> cat default.yml
---
#globala inställningar
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 tillåter användaren att överskrida den standard typkonverteringen till en annan.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

#postgres målanslutning
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 #skippa insättningar på tabellen delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #skippa borttagningar i schemat delphis_mediterranea
      update:

Konfigurationsfilen i detta exempel är ett exempel på en fil med pg_chameleon med små ändringar i enlighet med de ursprungliga och målmiljöerna, och nedan ges en översikt över de olika avsnitten i konfigurationsfilen.

I konfigurationsfilen default.yml finns ett avsnitt för globala parametrar (global settings), där du kan hantera inställningar som låsfilsplacering, loggar, loggförvaringsperiod och så vidare. Sedan följer avsnittet för typöverskrivning (type override), där ett antal regler för typöverskrivning under replikering anges. I standardexemplet används en typöverskrivningsregel som konverterar tinyint(1) till ett boolean-värde. I nästa avsnitt anger vi uppgifterna för anslutning till måldatabasen. I vårt fall handlar det om en PostgreSQL-databas som kallas pg_conn. I det sista avsnittet anger vi datakällor, det vill säga parametrar för anslutning till ursprungsdatabasen, schemaöversättning mellan ursprungs- och måldatabas, tabeller som ska hoppas över, tidsgränser, minne, batchstorlek. Observera att "sources" anges i plural, vilket innebär att vi kan lägga till flera källdatabaser för en mål för att konfigurera en "många till en"-inställning.

Databasen world_x i exemplet innehåller 4 tabeller med rader som MySQL-communityn erbjuder som exempel. Den kan laddas ner här. Exemplet på databasen levereras som en tar-fil och i en komprimerad arkiv med instruktioner för hur man skapar och importerar rader.

I MySQL- och PostgreSQL-databaser skapas en speciell användare med samma namn usr_replica. I MySQL tilldelas den ytterligare rättigheter att läsa alla replikerade 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-sidan skapas en databas db_replica, som kommer att ta emot ändringar från MySQL-databasen. Användaren usr_replica i PostgreSQL konfigureras automatiskt som ägare till de två scheman pgworld_x och sch_chameleon, som innehåller de faktiska replikerade tabellerna och tabellerna med replikeringskataloger respektive. Den automatiska konfigurationen styrs av argumentet create_replica_schema, som du kommer att se nedan.

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

MySQL-databasen konfigureras med ändringar av vissa parametrar för att förbereda den för replikering, som visas nedan. Databasservern måste startas om för att ändringarna ska träda i kraft.

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

Det är nu viktigt att kontrollera anslutningen till båda databasserverna så att det inte uppstår problem när kommandon körs med pg_chameleon.

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öljande tre kommandona i pg_chameleon (chameleon) förbereder miljön, lägger till källan och initierar repliken. Argumentet create_replica_schema i pg_chameleon skapar standardenschema (sch_chameleon) och replikeringsschemat (pgworld_x) i PostgreSQL-databasen, som vi tidigare nämnt. Argumentet add_source lägger till den ursprungliga databasen i konfigurationen genom att läsa konfigurationsfilen (default.yml), och i vårt fall är det mysql, och init_replica initierar konfigurationen baserat på parametrarna i konfigurationsfilen.

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

Resultaten från de tre kommandona indikerar tydligt att de har genomförts framgångsrikt. Alla fel eller syntaxproblem rapporteras i enkla och förståeliga meddelanden med förslag på hur man åtgärdar problemen.

Slutligen ska vi starta replikeringen med hjälp av start_replica och få ett meddelande om att den har genomförts framgångsrikt.

$> chameleon start_replica --config default --source mysql 
output: Startar replikationsprocessen för källan mysql

Replikationsstatus kan begäras med argumentet show_status, medan fel kan granskas med argumentet show_errors.

Result.

Som vi redan nämnt styrs varje replikationsfunktion av demoner. För att visa dem kan vi begära processens tabell med kommandot Linux ps, som visas nedan.

Result.

Replikeringen anses inte vara konfigurerad förrän vi testar den i realtid, som visas nedan. Vi skapar en tabell, infogar ett par poster i databasen MySQL och anropar argumentet sync_tables i pg_chameleon för att uppdatera demonerna och replikera tabellen med posterna till databasen PostgreSQL.

mysql> create table t1 (n1 int primary key, n2 varchar(10));
Fråga OK, 0 rader påverkade (0.01 sek)
mysql> insert into t1 values (1,'one');
Fråga OK, 1 rad påverkad (0.00 sek)
mysql> insert into t1 values (2,'two');
Fråga OK, 1 rad påverkad (0.00 sek)

$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Synkronisering av tabeller process för källan mysql startad.

För att bekräfta testresultaten, begär vi tabellen från PostgreSQL-databasen och skriver ut raderna.

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

Om vi utför migrering, kommer följande kommandon pg_chameleon att avsluta den. Kommandona ska utföras efter att vi har verifierat att raderna i alla måltabeller har replikeras, och resultatet kommer att bli en noggrant överförd PostgreSQL-databas utan hänvisningar till den ursprungliga databasen eller replikeringens schema (sch_chameleon).

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

Vid behov kan du med följande kommandon ta bort den ursprungliga konfigurationen och replikationsschemat.

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

Fördelar med pg_chameleon

Enkel installation och konfiguration.
Lätt att felsöka och upptäcka avvikelser med tydliga felmeddelanden.
Det går att lägga till ytterligare specialtabeller till replikationen efter initiering, utan att ändra den övriga konfigurationen.
Du kan konfigurera flera källdatabaser för en mål databas, vilket är mycket bekvämt om du samlar data från en eller flera MySQL-databaser till en PostgreSQL-databas.
Det går att utesluta valda tabeller från replikeringen.

Nackdelar med pg_chameleon

Stöder endast MySQL 5.5 och senare som källa och PostgreSQL 9.5 och senare som måldatabas.
Varje tabell måste ha en primär eller unik nyckel, annars initieras tabellerna under init_replica-processen men replikeras inte.
Enkelriktad replikering — endast från MySQL till PostgreSQL. Därför passar den endast för en "aktiv-passiv"-modell.
Källan kan endast vara en MySQL-databas, och stöd för PostgreSQL som källa är endast experimentellt och med begränsningar (läs mer) här)

Sammanfattning av pg_chameleon

Replikationsmetoden i pg_chameleon är utmärkt för migrering av databasen från MySQL till PostgreSQL. En betydande nackdel är att replikeringen är enkelriktad, vilket gör att databasspecialister sällan kommer att vilja använda den för något annat än migrering. Men problemet med enkelriktad replikering kan lösas med ett annat open source-verktyg — SymmetricDS.

Läs mer i den officiella dokumentationen här. Hjälpen för kommandoraden finns tillgänglig här.

Översikt av SymmetricDS

SymmetricDS är ett open source-verktyg som replikera vilken databas som helst till vilken annan populär databas som helst: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird och andra molnbaserade databasinstanser, såsom Redshift, Azure etc. Tillgängliga funktioner: databas- och filsynkronisering, replikering av flera ledande databaser, filtrerad synkronisering, transformering och mer. Det är ett verktyg i Java, och standardutgåvan av JRE eller JDK (version 8.0 eller senare) krävs. Här kan du registrera databasändringar via triggers i källdatabasen och skicka dem till motsvarande måldatabas i form av paket.

Funktioner i SymmetricDS

Verktyget är plattformsoberoende, vilket innebär att två eller flera olika databaser kan utbyta data.
Relationsdatabaser synkroniseras genom databasändringsregistrering, medan filsystembaserade databaser använder filsynkronisering.
Dubbelriktad replikering med användning av Push- och Pull-metoder baserat på regler.
Dataöverföring är möjlig över skyddade nätverk och nätverk med låg bandbredd.
Automatisk återställning vid återstart av noder efter ett fel och automatisk konfliktlösning.
Kompatibilitet med molnet och effektiva API:er för tillägg.

Exempel

SymmetricDS kan konfigureras på ett av två sätt:
En ledande (parent) nod som centralt koordinerar datareplication mellan två följande (child) noder, och datautbyte mellan de följande noderna sker endast genom den ledande noden.
Den aktiva noden (nod 1) kan utbyta data för replikering med en annan aktiv nod (nod 2) utan mellanhand.

I båda konfigurationerna sker datautbyte med hjälp av Push och Pull. I detta exempel kommer vi att titta på konfigurationen "aktiv-aktiv". Att beskriva hela arkitekturen tar för lång tid, så titta på en guide, för att lära dig mer om SymmetricDS.

Att installera SymmetricDS är mycket enkelt: ladda ner den öppen källkodsversionen av zip-filen härifrån och extrahera den vart du vill. I tabellen nedan ger vi information om installationsställe och version av SymmetricDS i detta exempel, liksom databasversioner, Linux-versioner, IP-adresser och portar för båda noder.

Värd
vm1
vm2

OS-version
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

DB-serverversion
MySQL 5.7.26
PostgreSQL 10.5

DB-port
3306
5832

IP-adress
192.168.1.107
192.168.1.112

Version av SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9

Installationsväg för SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

Namn på SymmetricDS-nod
corp-000
store-001

Här installerar vi SymmetricDS i /usr/local/symmetric-server-3.9.20, och olika underkataloger och filer kommer att lagras här. Vi är intresserade av underkatalogerna samples och engines. I katalogen samples lagras exempelkonfigurationsfiler med nodens egenskaper samt exempel på SQL-skript för en snabb start av demonstrationer.

I katalogen samples ser vi tre konfigurationsfiler med nodens egenskaper — namnen visar nodens karaktär i en viss schem.

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

SymmetricDS levererar alla nödvändiga konfigurationsfiler för ett grundschema med 3 noder (alternativ 1), och samma filer kan användas för ett schema med 2 noder (alternativ 2). Kopiera den nödvändiga konfigurationsfilen från katalogen samples till engines på värden vm1. Det blir så här:

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

Denna nod i SymmetricDS-konfigurationen kallas corp-000, och anslutningen till databasen hanteras av mysql jdbc-drivrutinen, som använder den ovan angivna anslutningssträngen och inloggningsuppgifterna. Vi ansluter till databasen replica_db, och under skapandet av schemat kommer tabeller att skapas. sync.url visar platsen för att koppla samman med noden för synkronisering.

Nod 2 på värden vm2 är konfigurerad som store-001, och resten anges i filen node.properties, som återges nedan. Nod store-001 använder PostgreSQL-databasen, och pgdb_replica är databasen för replikering. registration.url tillåter värden vm2 att koppla upp sig mot värden vm1 och hämta konfigurationsdetaljer.

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

Ett färdigt exempel på SymmetricDS innehåller parametrar för att konfigurera tvåvägs replikering mellan två databasserverar (två noder). Stegen nedan utförs på värden vm1 (corp-000), som kommer att skapa ett exempel på schema med 4 tabeller. Därefter kommer kommandot create-sym-tables i symadmin att skapa katalogtabeller där regler och riktning för replikering mellan noder kommer att lagras. Slutligen laddas exempeldata upp i tabellerna.

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 exemplet är tabellerna item och item_selling_price automatiskt konfigurerade för replikering från corp-000 till store-001, och tabellerna sale (sale_transaction och sale_return_line_item) är automatiskt konfigurerade för replikering från store-001 till corp-000. Nu skapar vi ett schema i PostgreSQL-databasen på värden vm2 (store-001) för att förbereda den för att ta emot data från corp-000.

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

Det är viktigt att kontrollera att det finns exempeldata i MySQL-databasen på vm1, liksom katalogtabellerna för SymmetricDS. Observera att systemtabellerna för SymmetricDS (med prefikset sym_) för närvarande endast är tillgängliga på noden corp-000, eftersom vi där har utfört kommandot create-sym-tables och kommer att hantera replikeringen. Dessutom kommer databasen på noden store-001 att ha totalt 4 exempel tabeller utan data.

Klart. Miljön är redo för att köra serverprocesserna sym på båda noderna, som visas nedan.

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

Loggning av registreringar skickas till filen för bakgrundsloggen (symmetric.log) i loggmappen i katalogen där SymmetricDS är installerat, samt till standardutdata. Sym-servern kan nu initieras på noden store-001.

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

Om man startar serverprocessen sym på värden vm2 kommer det att skapa SymmetricDS-katalogtabeller även i PostgreSQL-databasen. Om serverprocessen sym körs på båda noderna kommer de att samordna sig med varandra för att replikera data från corp-000 till store-001. Om vi efter några sekunder begär alla 4 tabeller på båda sidor kommer vi att se att replikeringen har genomförts framgångsrikt. Alternativt kan vi skicka en initial laddning till noden store-001 från corp-000 med följande kommando.

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

Vid det här laget sätts en ny post in i item-tabellen i MySQL-databasen på noden corp-000 (värd: vm1), och vi kan kontrollera dess replikering till PostgreSQL-databasen på noden store-001. Vi ser en Pull-operation för att flytta data från corp-000 till 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)

För att utföra Push-operationen för att flytta data från store-001 till corp-000, sätter vi in en post i sale_transaction-tabellen och kontrollerar att replikeringen har genomförts.

Result.

Vi ser en framgångsrik inställning av tvåvägsreplikering av exempeltabellerna mellan MySQL- och PostgreSQL-databaserna. För att ställa in replikering för nya användartabeller följer vi dessa steg. Vi skapar tabellen t1 som ett exempel och ställer in reglerna för dess replikering på följande sätt. Så ställer vi endast in replikering från corp-000 till 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 sedan ett meddelande om ändring av schemat, det vill säga tillägg av en ny tabell, via kommandot symadmin med argumentet sync-triggers, som återskapar triggers för att matcha tabelldefinitionerna. send-schema körs för att skicka schemaändringarna till noden store-001, och replikeringen av tabellen t1 konfigureras.

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

Fördelar med SymmetricDS

Enkel installation och konfiguration, inklusive en färdig uppsättning filer med parametrar för att skapa scheman med tre eller två noder.
Plattformsoberoende databas och oberoende av plattform, inklusive servrar, bärbara datorer och mobila enheter.
Replikering av vilken databas som helst till vilken annan databas som helst lokalt, i WAN eller i molnet.
Möjligheten till optimal drift med ett par databaser eller flera tusen för bekväm replikering.
Betald version med grafiskt gränssnitt och utmärkt support.

Nackdelar med SymmetricDS

Man behöver manuellt ange regler och riktning för replikering via SQL-operatörer för att ladda katalogtabeller, vilket kan vara besvärligt.
Att konfigurera många tabeller för replikering kan vara tröttsamt om man inte använder skript för att skapa SQL-operatörer som definierar regler och riktning för replikeringen.
Det skrivs för mycket information i loggarna, och ibland måste man städa upp loggfilen så att den inte tar för mycket plats.

Sammanfattning av SymmetricDS

SymmetricDS möjliggör konfiguration av tvåvägsreplikering mellan två, tre och till och med flera tusen noder för att utföra replikering och synkronisera filer. Detta är ett unikt verktyg som själv utför många uppgifter, såsom automatisk återställning av data efter långvarigt driftstopp på en nod, säker och effektiv dataöverföring mellan noder över HTTPS, automatisk hantering av konflikter baserat på ett regelsystem etc. SymmetricDS utför replikering mellan valfria databaser, vilket gör att den kan användas för en mängd olika scenarier, inklusive migrering, uppgradering, distribution, filtrering och omvandling av data på olika plattformar.

Exemplet är skapat baserat på den officiella kortguiden till SymmetricDS. I användarhandboken detaljerat beskrivs olika begrepp relaterade till att konfigurera replikering med SymmetricDS.

Källa: habr.com