Keresztreplikáció a PostgreSQL és a MySQL között

Felvázolom a PostgreSQL és a MySQL közötti keresztreplikációt, valamint a két adatbázis-kiszolgáló közötti keresztreplikáció beállításának módszereit. A keresztreplikált adatbázisokat általában homogénnek nevezik, és ez kényelmes módszer az egyik RDBMS-kiszolgálóról a másikra való áthelyezésre.

A PostgreSQL és a MySQL adatbázisokat általában relációsnak tekintik, de további kiterjesztésekkel NoSQL-képességeket kínálnak. Itt a PostgreSQL és a MySQL közötti replikációt relációs DBMS-szempontból tárgyaljuk.

Nem írjuk le a teljes belső működést, csak az alapelveket, hogy képet kapjon az adatbázis-kiszolgálók közötti replikáció konfigurálásáról, előnyeiről, korlátairól és használati eseteiről.

A replikáció két azonos adatbázis-kiszolgáló között általában bináris módban vagy egy mester (más néven kiadó, mester vagy aktív) és egy szolga (előfizető, készenléti vagy passzív) közötti lekérdezések használatával történik. A replikáció célja a fő adatbázis valós idejű másolatának biztosítása a slave oldalon. Ebben az esetben az adatok a masterről a slave-re, vagyis az aktívról a passzívra kerülnek átvitelre, mivel a replikáció csak egy irányban történik. De beállíthat replikációt két adatbázis között mindkét irányban, így az adatok aktív-aktív konfigurációban kerülnek átvitelre a slave-től a masterig. Mindez, beleértve a lépcsőzetes replikációt is, két vagy több azonos adatbázis-kiszolgáló között lehetséges. Az aktív-aktív vagy az aktív-passzív konfiguráció az igénytől, az ilyen képességek elérhetőségétől a kezdeti konfigurációban vagy külső konfigurációs megoldások használatától és a meglévő kompromisszumoktól függ.

A leírt konfiguráció különböző adatbázis-kiszolgálók között lehetséges. A kiszolgáló konfigurálható úgy, hogy más adatbázis-kiszolgálóról replikált adatokat fogadjon el, és továbbra is fenntartsa a replikált adatok valós idejű pillanatfelvételeit. A MySQL és a PostgreSQL a legtöbb ilyen konfigurációt házon belül vagy harmadik féltől származó bővítményeken keresztül kínálja, beleértve a bináris naplózási módszereket, a lemezzárolást, valamint az utasítás- és soralapú módszereket.

A MySQL és a PostgreSQL közötti keresztreplikáció szükséges az egyik adatbázis-kiszolgálóról a másikra való egyszeri migrációhoz. Ezek az adatbázisok különböző protokollokat használnak, így nem lehetséges közvetlenül összekapcsolni őket. Az adatcsere létrehozásához használhat egy külső nyílt forráskódú eszközt, például a pg_chameleont.

Mi az a pg_chameleon

A pg_chameleon egy replikációs rendszer a MySQL-ről a PostgreSQL-re Python 3-ban. A nyílt forráskódú mysql-replikációs könyvtárat használja, szintén Pythonban. A sorképeket a rendszer kivonja a MySQL táblákból, és JSONB objektumként tárolja a PostgreSQL adatbázisban, majd a pl/pgsql függvény visszafejti, és reprodukálja a PostgreSQL adatbázisban.

A pg_chameleon jellemzői

Ugyanabból a fürtből több MySQL-séma replikálható egyetlen cél PostgreSQL-adatbázisba egy-a többhez konfigurációban
A forrás- és a célséma neve nem lehet azonos.
A replikációs adatok lekérhetők egy lépcsőzetes MySQL-replikából.
Azok a táblák, amelyek nem replikálhatók vagy nem tudnak hibát okozni, kizárásra kerülnek.
Minden replikációs funkciót démonok vezérelnek.
Vezérlés YAML alapú paramétereken és konfigurációs fájlokon keresztül.

Példa

Házigazda
vm1
vm2

OS verzió
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

DB szerver verzió
MySQL 5.7.26
PostgreSQL 10.5

DB port
3306
5433

IP-cím
192.168.56.102
192.168.56.106

Kezdésként készítse elő az összes szükséges összetevőt a pg_chameleon telepítéséhez. Ez a példa a Python 3.6.8-at telepíti, amely létrehozza és aktiválja a virtuális környezetet.

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

A Python3.6 sikeres telepítése után teljesítenie kell a fennmaradó követelményeket, például létre kell hoznia és aktiválnia kell egy virtuális környezetet. Ezenkívül a pip modul a legújabb verzióra frissül, és a pg_chameleon telepítésére szolgál. Az alábbi parancsok szándékosan telepítik a pg_chameleon 2.0.9-et, bár a legújabb verzió a 2.0.10. Erre azért van szükség, hogy elkerüljük az új hibákat a frissített verzióban.

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

Ezután meghívjuk a pg_chameleon-t (a chameleon egy parancs) a set_configuration_files argumentummal, hogy engedélyezzük a pg_chameleon-t, és létrehozzuk az alapértelmezett könyvtárakat és konfigurációs fájlokat.

(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

Most létrehozzuk a config-example.yml másolatát default.yml néven, így az lesz az alapértelmezett konfigurációs fájl. Az alábbiakban egy minta konfigurációs fájl található ehhez a példához.

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

Ebben a példában a konfigurációs fájl egy minta pg_chameleon fájl, kisebb módosításokkal, hogy megfeleljen a forrás- és célkörnyezetnek, az alábbiakban pedig áttekintést adunk a konfigurációs fájl különböző szakaszairól.

A default.yml konfigurációs fájlban található a globális beállítások része, ahol olyan beállításokat kezelhet, mint a zárolási fájl helye, a naplók helye, a naplók tárolási ideje stb. Ezután következik a típusfelülírás szakasz, ahol szabálykészlet a típusok felülbírálásához a replikáció során. A példa alapértelmezés szerint egy típusfelülbíráló szabályt használ, amely a tinyint(1)-et logikai értékké alakítja. A következő részben megadjuk a kapcsolat részleteit a céladatbázishoz. Esetünkben ez egy PostgreSQL adatbázis, pg_conn néven. Az utolsó részben feltüntetjük a forrásadatokat, vagyis a forrásadatbázis kapcsolódási paramétereit, a forrás- és céladatbázis közötti leképezési sémát, a kihagyandó táblákat, a várakozási időt, a memóriát, a csomagméretet. Ne feledje, hogy a „források” többes szám, ami azt jelenti, hogy több forrásadatbázist is hozzáadhatunk egyetlen céladatbázishoz, hogy több-az-egy konfigurációt állítsunk be.

A world_x példaadatbázis 4 táblát tartalmaz sorokkal, amelyeket a MySQL közösség példaként kínál fel. Letölthető itt. A mintaadatbázis tar és tömörített archívumként érkezik, a sorok létrehozására és importálására vonatkozó utasításokkal.

A MySQL és PostgreSQL adatbázisokban egy speciális felhasználó jön létre ugyanazzal a névvel: usr_replica. A MySQL-ben további olvasási jogokat kap az összes replikált táblához.

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;

A PostgreSQL oldalon egy db_replica adatbázis jön létre, amely elfogadja a MySQL adatbázis módosításait. Az usr_replica felhasználó a PostgreSQL-ben automatikusan be van állítva két séma tulajdonosaként, a pgworld_x és az sch_chameleon, amelyek a tényleges replikált táblákat, illetve a replikációs címtártáblákat tartalmazzák. A create_replica_schema argumentum felelős az automatikus konfigurációért, amint azt alább látni fogja.

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

A MySQL adatbázis néhány paramétermódosítással van konfigurálva, hogy előkészítse a replikációra, az alábbiak szerint. A változtatások életbe lépéséhez újra kell indítania az adatbázis-kiszolgálót.

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

Most fontos ellenőrizni a kapcsolatot mindkét adatbázis-kiszolgálóval, hogy ne legyen probléma a pg_chameleon parancsok futtatásakor.

A PostgreSQL csomóponton:

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

A MySQL csomóponton:

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

A következő három pg_chameleon (chameleon) parancs előkészíti a környezetet, hozzáadja a forrást, és inicializálja a replikát. A pg_chameleonhoz tartozó create_replica_schema argumentum létrehoz egy alapértelmezett sémát (sch_chameleon) és egy replikációs sémát (pgworld_x) a PostgreSQL adatbázisban, amint azt már tárgyaltuk. Az add_source argumentum a konfigurációs fájl (default.yml) beolvasásával ad hozzá egy forrásadatbázist a konfigurációhoz, esetünkben ez a mysql, az init_replica pedig a konfigurációs fájl paraméterei alapján inicializálja a konfigurációt.

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

Ennek a három parancsnak a kimenete egyértelműen jelzi, hogy sikeresen végrehajtották őket. Az összeomlásokat vagy szintaktikai hibákat egyszerű, világos üzenetekben jelentik a probléma megoldására vonatkozó tippekkel.

Végül elindítjuk a replikációt a start_replica használatával, és sikeres üzenetet kapunk.

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

A replikáció állapota a show_status argumentummal kérdezhető le, a hibák pedig a show_errors argumentummal tekinthetők meg.

Az eredmény.

Mint már említettük, minden replikációs függvényt démonok vezérelnek. Megtekintésükhöz lekérdezzük a folyamattáblázatot a Linux ps paranccsal, az alábbiak szerint.

Az eredmény.

A replikáció nem tekinthető konfiguráltnak mindaddig, amíg valós időben nem teszteljük, az alábbiak szerint. Létrehozunk egy táblát, beszúrunk néhány rekordot a MySQL adatbázisba, és meghívjuk a sync_tables argumentumot a pg_chameleon fájlban, hogy frissítsük a démonokat, és replikáljuk a táblát a rekordokkal a PostgreSQL adatbázisba.

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.

A teszteredmények megerősítéséhez lekérdezzük a táblát a PostgreSQL adatbázisból, és kiadjuk a sorokat.

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

Ha migrációt végzünk, akkor a következő pg_chameleon parancsok jelentik a végét. A parancsokat akkor kell végrehajtani, ha megbizonyosodtunk arról, hogy az összes céltábla sorát replikáltuk, és az eredmény egy szépen áttelepített PostgreSQL-adatbázis lesz, a forrásadatbázisra vagy a replikációs sémára (sch_chameleon) való hivatkozás nélkül.

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

Ha szükséges, a következő parancsokkal törölheti az eredeti konfigurációt és replikációs sémát.

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

A pg_chameleon előnyei

Könnyű beállítás és konfiguráció.
Egyszerű hibaelhárítás és az anomáliák azonosítása egyértelmű hibaüzenetekkel.
Az inicializálás után további speciális táblák adhatók hozzá a replikációhoz a konfiguráció többi részének megváltoztatása nélkül.
Lehetőség van több forrásadatbázis konfigurálására egyetlen céladatbázishoz, és ez nagyon hasznos, ha egy vagy több MySQL-adatbázisból származó adatokat egyetlen PostgreSQL-adatbázisba egyesít.
Nem kell replikálnia a kiválasztott táblákat.

A pg_chameleon hátrányai

Csak a MySQL 5.5 és újabb verziója támogatja forrásként, valamint a PostgreSQL 9.5 és újabb, mint céladatbázis.
Minden táblának rendelkeznie kell egy elsődleges vagy egyedi kulccsal, ellenkező esetben a táblák inicializálódnak az init_replica folyamat során, de nem replikálódnak.
Egyirányú replikáció – csak MySQL-ről PostgreSQL-re. Ezért csak az „aktív-passzív” áramkörhöz alkalmas.
A forrás csak MySQL adatbázis lehet, és a PostgreSQL adatbázis forrásként való támogatása csak kísérleti jellegű és korlátozott (további információ itt)

Találatok a pg_chameleon kifejezésre

A pg_chameleon replikációs módszere kiválóan alkalmas az adatbázisok MySQL-ről PostgreSQL-re való migrálására. A jelentős hátránya, hogy a replikáció csak egyirányú, így az adatbázis-szakemberek valószínűleg nem akarják másra használni, mint az áttelepítésre. Az egyirányú replikáció problémája azonban megoldható egy másik nyílt forráskódú eszközzel - a SymmetricDS-sel.

Bővebben a hivatalos dokumentációban itt. Parancssori súgó található itt.

A SymmetricDS áttekintése

A SymmetricDS egy nyílt forráskódú eszköz, amely bármilyen adatbázist replikál bármely más általános adatbázisba: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird és más felhőalapú adatbázis-példányok, például Redshift és Azure stb. Elérhető szolgáltatások: adatbázis- és fájlszinkronizálás, több főadatbázis-replikáció, szűrt szinkronizálás, átalakítás és egyebek. Ez egy Java eszköz, és a JRE vagy a JDK szabványos kiadására van szükség (8.0 vagy újabb verzió). Itt rögzíthetők a forrásadatbázisban lévő triggerek adatváltozásai, és kötegek formájában elküldhetők a megfelelő céladatbázisba.

SymmetricDS funkciók

Az eszköz platformfüggetlen, vagyis két vagy több különböző adatbázis tud adatot cserélni.
A relációs adatbázisok szinkronizálása adatmódosítási rekordok segítségével történik, míg a fájlrendszer alapú adatbázisok fájlszinkronizálást használnak.
Kétirányú replikáció Push és Pull metódusokkal, szabályok alapján.
Az adatátvitel biztonságos és alacsony sávszélességű hálózatokon keresztül lehetséges.
Automatikus helyreállítás, amikor a csomópontok újra működnek egy hiba után, és automatikus konfliktusfeloldás.
Felhővel kompatibilis és hatékony kiterjesztés API-k.

Példa

A SymmetricDS két lehetőség egyikével konfigurálható:
Egy mester (szülő) csomópont, amely központilag koordinálja az adatreplikációt két szolga (gyermek) csomópont között, és a gyermek csomópontok közötti kommunikáció csak a szülőn keresztül történik.
Egy aktív csomópont (1. csomópont) közvetítő nélkül kommunikálhat replikáció céljából egy másik aktív csomóponttal (2. csomópont).

Mindkét lehetőségnél az adatcsere Push and Pull használatával történik. Ebben a példában egy aktív-aktív konfigurációt fogunk megvizsgálni. Túl sokáig tartana a teljes architektúra leírása, ezért végezzen kutatást. vezetéshogy többet tudjon meg a SymmetricDS eszközről.

A SymmetricDS telepítése nagyon egyszerű: töltse le a zip fájl nyílt forráskódú verzióját ezért és vedd ki ahova akarod. Az alábbi táblázat információkat tartalmaz a SymmetricDS telepítési helyéről és verziójáról ebben a példában, valamint mindkét csomópont adatbázis-verzióiról, Linux-verzióiról, IP-címeiről és portjairól.

Házigazda
vm1
vm2

OS verzió
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

DB szerver verzió
MySQL 5.7.26
PostgreSQL 10.5

DB port
3306
5832

IP-cím
192.168.1.107
192.168.1.112

SymmetricDS verzió
SymmetricDS 3.9
SymmetricDS 3.9

SymmetricDS telepítési útvonal
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

SymmetricDS csomópont neve
corp-000
üzlet-001

Itt telepítjük a SymmetricDS-t a /usr/local/symmetric-server-3.9.20 könyvtárba, és ott különböző alkönyvtárak és fájlok lesznek tárolva. Érdekelnek minket a minták és a motorok alkönyvtárai. A minták könyvtára példa konfigurációs fájlokat tartalmaz csomóponttulajdonságokkal, valamint példa SQL-parancsfájlokat a gyors kezdéshez.

A minták könyvtárában három konfigurációs fájlt látunk csomóponttulajdonságokkal - a név a csomópont jellegét mutatja egy bizonyos sémában.

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

A SymmetricDS rendelkezik az összes szükséges konfigurációs fájllal egy alapvető 3 csomópontos kialakításhoz (1. lehetőség), és ugyanezek a fájlok használhatók egy 2 csomópontos kialakításhoz (2. lehetőség). Másolja a szükséges konfigurációs fájlt a minták könyvtárából a vm1 gazdagép motorjaiba. Így alakul:

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

A SymmetricDS konfigurációban ezt a csomópontot corp-000-nak hívják, és az adatbázis-kapcsolatot a mysql jdbc illesztőprogram kezeli, amely a fenti kapcsolati karakterláncot és a bejelentkezési hitelesítő adatokat használja. Csatlakozunk a replica_db adatbázishoz, és a séma létrehozása során táblák jönnek létre. A sync.url megmutatja, hol lehet kapcsolatba lépni a csomóponttal a szinkronizáláshoz.

A vm2 gazdagépen a 2. csomópont store-001-ként van konfigurálva, a többi pedig az alábbi node.properties fájlban van megadva. A Node store-001 a PostgreSQL adatbázist futtatja, a pgdb_replica pedig a replikációs adatbázis. A register.url lehetővé teszi, hogy a vm2 gazdagép kapcsolatba lépjen a vm1 gazdagéppel, és megkapja tőle a konfigurációs részleteket.

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

Az elkészült SymmetricDS-példa paramétereket tartalmaz a két adatbázis-kiszolgáló (két csomópont) közötti kétirányú replikáció beállításához. Az alábbi lépéseket a vm1 (corp-000) gazdagépen hajtják végre, amely egy példa sémát hoz létre 4 táblával. Ezután a create-sym-tables futtatása a symadmin paranccsal címtártáblázatokat hoz létre, amelyekben a csomópontok közötti replikáció szabályai és iránya tárolódnak. Végül a mintaadatok betöltődnek a táblázatokba.

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

A példában a cikk és az item_selling_price táblák automatikusan úgy vannak konfigurálva, hogy replikáljanak a 000-es vállalatról a 001-es üzletre, az értékesítési táblák pedig (sale_transaction és sale_return_line_item) automatikusan replikálódnak a 001-es áruházból a 000-es üzletbe. Most létrehozunk egy sémát a PostgreSQL adatbázisban a vm2 (store-001) gazdagépen, hogy előkészítsük a 000-es vállalattól származó adatok fogadására.

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

Ügyeljen arra, hogy ellenőrizze, hogy a vm1-en található MySQL-adatbázis tartalmaz-e példatáblázatokat és SymmetricDS-katalógustáblákat. Ne feledje, hogy a SymmetricDS rendszertáblák (előtagként sym_) jelenleg csak a corp-000 csomóponton érhetők el, mert ott futtattuk a create-sym-tables parancsot, és ott fogjuk kezelni a replikációt. És a node store-001 adatbázisban csak 4 példatábla lesz adat nélkül.

Minden. A környezet készen áll a sym szerver folyamatok futtatására mindkét csomóponton, az alábbiak szerint.

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

A naplóbejegyzések egy háttér naplófájlba (symmetric.log) kerülnek elküldésre annak a könyvtárnak a naplómappájában, ahol a SymmetricDS telepítve van, valamint a szabványos kimenetre. A sym-kiszolgáló most már elindítható a 001-es csomóponti tárolón.

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

Ha a sym-kiszolgáló folyamatát a vm2 gazdagépen futtatja, az SymmetricDS katalógustáblákat is létrehoz a PostgreSQL adatbázisban. Ha mindkét csomóponton futtatja a sym-kiszolgáló folyamatát, akkor azok egymással koordinálva replikálják az adatokat a corp-000-ból a store-001-be. Ha néhány másodperc múlva lekérdezzük mind a 4 táblát mindkét oldalon, látni fogjuk, hogy a replikáció sikeres volt. Vagy elküldheti a bootstrap-et a node store-001-be a corp-000-ból a következő paranccsal.

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

Ezen a ponton egy új rekord kerül beszúrásra a MySQL-adatbázis elemtáblájába a corp-000 csomóponton (host: vm1), és ellenőrizheti a replikációját a PostgreSQL adatbázisba a node store-001-en (gazdagép: vm2). Látunk egy Pull műveletet az adatok áthelyezésére a corp-000-ból a store-001-be.

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)

A 001-es áruházból a corp-000-be történő adatátvitelhez Push művelet végrehajtásához beszúrunk egy rekordot a sale_transaction táblába, és ellenőrizzük, hogy a replikáció sikeres-e.

Az eredmény.

Látjuk a példatáblázatok kétirányú replikációjának sikeres beállítását a MySQL és a PostgreSQL adatbázisok között. Az új felhasználói táblák replikációjának beállításához kövesse az alábbi lépéseket: Létrehozzuk például a t1 táblát, és a replikációs szabályait az alábbiak szerint konfiguráljuk. Így csak a replikációt állítjuk be a corp-000-ról a store-001-re.

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)

A konfiguráció ezután értesítést kap a sémamódosításról, azaz egy új tábla hozzáadásáról, a symadmin paranccsal a sync-triggers argumentummal, amely újra létrehozza a triggereket a tábladefiníciók leképezéséhez. A send-schema végrehajtásra kerül a sémamódosítások elküldése a 001 csomóponti tárolóba, és a t1 tábla replikációja be van állítva.

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

A SymmetricDS előnyei

Könnyű telepítés és konfigurálás, beleértve a kész fájlkészletet paraméterekkel a három vagy két csomópontos áramkör létrehozásához.
Platformok közötti adatbázisok és platformfüggetlenség, beleértve a szervereket, laptopokat és mobileszközöket.
Bármely adatbázist replikálhat bármely más adatbázisba helyileg, a WAN-on vagy a felhőben.
Optimális munkavégzés lehetősége pár vagy több ezer adatbázissal a kényelmes replikáció érdekében.
Fizetett verzió GUI-val és kiváló támogatással.

A SymmetricDS hátrányai

A katalógustáblázatok betöltéséhez manuálisan kell megadnia a replikáció szabályait és irányát a parancssorban SQL-utasításokon keresztül, ami kényelmetlen lehet.
Sok tábla beállítása a replikációhoz fárasztó lehet, hacsak nem használ parancsfájlokat a replikáció szabályait és irányát meghatározó SQL utasítások létrehozásához.
Túl sok információ van rögzítve a naplókban, és néha rendbe kell tenni a naplófájlt, hogy ne foglaljon túl sok helyet.

Találatok a SymmetricDS kifejezésre

A SymmetricDS lehetővé teszi kétirányú replikáció beállítását két, három vagy akár több ezer csomópont között a fájlok replikálásához és szinkronizálásához. Ez egy egyedülálló eszköz, amely számos feladatot önállóan hajt végre, például automatikus adat-helyreállítást egy csomópont hosszú leállása után, biztonságos és hatékony adatcserét a csomópontok között HTTPS-en keresztül, automatikus konfliktuskezelést szabályrendszeren alapulóan stb. A SymmetricDS replikáció bármilyen adatbázis között, ezért sokféle forgatókönyvhöz használható, beleértve az adatok áttelepítését, áttelepítését, elosztását, szűrését és platformokon keresztüli átalakítását.

A példa a hivataloson alapul Gyors útmutató a SymmetricDS által. BAN BEN használati utasítás Részletesen leírja a SymmetricDS replikáció beállításával kapcsolatos különféle fogalmakat.

Forrás: will.com