Křížová replikace mezi PostgreSQL a MySQL

Obecně se podívám na křížovou replikaci mezi PostgreSQL a MySQL a také na metody nastavení křížové replikace mezi těmito dvěma databázovými servery. Obvykle se databáze v křížové replikaci považují za homogenní a je to pohodlný způsob přechodu z jednoho serveru relační DB na jiný.

Databáze PostgreSQL a MySQL jsou obecně považovány za relační, ale s dalšími rozšířeními nabízejí možnosti NoSQL. Zde budeme diskutovat o replikaci mezi PostgreSQL a MySQL z pohledu relačních DB.

Nebudeme popisovat celou vnitřní strukturu, pouze základní principy, abyste získali představu o nastavení replikace mezi databázovými servery, výhodách, omezeních a scénářích použití.

Obvykle se replikace mezi dvěma identickými databázovými servery provádí buď v binárním režimu, nebo pomocí dotazů mezi hlavním uzlem (také známým jako vydavatel, hlavní nebo aktivní) a podřízeným (odběratelem, čekajícím nebo pasivním). Cílem replikace je poskytnout v reálném čase kopii hlavní databáze na straně podřízeného. Přitom jsou data přenášena od hlavního k podřízenému, tedy od aktivního k pasivnímu, protože replikace probíhá pouze jedním směrem. Ale je možné nastavit replikaci mezi dvěma databázemi obousměrně, aby data byla přenášena od podřízeného k hlavnímu v konfiguraci "aktivní-aktivní". To vše, včetně kaskádové replikace, je možné mezi dvěma a více identickými databázovými servery. Konfigurace "aktivní-aktivní" nebo "aktivní-pasivní" závisí na potřebě, dostupnosti takových možností v původní konfiguraci nebo použití externích řešení pro nastavení a existujících kompromisů.

Popisovaná konfigurace je možná mezi různými databázovými servery. Server může být nastaven tak, aby přijímal replikovaná data z jiného databázového serveru, a zároveň uchovával snímky replikovaných dat v reálném čase. MySQL a PostgreSQL nabízejí většinu těchto konfigurací buď nativně, nebo pomocí externích rozšíření, včetně metod binárního protokolu, zámků disku a metod založených na operátorech a řádcích.

Křížová replikace mezi MySQL a PostgreSQL je potřebná pro jednorázovou migraci z jednoho databázového serveru na druhý. Tyto databáze používají různé protokoly, a proto je nelze propojit přímo. Pro usnadnění výměny dat lze použít externí open-source nástroj, například pg_chameleon.

Co je pg_chameleon

pg_chameleon je systém replikace z MySQL do PostgreSQL napsaný v Pythonu 3. Využívá open-source knihovnu mysql-replication také na Pythonu. Obrazce řádků jsou extrahovány z tabulek MySQL a ukládány jako objekty JSONB v databázi PostgreSQL, a poté jsou dekódovány funkcí pl/pgsql a reprodukovány v databázi PostgreSQL.

Možnosti pg_chameleon

Několik schémat MySQL z jednoho clusteru může být replikováno do jedné cílové databáze PostgreSQL s konfigurací „jeden k mnoha“.
Názvy zdrojového a cílového schématu se nesmí shodovat.
Data replikace mohou být extrahována z kaskádové repliky MySQL.
Tabulky, které nelze replikovat nebo vytvářejí chyby, jsou vyloučeny.
Každou funkci replikace řídí démoni.
Kontrola pomocí parametrů a konfiguračních souborů ve formátu YAML.

Příklad

Hostitel
vm1
vm2

Verze OS
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Verze databázového serveru
MySQL 5.7.26
PostgreSQL 10.5

Port DB
3306
5433

IP adresa
192.168.56.102
192.168.56.106

Nejprve připravte všechny potřebné komponenty pro instalaci pg_chameleon. V tomto příkladu je nainstalován Python 3.6.8, který vytvoří virtuální prostředí a aktivuje ho.

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

Po úspěšné instalaci Pythonu 3.6 je třeba splnit další požadavky, například vytvořit a aktivovat virtuální prostředí. Kromě toho se modul pip aktualizuje na nejnovější verzi a používá se k instalaci pg_chameleon. V následujících příkazech je úmyslně nainstalována verze pg_chameleon 2.0.9, i když poslední verze je 2.0.10. To je potřeba, aby se předešlo novým chybám v aktualizované verzi.

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

Poté voláme pg_chameleon (chameleon je příkaz) s argumentem set_configuration_files, aby se aktivoval pg_chameleon a vytvořily se výchozí adresáře a konfigurační soubory.

(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/
coping configuration example in /root/.pg_chameleon/configuration//config-example.yml

Nyní vytváříme kopii config-example.yml jako default.yml, aby se stal výchozím konfiguračním souborem. Ukázka konfiguračního souboru pro tento příklad je uvedena níže.

$> cat default.yml
---
#globální nastavení
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 umožňuje uživateli přepsat výchozí převod typů na jiný.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

#postgres  cílové připojení
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 #přeskakuje vkládání do tabulky delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #přeskakuje mazání ve schématu delphis_mediterranea
      update:

Konfigurační soubor v tomto příkladu je vzorek souboru s pg_chameleon s drobnými změnami v souladu se zdrojovým a cílovým prostředím, a níže je shrnutí různých sekcí konfiguračního souboru.

V konfiguračním souboru default.yml je sekce globálních parametrů (global settings), kde lze řídit nastavení, jako je umístění souboru zámku, umístění logů, doba uchování logů atd. Dále následuje sekce přepisování typů (type override), kde je uvedena sada pravidel pro přepisování typů během replikace. V příkladu se používá pravidlo přepisování typu, které převádí tinyint(1) na logickou hodnotu. V další sekci uvádíme detaily připojení k cílové databázi. V našem případě je to databáze PostgreSQL, označená jako pg_conn. V poslední sekci uvádíme údaje o zdroji, tj. parametry připojení zdrojové databáze, schéma mapování zdrojové a cílové databáze, tabulky, které je třeba přeskočit, časové limity, paměť, velikost várky. Všimněte si, že „sources“ je uvedeno v množném čísle, tj. můžeme přidat několik zdrojových databází pro jednu cílovou, abychom nastavili konfiguraci „mnohého k jednomu“.

Databáze world_x v ukázce obsahuje 4 tabulky se řádky, které komunitě MySQL slouží jako příklad. Lze ji načíst zde. Ukázková databáze je dodávána ve formátu tar a jako komprimovaný archiv s pokyny k vytvoření a importu řádků.

Ve databázích MySQL a PostgreSQL se vytváří speciální uživatel se stejným názvem usr_replica. V MySQL mu jsou udělena další práva pro čtení všech replikovaných tabulek.

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;

Na straně PostgreSQL se vytváří databáze db_replica, která bude přijímat změny z databáze MySQL. Uživatel usr_replica v PostgreSQL je automaticky nastaven jako vlastník dvou schémat pgworld_x a sch_chameleon, které obsahují skutečné replikované tabulky a tabulky pro katalogizaci replikace. O automatickou konfiguraci se postará argument create_replica_schema, jak uvidíte níže.

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

Databáze MySQL se nastavuje se změnami některých parametrů, aby byla připravena na replikaci, jak je ukázáno níže. Bude třeba restartovat databázový server, aby změny nabyly účinnosti.

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

Je nyní důležité zkontrolovat připojení k oběma databázovým serverům, aby při provádění příkazů pg_chameleon nevznikly problémy.

Na uzlu PostgreSQL:

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

Na uzlu MySQL :

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

Následující tři příkazy pg_chameleon (chameleon) připravují prostředí, přidávají zdroj a inicializují replikaci. Argument create_replica_schema v pg_chameleon vytváří výchozí schéma (sch_chameleon) a schéma replikace (pgworld_x) v databázi PostgreSQL, jak jsme již zmínili. Argument add_source přidává zdrojovou databázi do konfigurace, čtením konfiguračního souboru (default.yml), a v našem případě je to mysql, a init_replica inicializuje konfiguraci na základě parametrů v konfiguračním souboru.

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

Výstupy těchto tří příkazů zjevně ukazují na jejich úspěšné provedení. Všechny chyby nebo syntaktické problémy jsou uvedeny v jednoduchých a srozumitelných zprávách s tipy na opravu problémů.

Nakonec spustíme replikaci pomocí start_replica a obdržíme zprávu o úspěšném provedení.

$> chameleon start_replica --config default --source mysql 
výstup: Spouští se proces replikace pro zdroj mysql

Stav replikace lze dotazovat pomocí argumentu show_status, a chyby zkontrolovat pomocí argumentu show_errors.

Result.

Jak již bylo zmíněno, každou funkcí replikace řídí démoni. Abychom je mohli zobrazit, dotázáme se na tabulku procesů pomocí příkazu Linux ps, jak je uvedeno níže.

Result.

Replikace se nepovažuje za nastavenou, dokud ji neprověříme v reálném čase, jak je ukázáno níže. Vytvoříme tabulku, vložíme pár záznamů do databáze MySQL a zavoláme argument sync_tables v pg_chameleon, abychom aktualizovali démony a replikovali tabulku se záznamy do databáze PostgreSQL.

mysql> create table t1 (n1 int primary key, n2 varchar(10));
Dotaz OK, 0 řádků ovlivněno (0.01 sek)
mysql> insert into t1 values (1,'one');
Dotaz OK, 1 řádek ovlivněn (0.00 sek)
mysql> insert into t1 values (2,'two');
Dotaz OK, 1 řádek ovlivněn (0.00 sek)

$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Proces synchronizace tabulky pro zdroj mysql byl spuštěn.

Abychom potvrdili výsledky testu, dotazujeme se na tabulku v databázi PostgreSQL a zobrazujeme řádky.

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

Pokud provádíme migraci, následující příkazy pg_chameleon budou jejím ukončením. Příkazy je třeba provést poté, co se ujistíme, že řádky všech cílových tabulek byly replikovány, a výsledkem bude pečlivě přenesená databáze PostgreSQL bez odkazů na původní databázi nebo schéma replikace (sch_chameleon).

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

Na žádost lze následujícími příkazy odstranit původní konfiguraci a schéma replikace.

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

Výhody pg_chameleon

Jednoduché nastavení a konfigurace.
Snadné odstraňování problémů a odhalování anomálií s jasnými chybovými zprávami.
Do replikace lze po inicializaci přidat další speciální tabulky, aniž by se měnila zbytek konfigurace.
Lze nastavit několik zdrojových databází pro jednu cílovou, což je velmi užitečné, pokud slučujete data z jedné nebo více databází MySQL do jedné databáze PostgreSQL.
Vybrané tabulky není nutné replikovat.

Nevýhody pg_chameleon

Podporována je pouze MySQL 5.5 a novější jako zdroj a PostgreSQL 9.5 a novější jako cílová databáze.
Každá tabulka musí mít primární nebo unikátní klíč, jinak budou tabulky inicializovány v procesu init_replica, ale nebudou replikovány.
Jednosměrná replikace — pouze z MySQL do PostgreSQL. Proto je vhodná pouze pro schéma „aktivní-pasivní“.
Zdrojem může být pouze databáze MySQL, a podpora databáze PostgreSQL jako zdroje je pouze experimentální a s omezeními (více informací zde zde)

Závěry o pg_chameleon

Metoda replikace v pg_chameleon je skvělá pro migraci databáze z MySQL do PostgreSQL. Podstatnou nevýhodou je to, že replikace je pouze jednosměrná, proto se odborníci na databáze pravděpodobně nebudou chtít používat k něčemu jinému než migraci. Ale problém jednosměrné replikace lze vyřešit dalším open-source nástrojem — SymmetricDS.

Podrobnosti najdete v oficiální dokumentaci zde. Nápovědu k příkazovému řádku najdete zde.

Přehled SymmetricDS

SymmetricDS je open-source nástroj, který replikujte jakoukoli databázi do jakékoli jiné běžné databáze: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird a další cloudové instance DB, jako je Redshift a Azure atd. K dispozici: synchronizace databází a souborů, replikace několika hlavních databází, filtrovaná synchronizace, transformace a další. Je to nástroj v Javě, vyžadující standardní vydání JRE nebo JDK (verze 8.0 a vyšší). Zde lze zapisovat změny dat pomocí spouštěčů v zdrojové databázi a směrovat je do odpovídající cílové databáze ve formě balíčků.

Funkce SymmetricDS

Nástroj je nezávislý na platformě, což znamená, že dvě nebo více různých databází mohou měnit data.
Relational databases are synchronized using data change recording, whereas file system-based databases use file synchronization.
Oboustranná replikace pomocí metod Push a Pull na základě pravidel.
Přenášení dat je možné prostřednictvím zabezpečených sítí a sítí s nízkou šířkou pásma.
Automatické obnovení při znovuobnovení provozu uzlů po selhání a automatické řešení konfliktů.
Kompatibilita s cloudem a efektivní rozhraní API pro rozšíření.

Příklad

SymmetricDS lze nastavit jedním ze dvou způsobů:
Hlavní (rodičovský) uzel, který centralizovaně koordinuje replikaci dat mezi dvěma podřízenými uzly, a výměna dat mezi podřízenými uzly probíhá pouze prostřednictvím rodičovského uzlu.
Aktivní uzel (uzel 1) může vyměňovat data pro replikaci s jiným aktivním uzlem (uzel 2) bez prostředníka.

V obou variantách dochází k výměně dat pomocí Push a Pull. V tomto příkladu si ukážeme konfiguraci "aktivní-aktivní". Popsat celou architekturu by trvalo příliš dlouho, tak se podívejte průvodce, abyste se dozvěděli více o zařízení SymmetricDS.

Instalace SymmetricDS je velmi jednoduchá: stáhněte open-source verzi zip souboru odsud a rozbalte ji kamkoliv chcete. V následující tabulce se nachází informace o místě instalace a verzi SymmetricDS v tomto příkladu, stejně jako verze databází, verze Linuxu, IP adresy a porty pro oba uzly.

Hostitel
vm1
vm2

Verze OS
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Verze databázového serveru
MySQL 5.7.26
PostgreSQL 10.5

Port DB
3306
5832

IP adresa
192.168.1.107
192.168.1.112

Verze SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9

Cesta instalace SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

Název uzlu SymmetricDS
corp-000
store-001

Zde instalujeme SymmetricDS do /usr/local/symmetric-server-3.9.20, kde budou uloženy různé podřazené adresáře a soubory. Zajímáme se o podřazené adresáře samples a engines. V adresáři samples se nacházejí příklady konfiguračních souborů se vlastnostmi uzlu, stejně jako příklady SQL skriptů pro rychlý start demonstrace.

V adresáři samples vidíme tři konfigurační soubory s vlastnostmi uzlu — název ukazuje charakter uzlu v daném schématu.

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

V SymmetricDS jsou všechny potřebné konfigurační soubory pro základní schéma ze 3 uzlů (varianta 1), a tyto stejné soubory lze použít i pro schéma ze 2 uzlů (varianta 2). Zkopírujeme potřebný konfigurační soubor z adresáře samples do engines na hostiteli vm1. Vypadá to takto:

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

Toto uzel v konfiguraci SymmetricDS se nazývá corp-000, a připojení k databázi se zpracovává ovladačem mysql jdbc, který využívá výše uvedený připojovací řetězec a přihlašovací údaje. Připojujeme se k databázi replica_db, a během vytváření schématu budou vytvořeny tabulky. sync.url ukazuje místo spojení s uzlem pro synchronizaci.

Uzel 2 na hostiteli vm2 se nastavuje jako store-001, a zbytek je uveden v souboru node.properties, který je uveden níže. Uzel store-001 provádí databázi PostgreSQL, a pgdb_replica je databází pro replikaci. registration.url umožňuje hostiteli vm2 připojit se k hostiteli vm1 a získat od něj detaily konfigurace.

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

Hotový příklad SymmetricDS obsahuje parametry pro nastavení obousměrné replikace mezi dvěma servery databází (dvěma uzly). Následující kroky se provádějí na hostiteli vm1 (corp-000), který vytvoří příklad schématu se 4 tabulkami. Poté provedení příkazu create-sym-tables pomocí symadmin vytvoří tabulky katalogu, kde budou uložena pravidla a směr replikace mezi uzly. Nakonec se do tabulek načtou příkladová data.

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

V příkladu jsou tabulky item a item_selling_price automaticky nastaveny pro replikaci z corp-000 do store-001, a tabulky sale (sale_transaction a sale_return_line_item) jsou automaticky nastaveny pro replikaci z store-001 do corp-000. Nyní vytváříme schéma v databázi PostgreSQL na hostiteli vm2 (store-001), abychom ji připravili na příjem dat od corp-000.

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

Nezapomeňte zkontrolovat, že v databázi MySQL na vm1 existují příklady tabulek a tabulky katalogů SymmetricDS. Všimněte si, že systémové tabulky SymmetricDS (s prefixem sym_) jsou nyní dostupné pouze na uzlu corp-000, protože tam jsme provedli příkaz create-sym-tables a budeme spravovat replikaci. A také, v databázi na uzlu store-001 bude celkem 4 tabulky příkladu bez dat.

Všechno. Prostředí je připraveno k spuštění serverových procesů sym na obou uzlech, jak je uvedeno níže.

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

Záznamy logů jsou odesílány do souboru pozadí logu (symmetric.log) ve složce logů v adresáři, kde je nainstalován SymmetricDS, a také do standardního výstupu. Server sym lze nyní spustit na uzlu store-001.

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

Pokud spustíme serverový proces sym na hostiteli vm2, vytvoří tabulky katalogu SymmetricDS i v databázi PostgreSQL. Pokud spustíme serverový proces sym na obou uzlech, koordinují se navzájem, aby replikovaly data z corp-000 na store-001. Pokud po několika sekundách požádáme o všechny 4 tabulky na obou stranách, uvidíme, že replikace proběhla úspěšně. Nebo můžeme poslat počáteční načtení na uzel store-001 z corp-000 následujícím příkazem.

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

V této fázi se do tabulky item v databázi MySQL na uzlu corp-000 (host: vm1) vloží nový záznam a můžeme zkontrolovat jeho replikaci do databáze PostgreSQL na uzlu store-001. Vidíme operaci Pull k přesunu dat z corp-000 do store-001.

mysql> insert into item values ('22000002','Jelly Bean');
Dotaz OK, 1 řádek ovlivněn (0.00 s)

vm2$> psql -p 5832 -U postgres pgdb_replica -c "select * from item"
 item_id  |   name
----------+-----------
 11000001 | Yummy Gum
 22000002 | Jelly Bean
(2 řádky)

Abychom provedli operaci Push k přesunu dat ze store-001 do corp-000, vložíme záznam do tabulky sale_transaction a zkontrolujeme, že replikace proběhla.

Result.

Vidíme úspěšné nastavení obousměrné replikace tabulek příkladu mezi databázemi MySQL a PostgreSQL. Abychom nastavili replikaci pro nové uživatelské tabulky, provedeme následující kroky. Vytvoříme tabulku t1 pro příklad a nastavíme pravidla její replikace následovně. Tak nastavujeme pouze replikaci z corp-000 do store-001.

mysql> create table t1 (no integer);
Dotaz OK, 0 řádků ovlivněno (0.01 s)

mysql> insert into sym_channel (channel_id,create_time,last_update_time) 
values ('t1',current_timestamp,current_timestamp);
Dotaz OK, 1 řádek ovlivněn (0.01 s)

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);
Dotaz OK, 1 řádek ovlivněn (0.01 s)

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);
Dotaz OK, 1 řádek ovlivněn (0.01 s)

Konfigurace dostává oznámení o změně schématu, tedy přidání nové tabulky, pomocí příkazu symadmin s argumentem sync-triggers, který znovu vytváří spouštěče pro porovnání definic tabulek. Probíhá send-schema pro odeslání změn schématu na uzel store-001 a replikace tabulky t1 je nastavena.

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

Výhody SymmetricDS

Jednoduchá instalace a konfigurace, včetně hotové sady souborů s parametry pro vytvoření schématu se třemi nebo dvěma uzly.
Mezi platformami kompatibilní databáze a nezávislost na platformách, včetně serverů, notebooků a mobilních zařízení.
Replikace jakékoli databáze do jakékoli jiné databáze lokálně, v WAN nebo v cloudu.
Schopnost optimálně pracovat s párem databází nebo tisíci pro pohodlnou replikaci.
Placená verze s grafickým rozhraním a vynikající podporou.

Nevýhody SymmetricDS

Je nutné ručně určovat v příkazovém řádku pravidla a směr replikace prostřednictvím SQL operátorů pro načítání tabulek katalogů, což může být nepohodlné.
Nastavování mnoha tabulek pro replikaci může být únavné, pokud se nepoužijí skripty pro vytvoření SQL operátorů, které určují pravidla a směr replikace.
Do logů se zaznamenává příliš mnoho informací, a někdy je potřeba uspořádat soubor logu, aby nezabíral příliš mnoho místa.

Shrnutí k SymmetricDS

SymmetricDS umožňuje nastavovat obousměrnou replikaci mezi dvěma, třemi a dokonce i několika tisíci uzly pro provádění replikace a synchronizaci souborů. Je to jedinečný nástroj, který sám vykonává mnoho úkolů, jako je automatické obnovení dat po dlouhé výpadku na uzlu, zabezpečená a efektivní výměna dat mezi uzly přes HTTPS, automatické řízení konfliktů na základě souboru pravidel atd. SymmetricDS provádí replikaci mezi jakýmikoli databázemi, takže jej lze použít pro různé scénáře, včetně migrace, přechodu na novou verzi, distribuce, filtrování a transformace dat na různých platformách.

Příklad byl vytvořen na základě oficiálního stručného průvodce k SymmetricDS. V uživatelské příručce podrobně vysvětleny různé pojmy související s nastavením replikace pomocí SymmetricDS.

Zdroj: habr.com