En översikt över PostgreSQL &MySQL Cross Replication

Den här bloggen syftar till att förklara en översikt av korsreplikering mellan PostgreSQL och MySQL, och ytterligare diskutera metoderna för att konfigurera korsreplikering mellan de två databasservrarna. Traditionellt kallas databaserna som är involverade i en korsreplikeringskonfiguration heterogena databaser, vilket är ett bra sätt att flytta från en RDBMS-server till en annan.

Både PostgreSQL- och MySQL-databaser är konventionella RDBMS-databaser men de erbjuder också NoSQL-kapacitet med tillägg för att få det bästa av två världar. Den här artikeln fokuserar på diskussionen om replikering mellan PostgreSQL och MySQL ur ett RDBMS-perspektiv.

En uttömmande förklaring om interna replikeringar ligger inte inom ramen för denna blogg, men några grundläggande element ska diskuteras för att ge publiken en förståelse för hur replikering konfigureras mellan databasservrar, fördelar, begränsningar och kanske några kända användningsfall.

Generellt sett uppnås replikering mellan två identiska databasservrar antingen i binärt läge eller frågeläge mellan en masternod (annars kallad utgivare, primär eller aktiv) och en slavnod (abonnent, standby eller passiv). Syftet med replikering är att tillhandahålla en realtidskopia av masterdatabasen på slavsidan, där data överförs från master till slav, och därigenom bilda en aktiv-passiv setup eftersom replikeringen bara är konfigurerad att ske på ett sätt. Å andra sidan kan replikering mellan två databaser konfigureras åt båda hållen så att data också kan överföras från slav tillbaka till master, vilket skapar en aktiv-aktiv konfiguration. Allt detta kan konfigureras mellan två eller flera identiska databasservrar som också kan inkludera en kaskadreplikering. Konfigurationen av aktiv-aktiv eller aktiv-passiv beror verkligen på affärsbehovet, tillgängligheten av sådana funktioner inom den inbyggda konfigurationen eller användning av externa lösningar för att konfigurera och tillämpliga avvägningar.

Den ovan nämnda konfigurationen kan åstadkommas med olika databasservrar, varvid en databasserver kan konfigureras för att acceptera replikerad data från en annan helt annan databasserver och fortfarande upprätthålla ögonblicksbild i realtid av data som replikeras. Både MySQL- och PostgreSQL-databasservrar erbjuder de flesta av de konfigurationer som diskuterats ovan, antingen i sin egen nativitet eller med hjälp av tredjepartstillägg inklusive binär loggmetod, diskblockeringsmetod, satsbaserade och radbaserade metoder.

Kravet att konfigurera en korsreplikering mellan MySQL och PostgreSQL kommer verkligen in som ett resultat av en engångsmigreringsansträngning för att flytta från en databasserver till en annan. Eftersom båda databaserna använder olika protokoll så kan de inte direkt prata med varandra. För att uppnå det kommunikationsflödet finns det ett externt verktyg med öppen källkod som pg_chameleon.

Bakgrund för pg_chameleon

pg_chameleon är ett MySQL till PostgreSQL-replikeringssystem utvecklat i Python 3. Det använder ett bibliotek med öppen källkod som heter mysql-replikering som också är utvecklat med Python. Funktionen innefattar att dra radbilder av MySQL-tabeller och lagra dem som JSONB-objekt i en PostgreSQL-databas, som avkodas ytterligare av en pl/pgsql-funktion och spela upp dessa ändringar mot PostgreSQL-databasen.

Funktioner hos pg_chameleon

• Flera MySQL-scheman från samma kluster kan replikeras till en enda mål-PostgreSQL-databas, vilket bildar en replikeringsinställning för många till en
• Käll- och målschemanamnen kan vara icke-identiska
• Replikeringsdata kan hämtas från MySQL-kaskadreplik
• Tabeller som inte kan replikera eller generera fel exkluderas
• Varje replikeringsfunktionalitet hanteras med hjälp av demoner
• Styrs med hjälp av parametrar och konfigurationsfiler baserade på YAML-konstruktion

Demo

Till att börja med, förbered installationen med alla förutsättningar som behövs för att installera pg_chameleon. I den här demon installeras Python 3.6.8, vilket skapar en virtuell miljö och aktiverar den för användning.

$> 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 lyckad installation av Python3.6 uppfylls ytterligare ytterligare krav som att skapa och aktivera en virtuell miljö. Utöver att pip-modulen uppgraderades till den senaste versionen och den används för att installera pg_chameleon. I kommandona nedan installerades pg_chameleon 2.0.9 medvetet medan den senaste versionen är en 2.0.10. Detta görs för att undvika eventuella nyintroducerade 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

Nästa steg är att anropa pg_chameleon (chameleon är kommandot) med set_configuration_files argument för att pg_chameleon ska kunna 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

Skapa nu en kopia av config-example.yml som default.yml för att göra den till standardkonfigurationsfilen. Ett exempel på en konfigurationsfil som används för denna demo 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 som används i denna demo är exempelfilen som följer med pg_chameleon med mindre ändringar för att passa käll- och destinationsmiljöerna, och en sammanfattning av olika avsnitt av konfigurationsfilen följer.

Konfigurationsfilen default.yml har en "globala inställningar"-sektion som kontrollerar detaljer som låsfilsplats, loggningsplatser och lagringsperiod, etc. Avsnittet som följer härnäst är avsnittet "typ åsidosättande" som är en uppsättning regler att åsidosätta typer under replikering. En överstyrningsregel för exempeltyp används som standard som konverterar en tinyint(1) till ett booleskt värde. Nästa avsnitt är avsnittet med destinationsdatabasanslutningsdetaljer som i vårt fall är en PostgreSQL-databas, betecknad med "pg_conn". Det sista avsnittet är källsektionen som har alla detaljer om källdatabasanslutningsinställningar, schemamappning mellan källa och destination, eventuella tabeller att hoppa över inklusive timeout, minne och inställningar för batchstorlek. Lägg märke till "källorna" som anger att det kan finnas flera källor till en enda destination för att bilda en replikeringsuppsättning för många till en.

En "world_x"-databas används i denna demo som är en exempeldatabas med 4 tabeller som innehåller exempelrader, som MySQL-communityt erbjuder för demoändamål, och den kan laddas ner härifrån. Exempeldatabasen kommer som ett tar och komprimerat arkiv tillsammans med instruktioner för att skapa den och importera rader i den.

En dedikerad användare skapas i både MySQL- och PostgreSQL-databaserna med samma namn som usr_replica som dessutom ges ytterligare privilegier på MySQL för att ha läsbehörighet till alla tabeller som replikeras.

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;

En databas skapas på PostgreSQL-sidan som accepterar ändringar från MySQL-databasen, som heter "db_replica". "usr_replica"-användaren i PostgreSQL konfigureras automatiskt som ägare av två scheman såsom "pgworld_x" och "sch_chameleon" som innehåller de faktiska replikerade tabellerna respektive katalogtabellerna för replikering. Denna automatiska konfiguration görs av argumentet create_replica_schema, som anges längre fram 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, som visas nedan, och den kräver en omstart av 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

Vid det här laget är det viktigt att testa anslutningen till båda databasservrarna för att säkerställa att det inte finns några problem när pg_chameleon-kommandon körs.

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 för pg_chameleon (chameleon) är där den ställer in miljön, lägger till en källa och initierar en replik. Argumentet "create_replica_schema" för pg_chameleon skapar standardschemat (sch_chameleon) och replikeringsschemat (pgworld_x) i PostgreSQL-databasen, vilket redan har diskuterats. Argumentet "add_source" lägger till källdatabasen till konfigurationen genom att läsa konfigurationsfilen (default.yml), som i det här fallet är "mysql", medan "init_replica" initierar konfigurationen baserat på inställningarna för 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 ovanstående tre kommandon är självförklarande och indikerar framgången för varje kommando med ett tydligt utmatningsmeddelande. Eventuella fel eller syntaxfel nämns tydligt i enkla och tydliga meddelanden, vilket föreslår och uppmanar till korrigerande åtgärder.

Det sista steget är att starta replikeringen med "start_replika", vars framgång indikeras av en utmatningstips som visas nedan.

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

Statusen för replikeringen kan frågas med argumentet "show_status" medan fel kan ses med argumentet "show_errors".

$> chameleon show_status --source mysql  
OUTPUT: 
  Source id  Source name    Type    Status    Consistent    Read lag    Last read    Replay lag    Last replay
-----------  -------------  ------  --------  ------------  ----------  -----------  ------------  -------------
          1  mysql          mysql   running   No            N/A                      N/A

== Schema mappings ==
Origin schema    Destination schema
---------------  --------------------
world_x          pgworld_x

== Replica status ==
---------------------  ---
Tables not replicated  0
Tables replicated      4
All tables             4
Last maintenance       N/A
Next maintenance       N/A
Replayed rows
Replayed DDL
Skipped rows
---------------------  ---
$> chameleon show_errors --config default 
output: There are no errors in the log

Som diskuterats tidigare att var och en av replikeringsfunktionerna hanteras med hjälp av demoner, som kan ses genom att fråga processtabellen med Linux-kommandot "ps", som visas nedan.

$>  ps -ef|grep chameleon
root       763     1  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       764   763  0 19:20 ?        00:00:01 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       765   763  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql

Ingen replikeringsinställning är klar förrän den har ställts på "applicering i realtid", som har simulerats enligt nedan. Det innebär att skapa en tabell och infoga ett par poster i MySQL-databasen, därefter anropas "sync_tables"-argumentet för pg_chameleon för att uppdatera demonerna för att replikera tabellen tillsammans med dess poster 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.

Testet bekräftas genom att fråga tabellen från PostgreSQL-databasen för att återspegla raderna.

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

Om det är ett migreringsprojekt kommer följande pg_chameleon-kommandon att markera slutet på migreringsansträngningen. Kommandona ska köras efter att det har bekräftats att rader i alla måltabeller har replikerats över, och resultatet kommer att bli en rent migrerad PostgreSQL-databas utan några referenser till källdatabasen eller replikeringsschemat (sch_chameleon).

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

Alternativt kommer följande kommandon att ta bort källkonfigurationen och replikeringsschemat.

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

Fördelar med att använda pg_chameleon

• Enkel att installera och mindre komplicerad konfiguration
• Smärtfri felsökning och avvikelsedetektering med lättförståeliga felutdata
• Ytterligare adhoc-tabeller kan läggas till i replikeringen efter initiering, utan att ändra någon annan konfiguration
• Flera källor kan konfigureras för en enda måldatabas, vilket är användbart i konsolideringsprojekt för att slå samman data från en eller flera MySQL-databaser till en enda PostgreSQL-databas
• Utvalda tabeller kan hoppas över från att replikeras

Nackdelar med att använda pg_chameleon

• Stöds endast från MySQL 5.5 och framåt som Origin-databas och PostgreSQL 9.5 och framåt för destinationsdatabas
• Kräver att varje tabell har en primär eller unik nyckel, annars initieras tabellerna under init_replica-processen men de kommer inte att replikera
• Envägsreplikering, d.v.s. MySQL till PostgreSQL. Därmed begränsas dess användning till endast en aktiv-passiv installation
• Källdatabasen kan endast vara en MySQL-databas medan stöd för PostgreSQL-databas som källa är experimentellt med ytterligare begränsningar (klicka här för att lära dig mer)

pg_chameleon Sammanfattning

Replikeringsmetoden som erbjuds av pg_chameleon är gynnsam för en databasmigrering av MySQL till PostgreSQL. En av de betydande begränsningarna för envägsreplikering kan dock avskräcka databasproffs att använda den för allt annat än migrering. Denna nackdel med enkelriktad replikering kan åtgärdas med ytterligare ett verktyg med öppen källkod som heter SymmetricDS.

För att studera verktyget mer i detalj, se den officiella dokumentationen här. Kommandoradsreferensen kan erhållas härifrån.

En översikt över SymmetricDS

SymmetricDS är ett verktyg med öppen källkod som kan replikera vilken databas som helst till vilken annan databas som helst, från den populära listan över databasservrar som Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird och andra molnbaserade databasinstanser som Redshift och Azure etc. Några av erbjudandena inkluderar databas- och filsynkronisering, multi-master replikering, filtrerad synkronisering och transformation. Verktyget är utvecklat med Java, vilket kräver en standardutgåva (version 8.0 eller högre) av antingen JRE eller JDK. Funktionaliteten innebär att dataändringar fångas upp av triggers vid källdatabasen och dirigerar den till en deltagande destinationsdatabas som utgående batcher

Funktioner i SymmetricDS

• Plattformoberoende, vilket innebär att två eller flera olika databaser kan kommunicera med varandra, vilken databas som helst till vilken annan databas som helst
• Relationella databaser uppnår synkronisering med ändringsdatafångst medan filsystembaserade system använder filsynkronisering
• Dubbelriktad replikering med Push and Pull-metoden, som utförs baserat på fastställda regler
• Dataöverföring kan också ske över säkra nätverk med låg bandbredd
• Automatisk återställning under återupptagandet av en kraschad nod och automatisk konfliktlösning
• Molnet redo och innehåller kraftfulla API:er för tillägg

Demo

SymmetricDS kan konfigureras i ett av de två alternativen:

• En huvudnod (föräldernod) som fungerar som en centraliserad mellanhand som koordinerar datareplikering mellan två slavnoder (undernoder), där kommunikationen mellan de två underordnade noderna endast kan ske via föräldern.
• En aktiv nod (nod1) kan replikera till och från en annan aktiv nod (nod2) utan någon mellanhand.

I båda alternativen sker kommunikationen mellan noderna via "Push"- och "Pull"-händelser. I denna demo kommer en aktiv-aktiv konfiguration mellan två noder att förklaras. Den fullständiga arkitekturen kan vara uttömmande, så läsarna uppmuntras att kontrollera användarhandboken som finns här för att lära sig mer om SymmetricDS interna delar.

Att installera SymmetricDS är lika enkelt som att ladda ner open source-versionen av zip-filen härifrån och extrahera den på en lämplig plats. Detaljerna för installationsplatsen och versionen av SymmetricDS i denna demo är enligt tabellen nedan, tillsammans med andra detaljer som hänför sig till databasversioner, Linux-versioner, IP-adresser och kommunikationsport för båda de deltagande noderna.

Installationshemmet i det här fallet är "/usr/local/symmetric-server-3.9.20" som kommer att vara hemkatalogen för SymmetricDS, som innehåller olika andra underkataloger och filer. Två av de underkataloger som är viktiga nu är "prover" och "motorer". Samplekatalogen innehåller exempel på konfigurationsfil för nodegenskaper förutom exempel på SQL-skript för att kickstarta en snabb demo.

Följande tre konfigurationsfiler för nodegenskaper kan ses i katalogen "samples" med namn som indikerar nodens natur i en given inställning.

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

Eftersom SymmetricDS kommer med alla nödvändiga konfigurationsfiler för att stödja en grundläggande 3-nodsinställning (alternativ 1), är det bekvämt att använda samma konfigurationsfiler för att ställa in en 2-nodsinställning (alternativ 2). Den avsedda konfigurationsfilen kopieras från katalogen "samples" till "motorerna" på host vm1, och den ser ut som nedan.

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

Namnet på denna nod i SymmetricDS-konfigurationen är "corp-000" med databasanslutningen hanterad med mysql jdbc-drivrutinen med anslutningssträngen enligt ovan tillsammans med inloggningsuppgifter. Databasen som ska anslutas är "replica_db" och tabellerna kommer att skapas under skapandet av ett exempelschema. "sync.url" anger platsen för kontakt med noden för synkronisering.

Nod 2 på värd vm2 är konfigurerad som "store-001" med resten av detaljerna som konfigurerats i filen node.properties, som visas nedan. Noden "store-001" kör en PostgreSQL-databas, med "pgdb_replica" som databas för replikering. "registration.url" gör det möjligt för värd "vm2" att kommunicera med värd "vm1" för att 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

Den förkonfigurerade standarddemon av SymmetricDS innehåller inställningar för att ställa in en dubbelriktad replikering mellan två databasservrar (två noder). Stegen nedan exekveras på värd vm1 (corp-000), vilket kommer att skapa ett exempelschema med 4 tabeller. Vidare kommer exekvering av "create-sym-tables" med kommandot "symadmin" att skapa katalogtabellerna som lagrar och kontrollerar reglerna och replikeringsriktningen mellan noder. Slutligen laddas demotabellerna med exempeldata.

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

Demotabellerna "artikel" och "varuförsäljningspris" är automatiskt konfigurerade för att replikera från corp-000 till butik-001 medan försäljningstabellerna (försäljningstransaktion och försäljningsreturrad) är autokonfigurerade repliker från butik-001 till företag-000. Nästa steg är att skapa exempelschemat i PostgreSQL-databasen på värd 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

Det är viktigt att verifiera förekomsten av demotabeller och SymmetricDS-katalogtabeller i MySQL-databasen på vm1 i detta skede. Observera att SymmetricDS-systemtabellerna (tabeller med prefixet "sym_") endast är tillgängliga i corp-000-noden vid denna tidpunkt, eftersom det var där kommandot "create-sym-tables" kördes, vilket kommer att vara platsen för att kontrollera och hantera replikeringen. Utöver det kommer noddatabasen store-001 bara att ha fyra demotabeller utan data.

Miljön är nu redo att starta "sym"-serverprocesserna på båda noderna, som visas nedan.

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

Loggposterna skickas både till en bakgrundsloggfil (symmetric.log) under en loggkatalog på installationsplatsen för SymmetricDS såväl som till standardutgången. "Sym"-servern kan nu initieras på noden store-001.

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

Uppstarten av "sym"-serverprocessen på värd vm2 kommer också att skapa SymmetricDS-katalogtabellerna i PostgreSQL-databasen. Starten av "sym"-serverprocessen på båda noderna kommer att få dem att koordinera med varandra för att replikera data från corp-000 till store-001. Efter några sekunder, efterfrågar alla fyra tabellerna på vardera sidan, kommer de framgångsrika replikeringsresultaten att visas. Alternativt kan en initial laddning också skickas till noden store-001 från corp-000 med kommandot nedan.

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

Vid denna tidpunkt infogas en ny post i "objekt"-tabellen i MySQL-databasen vid corp-000-noden (värd:vm1) och den kan verifieras att den har replikerats framgångsrikt till PostgreSQL-databasen vid noden store-001 (värd:vm2 ). Detta visar "Pull"-händelsen för 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)

"Push"-händelsen för data från store-001 till corp-000 kan uppnås genom att infoga en post i tabellen "sale_transaction" och bekräfta att den replikeras.

pgdb_replica=# insert into "sale_transaction" ("tran_id", "store_id", "workstation", "day", "seq") values (1000, '001', '3', '2007-11-01', 100);
vm1$> [[email protected] ~]#  mysql -uroot -p'admin123' -D replica_db -e "select * from sale_transaction";
+---------+----------+-------------+------------+-----+
| tran_id | store_id | workstation | day        | seq |
+---------+----------+-------------+------------+-----+
|     900 | 001      | 3           | 2012-12-01 |  90 |
|    1000 | 001      | 3           | 2007-11-01 | 100 |
|    2000 | 002      | 2           | 2007-11-01 | 200 |
+---------+----------+-------------+------------+-----+

Detta markerar den framgångsrika konfigurationen av dubbelriktad replikering av demotabeller mellan en MySQL- och PostgreSQL-databas. Konfigurationen av replikering för nyskapade användartabeller kan göras med följande steg. En exempeltabell "t1" skapas för demon och reglerna för dess replikering konfigureras enligt proceduren nedan. Stegen konfigurerar bara replikeringen 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)

Efter detta meddelas konfigurationen om schemaändringen för att lägga till en ny tabell genom att anropa symadmin-kommandot med "sync-triggers"-argumentet som kommer att återskapa triggers för att matcha tabelldefinitioner. Kör sedan "send-schema" för att skicka schemaändringar ut till noden store-001, varefter replikeringen av "t1"-tabellen kommer att konfigureras framgångsrikt.

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

Fördelar med att använda SymmetricDS

• Bekväm installation och konfiguration inklusive en förkonfigurerad uppsättning parameterfiler för att bygga antingen en 3-nods- eller en 2-nodsinställning
• Överplattformsdatabas aktiverad och plattformsoberoende inklusive servrar, bärbara datorer och mobila enheter
• Replicera vilken databas som helst till vilken annan databas som helst, oavsett om den är lokal, WAN eller moln
• Kan hantera ett par databaser till flera tusen databaser optimalt för att replikera data sömlöst
• En kommersiell version av programvaran erbjuder GUI-driven hanteringskonsol med ett utmärkt supportpaket

Nackdelar med att använda SymmetricDS

• Manuell kommandoradskonfiguration kan innebära att definiera regler och riktning för replikering via SQL-satser för att ladda katalogtabeller, vilket kan vara obekvämt att hantera
• Att ställa in ett stort antal tabeller för replikering kommer att vara en uttömmande ansträngning, om inte någon form av skript används för att generera SQL-satserna som definierar regler och replikeringsriktning
• Mycket logginformation belamrar loggfilen, vilket kräver periodiskt underhåll av loggfilen för att inte tillåta loggfilen att fylla upp disken

SymmetricDS Sammanfattning

SymmetricDS erbjuder möjligheten att ställa in dubbelriktad replikering mellan 2 noder, 3 noder och så vidare för flera tusen noder för att replikera data och uppnå filsynkronisering. Det är ett unikt verktyg som utför många av de självläkande underhållsuppgifterna såsom automatisk återställning av data efter längre perioder av driftstopp i en nod, säker och effektiv kommunikation mellan noder med hjälp av HTTPS och automatisk konflikthantering baserat på fastställda regler , etc. The essential feature of replicating any database to any other database makes SymmetricDS ready to be deployed for a number of use cases including migration, version and patch upgrade, distribution, filtering and transformation of data across diverse platforms.

The demo was created by referring to the official quick-start tutorial of SymmetricDS which can be accessed from here. The user guide can be found here, which provides a detailed account of various concepts involved in a SymmetricDS replication setup.