Korsreplikering mellan PostgreSQL och MySQL

Jag kommer att beskriva korsreplikering mellan PostgreSQL och MySQL, samt metoder för att ställa in korsreplikering mellan de två databasservrarna. Vanligtvis kallas korsreplikerade databaser homogena, och det är en bekväm metod för att flytta från en RDBMS-server till en annan.

PostgreSQL- och MySQL-databaser anses generellt vara relationella, men med ytterligare tillägg erbjuder de NoSQL-funktioner. Här kommer vi att diskutera replikering mellan PostgreSQL och MySQL ur ett relationellt DBMS-perspektiv.

Vi kommer inte att beskriva hela det inre arbetet, bara de grundläggande principerna så att du får en uppfattning om att konfigurera replikering mellan databasservrar, fördelar, begränsningar och användningsfall.

Vanligtvis görs replikering mellan två identiska databasservrar antingen i binärt läge eller med hjälp av frågor mellan en master (a.k.a. utgivare, master eller aktiv) och en slav (abonnent, standby eller passiv). Syftet med replikering är att tillhandahålla en realtidskopia av masterdatabasen på slavsidan. I detta fall överförs data från master till slav, det vill säga från aktiv till passiv, eftersom replikering endast utförs i en riktning. Men du kan ställa in replikering mellan två databaser i båda riktningarna, så att data överförs från slav till master i en aktiv-aktiv konfiguration. Allt detta, inklusive kaskadreplikering, är möjligt mellan två eller flera identiska databasservrar. Aktiv-aktiv eller aktiv-passiv konfiguration beror på behov, tillgången på sådana möjligheter i den initiala konfigurationen eller användningen av externa konfigurationslösningar och befintliga avvägningar.

Den beskrivna konfigurationen är möjlig mellan olika databasservrar. Servern kan konfigureras för att acceptera replikerad data från en annan databasserver och fortfarande upprätthålla ögonblicksbilder i realtid av replikerad data. MySQL och PostgreSQL erbjuder de flesta av dessa konfigurationer internt eller via tredjepartstillägg, inklusive binära loggmetoder, disklåsning och uttalande- och radbaserade metoder.

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å det är inte möjligt att länka dem direkt. För att etablera datautbyte kan du använda ett externt verktyg med öppen källkod, till exempel pg_chameleon.

Vad är pg_chameleon

pg_chameleon är ett replikeringssystem från MySQL till PostgreSQL i Python 3. Det använder mysql-replikeringsbiblioteket med öppen källkod, även i Python. Radbilder extraheras från MySQL-tabeller och lagras som JSONB-objekt i PostgreSQL-databasen, och dekrypteras sedan med pl/pgsql-funktionen och reproduceras i PostgreSQL-databasen.

Funktioner av pg_chameleon

Flera MySQL-scheman från samma kluster kan replikeras till en enda mål-PostgreSQL-databas i en en-till-många-konfiguration
Käll- och målschemanamnen kan inte vara desamma.
Replikeringsdata kan hämtas från en kaskadkopplad MySQL-replik.
Tabeller som inte kan replikera eller skapa fel exkluderas.
Varje replikeringsfunktion styrs av demoner.
Styrning via YAML-baserade parametrar och konfigurationsfiler.

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. Det här exemplet installerar Python 3.6.8, som skapar och aktiverar den virtuella miljön.

$> 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 att ha lyckats installera Python3.6 måste du uppfylla de återstående kraven, som att skapa och aktivera en virtuell miljö. Dessutom uppdateras pip-modulen till den senaste versionen och används för att installera pg_chameleon. Kommandona nedan installerar avsiktligt pg_chameleon 2.0.9, även om den senaste versionen är 2.0.10. Detta är nödvändigt 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

Vi anropar sedan pg_chameleon (chameleon är ett kommando) med argumentet set_configuration_files för att aktivera pg_chameleon och skapa standardkataloger och konfigurationsfiler.

(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

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

$> 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 det här exemplet är en exempelfil pg_chameleon med mindre modifieringar för att passa käll- och målmiljön, och nedan finns en översikt över de olika delarna av konfigurationsfilen.

I konfigurationsfilen default.yml finns en sektion med globala inställningar, där du kan hantera inställningar som platsen för låsfilen, platsen för loggar, lagringsperioden för loggar, etc. Därefter kommer avsnittet för typöverstyrning, där en uppsättning regler för att åsidosätta typer under replikering. I exemplet används en typöverstyrande regel som konverterar tinyint(1) till ett booleskt värde. I nästa avsnitt anger vi anslutningsdetaljerna till måldatabasen. I vårt fall är detta en PostgreSQL-databas, betecknad pg_conn. I det sista avsnittet anger vi källdata, det vill säga anslutningsparametrarna för källdatabasen, mappningsschemat mellan käll- och måldatabaserna, tabeller som måste hoppas över, väntetid, minne, paketstorlek. Observera att "källor" är plural, vilket betyder att vi kan lägga till flera källdatabaser till en enda måldatabas för att skapa en många-till-en-konfiguration.

Exempeldatabasen world_x innehåller 4 tabeller med rader som MySQL-communityt erbjuder som exempel. Det går att ladda ner här. Exempeldatabasen kommer som ett tar och komprimerat arkiv med instruktioner för att skapa och importera rader.

I MySQL- och PostgreSQL-databaser skapas en speciell användare med samma namn usr_replica. I MySQL ges den ytterligare läsrättigheter till 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 db_replica-databas som accepterar ändringar från MySQL-databasen. Användaren usr_replica i PostgreSQL konfigureras automatiskt som ägare till två scheman, pgworld_x och sch_chameleon, som innehåller de faktiska replikerade tabellerna respektive replikeringskatalogtabellerna. Argumentet create_replica_schema är ansvarigt för automatisk konfiguration, 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 är konfigurerad med några parameterändringar för att förbereda den för replikering enligt nedan. Du måste starta om databasservern 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

Nu är det viktigt att kontrollera anslutningen till båda databasservrarna så att det inte blir några problem när man kör kommandona 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 nästa tre kommandona pg_chameleon (chameleon) förbereder miljön, lägg till källan och initiera repliken. Argumentet create_replica_schema till pg_chameleon skapar ett standardschema (sch_chameleon) och ett replikeringsschema (pgworld_x) i PostgreSQL-databasen, som vi redan diskuterat. Argumentet add_source lägger till en källdatabas till 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

Utdata från dessa tre kommandon indikerar tydligt att de utfördes framgångsrikt. Eventuella krascher eller syntaxfel rapporteras i enkla, tydliga meddelanden med tips om hur man åtgärdar problemet.

Slutligen startar vi replikering med start_replica och får ett framgångsmeddelande.

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

Replikeringsstatus kan frågas med hjälp av argumentet show_status, och fel kan ses med argumentet show_errors.

Resultatet.

Som vi redan har sagt, kontrolleras varje replikeringsfunktion av demoner. För att se dem frågar vi processtabellen med kommandot Linux ps, som visas nedan.

Resultatet.

Replikering anses inte vara konfigurerad förrän vi testar den i realtid, som visas nedan. Vi skapar en tabell, infogar ett par poster i MySQL-databasen och anropar sync_tables-argumentet i pg_chameleon för att uppdatera demonerna och replikera tabellen med posterna till 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.

För att bekräfta testresultaten frågar vi tabellen från PostgreSQL-databasen och matar 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 ​​gör en migrering kommer följande pg_chameleon-kommandon att vara slutet på det. Kommandona måste köras efter att vi är säkra på att raderna i alla måltabeller har replikerats, och resultatet blir en snyggt migrerad PostgreSQL-databas utan referenser till källdatabasen eller replikeringsschemat (sch_chameleon).

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

Om så önskas kan du använda följande kommandon för att ta bort den ursprungliga konfigurationen och replikeringsschemat.

$> 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.
Felsök och identifiera enkelt avvikelser med tydliga felmeddelanden.
Ytterligare specialtabeller kan läggas till replikering efter initiering utan att ändra resten av konfigurationen.
Det är möjligt att konfigurera flera källdatabaser för en enda måldatabas, och detta är mycket användbart om du kombinerar data från en eller flera MySQL-databaser till en enda PostgreSQL-databas.
Du behöver inte replikera de valda tabellerna.

Nackdelar med pg_chameleon

Stöds endast med MySQL 5.5 och senare som källa och PostgreSQL 9.5 och högre som måldatabas.
Varje tabell måste ha en primär eller unik nyckel, annars initieras tabellerna under init_replica-processen men replikeras inte.
Envägsreplikering - endast från MySQL till PostgreSQL. Därför är den endast lämplig för den "aktiva-passiva" kretsen.
Källan kan bara vara en MySQL-databas, och stödet för en PostgreSQL-databas som källa är endast experimentellt och med begränsningar (läs mer här)

Resultat för pg_chameleon

Replikeringsmetoden i pg_chameleon är utmärkt för att migrera en databas från MySQL till PostgreSQL. Den betydande nackdelen är att replikering bara är enkelriktad, så databasproffs kommer sannolikt inte att vilja använda den för något annat än migrering. Men problemet med envägsreplikering kan lösas med ett annat verktyg med öppen källkod - SymmetricDS.

Läs mer i den officiella dokumentationen här. Kommandoradshjälp kan hittas här.

Översikt över SymmetricDS

SymmetricDS är ett verktyg med öppen källkod som replikerar vilken databas som helst till vilken annan vanlig databas som helst: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird och andra molndatabasinstanser, t.ex. Redshift och Azure, etc. Tillgängliga funktioner: databas- och filsynkronisering, multi-master databasreplikering, filtrerad synkronisering, transformation och annat. Detta är ett Java-verktyg och kräver en standardversion av JRE eller JDK (version 8.0 eller högre). Här kan dataändringar av triggers i källdatabasen registreras och skickas till lämplig måldatabas i form av batcher.

SymmetricDS funktioner

Verktyget är plattformsoberoende, vilket innebär att två eller flera olika databaser kan utbyta data.
Relationsdatabaser synkroniseras med hjälp av dataändringsposter, medan filsystembaserade databaser använder filsynkronisering.
Tvåvägsreplikering med Push- och Pull-metoder baserat på en uppsättning regler.
Dataöverföring är möjlig över säkra nätverk med låg bandbredd.
Automatisk återställning när noder återupptas efter ett fel och automatisk konfliktlösning.
Molnkompatibla och kraftfulla API:er för tillägg.

Exempel

SymmetricDS kan konfigureras på ett av två sätt:
En huvudnod (föräldernod) som centralt koordinerar datareplikering mellan två slavnoder (undernoder), och kommunikation mellan underordnade noder sker endast genom föräldern.
En aktiv nod (nod 1) kan kommunicera för replikering med en annan aktiv nod (nod 2) utan en mellanhand.

I båda alternativen sker datautbyte med Push och Pull. I det här exemplet kommer vi att överväga en aktiv-aktiv konfiguration. Det skulle ta för lång tid att beskriva hela arkitekturen, så gör din research. ledningför att lära dig mer om SymmetricDS-enheten.

Att installera SymmetricDS är mycket enkelt: ladda ner open source-versionen av zip-filen hence och ta ut den var du vill. Tabellen nedan ger information om installationsplatsen och versionen av SymmetricDS i det här exemplet, samt databasversioner, Linux-versioner, IP-adresser och portar för båda noderna.

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

SymmetricDS version
SymmetricDS 3.9
SymmetricDS 3.9

SymmetricDS installationsväg
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

SymmetricDS nodnamn
corp-000
butik-001

Här installerar vi SymmetricDS i /usr/local/symmetric-server-3.9.20, och olika underkataloger och filer kommer att lagras där. Vi är intresserade av underkatalogerna för prover och motorer. Exempelkatalogen innehåller exempel på konfigurationsfiler med nodegenskaper, samt exempel på SQL-skript för att snabbt komma igång.

I provkatalogen ser vi tre konfigurationsfiler med nodegenskaper - namnet visar arten av noden i ett visst schema.

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

SymmetricDS har alla nödvändiga konfigurationsfiler för en grundläggande 3-nodsdesign (alternativ 1), och samma filer kan användas för en 2-nodsdesign (alternativ 2). Kopiera den nödvändiga konfigurationsfilen från provkatalogen till motorer på vm1-värden. 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 databasanslutningen hanteras av mysql jdbc-drivrutinen, som använder anslutningssträngen ovan och inloggningsuppgifterna. Vi ansluter till replica_db-databasen och tabeller kommer att skapas när schemat skapas. sync.url visar var du kan kontakta noden för synkronisering.

Nod 2 på värd vm2 är konfigurerad som store-001 och resten anges i filen node.properties nedan. Node store-001 kör PostgreSQL-databasen och pgdb_replica är replikeringsdatabasen. registration.url tillåter värd vm2 att kontakta värd vm1 och ta emot konfigurationsdetaljer från 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ärdiga SymmetricDS-exemplet innehåller parametrar för att ställa in tvåvägsreplikering mellan två databasservrar (två noder). Stegen nedan utförs på värd vm1 (corp-000), vilket kommer att skapa ett exempelschema med 4 tabeller. Att sedan köra create-sym-tables med kommandot symadmin skapar katalogtabeller där reglerna och riktningen för replikering mellan noder kommer att lagras. Slutligen läses exempeldata in 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 artikel- och artikelförsäljningspris automatiskt konfigurerade att replikera från corp-000 till butik-001, och försäljningstabellerna (försäljningstransaktion och försäljningsreturrad) är automatiskt konfigurerade att replikera från butik-001 till företag-000. Nu skapar vi ett schema i PostgreSQL-databasen på host vm2 (store-001) för att förbereda det 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

Se till att kontrollera att MySQL-databasen på vm1 har exempeltabeller och SymmetricDS-katalogtabeller. Observera att SymmetricDS-systemtabellerna (med prefixet sym_) för närvarande endast är tillgängliga på noden corp-000 eftersom det var där vi körde kommandot create-sym-tables och kommer att hantera replikering. Och i databasen på nod store-001 kommer det bara att finnas 4 exempeltabeller utan data.

Allt. Miljön är redo att köra sym-serverprocesser på båda noderna som visas nedan.

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

Loggposter skickas till en bakgrundsloggfil (symmetric.log) i logsmappen i katalogen där SymmetricDS är installerat, samt till standardutdata. Sym-servern kan nu initieras på nod store-001.

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

Om du kör sym-serverprocessen på vm2-värden kommer den också att skapa SymmetricDS-katalogtabeller i PostgreSQL-databasen. Om du kör sym-serverprocessen på båda noderna, koordinerar de med varandra för att replikera data från corp-000 till store-001. Om vi ​​efter några sekunder frågar alla 4 tabellerna på båda sidor kommer vi att se att replikeringen lyckades. Eller så kan du skicka bootstrap till nod store-001 från corp-000 med följande kommando.

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

Vid denna tidpunkt infogas en ny post i objekttabellen i MySQL-databasen på nod corp-000 (värd: vm1), och du kan kontrollera dess replikering till PostgreSQL-databasen på nodbutik-001 (värd: vm2). 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 en push-operation för att flytta data från store-001 till corp-000, infogar vi en post i sale_transaction-tabellen och verifierar att replikeringen är framgångsrik.

Resultatet.

Vi ser den framgångsrika installationen av tvåvägsreplikering av exempeltabellerna mellan MySQL- och PostgreSQL-databaser. Följ dessa steg för att ställa in replikering för nya användartabeller: Vi skapar till exempel tabell t1 och konfigurerar dess replikeringsregler enligt följande. På så sätt konfigurerar vi endast 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 meddelas sedan om schemaändringen, det vill säga tillägget av en ny tabell, med hjälp av kommandot symadmin med argumentet sync-triggers, som återskapar triggers för att mappa tabelldefinitionerna. send-schema exekveras för att skicka schemaändringar till nodlager-001, och replikering av tabell 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 en krets med tre noder eller två noder.
Plattformsövergripande databaser och plattformsoberoende, inklusive servrar, bärbara datorer och mobila enheter.
Replikera vilken databas som helst till vilken annan databas som helst lokalt, på WAN eller i molnet.
Möjlighet till optimalt arbete med ett par databaser eller flera tusen för smidig replikering.
Betalversion med GUI och utmärkt support.

Nackdelar med SymmetricDS

Du måste manuellt definiera reglerna och replikeringsriktningen på kommandoraden genom SQL-satser för att ladda katalogtabeller, vilket kan vara obekvämt.
Att ställa in många tabeller för replikering kan vara tråkigt om du inte använder skript för att skapa SQL-satser som definierar reglerna och riktningen för replikering.
Det finns för mycket information som registreras i loggarna, och ibland behöver du göra i ordning loggfilen så att den inte tar för mycket plats.

Resultat för SymmetricDS

SymmetricDS låter dig ställa in tvåvägsreplikering mellan två, tre eller till och med flera tusen noder för att replikera och synkronisera filer. Detta är ett unikt verktyg som självständigt utför många uppgifter, såsom automatisk dataåterställning efter en lång period av driftstopp på en nod, säkert och effektivt datautbyte mellan noder via HTTPS, automatisk konflikthantering baserad på en uppsättning regler etc. SymmetricDS utför replikering mellan alla databaser, därför kan den användas för en mängd olika scenarier, inklusive migrering, migrering, distribution, filtrering och transformation av data över plattformar.

Exemplet är baserat på tjänstemannen snabb guide av SymmetricDS. I användarmanual Beskriver i detalj de olika koncepten som är involverade i att sätta upp replikering med SymmetricDS.

Källa: will.com