Stručně pohovořím o křížové replikaci mezi PostgreSQL a MySQL a také o metodách nastavení křížové replikace mezi těmito dvěma databázovými servery. Křížově replikované databáze se běžně označují jako homogenní databáze, což je vhodná metoda pro migraci z jednoho serveru RDBMS na druhý.
Databáze PostgreSQL a MySQL jsou tradičně 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 správy relačních databází.
Nebudeme popisovat všechny vnitřnosti, pouze základní principy, abyste si udělali představu o nastavení replikace mezi databázovými servery, výhodách, omezeních a případech použití.
Replikace mezi dvěma identickými databázovými servery se obvykle provádí buď v binárním režimu, nebo pomocí dotazů mezi hlavním (aka vydavatel, hlavní nebo aktivní) a podřízeným (předplatitel, pohotovostní nebo pasivní). Účelem replikace je poskytnout kopii hlavní databáze v reálném čase na straně pohotovostního režimu. V tomto případě jsou data přenášena z master na slave, tedy z aktivního do pasivního, protože replikace se provádí pouze v jednom směru. Můžete však nastavit replikaci mezi dvěma databázemi v obou směrech, takže data jsou přenášena z podřízeného do nadřízeného v konfiguraci aktivní-aktivní. To vše, včetně kaskádové replikace, je možné mezi dvěma nebo více identickými databázovými servery. Konfigurace aktivní-aktivní nebo aktivní-pasivní závisí na potřebě, dostupnosti takových schopností v počáteční konfiguraci nebo použití externích tuningových řešení a stávajícím obchodu -offs .
Popsaná konfigurace je možná mezi různými databázovými servery. Server lze nakonfigurovat tak, aby přijímal replikovaná data z jiného databázového serveru a stále uchovával snímky replikovaných dat v reálném čase. MySQL a PostgreSQL nabízejí většinu těchto konfigurací nativně nebo prostřednictvím rozšíření třetích stran, včetně metod binárních protokolů, zámků disku a metod založených na příkazech a řádcích.
Křížová replikace mezi MySQL a PostgreSQL je nutná pro jednorázovou migraci z jednoho databázového serveru na druhý. Tyto databáze používají různé protokoly, takže je nelze přímo propojit. Pro usnadnění výměny dat můžete použít externí open source nástroj, jako je pg_chameleon.
Co je pg_chameleon
pg_chameleon je replikační systém z MySQL do PostgreSQL v Pythonu 3. Používá open source knihovnu mysql-replication, také v Pythonu. Obrázky řádků jsou načteny z tabulek MySQL a uloženy jako objekty JSONB v databázi PostgreSQL a poté dekódovány funkcí pl/pgsql a přehrány v databázi PostgreSQL.
Vlastnosti pg_chameleon
Více schémat MySQL ze stejného clusteru lze replikovat do jediné cílové databáze PostgreSQL s konfigurací jedna k mnoha
Názvy zdrojových a cílových schémat nemohou být stejné.
Data replikace lze získat z kaskádové repliky MySQL.
Tabulky, které se nemohou replikovat nebo generovat chyby, jsou vyloučeny.
Každá replikační funkce je řízena démony.
Ovládání pomocí parametrů a konfiguračních souborů založených na 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
DB port
3306
5433
IP adresa
192.168.56.102
192.168.56.106
Nejprve si připravte všechny potřebné komponenty pro instalaci pg_chameleon. Tento příklad má nainstalovaný Python 3.6.8, který vytváří 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 altinstallJakmile je Python3.6 úspěšně nainstalován, je třeba dokončit ostatní požadavky, jako je vytvoření a aktivace virtuálního prostředí. Modul pip je také aktualizován na nejnovější verzi a používá se k instalaci pg_chameleon. Níže uvedené příkazy záměrně instalují pg_chameleon 2.0.9, i když nejnovější verze je 2.0.10. To je nezbytné, aby se zabránilo 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.9Potom zavoláme pg_chameleon (chameleon je příkaz) s argumentem set_configuration_files, abychom povolili pg_chameleon a vytvořili výchozí konfigurační adresáře a 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/
copying configuration example in /root/.pg_chameleon/configuration//config-example.ymlNyní vytvoříme kopii config-example.yml jako default.yml, takže se stane výchozím konfiguračním souborem. Ukázkový konfigurační soubor pro tento příklad je uveden níže.
$> 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:Konfigurační soubor v tomto příkladu je ukázkový soubor pg_chameleon s drobnými úpravami, aby odpovídal zdrojovému a cílovému prostředí, a níže je přehled různých částí konfiguračního souboru.
Konfigurační soubor default.yml má sekci globálního nastavení (globální nastavení), kde můžete ovládat nastavení, jako je umístění souboru zámku, umístění protokolů, doba uložení protokolů atd. Dále následuje přepsání typu sekce, kde jsou nastavena pravidla pro přepisování typů během replikace. Výchozí příklad používá pravidlo přepisu typu, které převádí tinyint(1) na booleovský. V další části upřesníme detaily připojení k cílové databázi. V našem případě se jedná o PostgreSQL databázi, označenou jako pg_conn. V poslední části specifikujeme zdrojová data, tedy parametry připojení zdrojové databáze, schéma mapování zdrojové a cílové databáze, tabulky k přeskočení, timeout, paměť, velikost balíčku. Všimněte si, že "zdroje" je množné číslo, což znamená, že ke stejnému cíli můžeme přidat více zdrojových databází a nastavit konfiguraci typu many-to-one.
Databáze world_x v příkladu obsahuje 4 tabulky s řádky, které komunita MySQL pro příklad navrhuje. Dá se stáhnout . Vzorová databáze je dodávána jako tar a komprimovaný archiv s pokyny pro vytváření a import řetězců.
V databázích MySQL a PostgreSQL je vytvořen speciální uživatel se stejným názvem usr_replica. MySQL mu poskytuje další přístup pro čtení ke všem replikovaným tabulkám.
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 je vytvořena databáze db_replica, která bude přijímat změny z databáze MySQL. Uživatel usr_replica v PostgreSQL je automaticky nakonfigurován jako vlastník dvou schémat pgworld_x a sch_chameleon, která obsahují skutečné replikované tabulky a tabulky replikačního katalogu. Argument create_replica_schema je zodpovědný za automatickou konfiguraci, 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 DATABASEDatabáze MySQL je nakonfigurována s některými změnami, aby byla připravena na replikaci, jak je uvedeno níže. Aby se změny projevily, budete muset restartovat databázový server.
$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1Nyní je důležité zkontrolovat připojení k oběma databázovým serverům, aby nedošlo k problémům při provádění příkazů pg_chameleon.
Na uzlu PostgreSQL:
$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_xNa MySQL uzlu:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaDalší tři příkazy pg_chameleon (chameleon) připraví prostředí, přidají zdroj a inicializují repliku. Argument create_replica_schema pro pg_chameleon vytváří výchozí schéma (sch_chameleon) a schéma replikace (pgworld_x) v databázi PostgreSQL, jak jsme řekli. Argument add_source přidá zdrojovou databázi do konfigurace načtením konfiguračního souboru (default.yml), což je v našem případě mysql, a init_replica inicializuje konfiguraci na základě nastavení 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 --debugVýstup těchto tří příkazů jasně naznačuje jejich úspěch. Všechna selhání nebo syntaktické chyby jsou indikovány v jednoduchých a srozumitelných zprávách s radami, jak problémy opravit.
Nakonec spustíme replikaci pomocí start_replica a dostaneme zprávu o úspěchu.
$> chameleon start_replica --config default --source mysql
output: Starting the replica process for source mysqlNa stav replikace se lze dotázat pomocí argumentu show_status a chyby lze zobrazit pomocí argumentu show_errors.
Jak jsme již řekli, démoni řídí každou funkci replikace. Chcete-li je zobrazit, dotazujte se na tabulku procesů pomocí příkazu Linux ps, jak je znázorněno níže.
Replikace se nepovažuje za nakonfigurovanou, dokud ji neotestujeme v reálném čase, jak je uvedeno níže. Vytvoříme tabulku, vložíme několik záznamů do databáze MySQL a zavoláme argument sync_tables v pg_chameleon, abychom aktualizovali démony a zkopírovali tabulku se záznamy do databáze PostgreSQL.
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.Abychom ověřili výsledky testu, dotazujeme se na tabulku z databáze PostgreSQL a vypíšeme řádky.
$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
n1 | n2
----+-------
1 | one
2 | twoPokud provádíme migraci, následující příkazy pg_chameleon budou konec migrace. Příkazy by měly být spuštěny poté, co ověříme, že řádky všech cílových tabulek byly replikovány, výsledkem je úhledně migrovaná databáze PostgreSQL bez odkazů na zdrojovou databázi nebo schéma replikace (sch_chameleon).
$> chameleon stop_replica --config default --source mysql
$> chameleon detach_replica --config default --source mysql --debugPůvodní konfiguraci a schéma replikace můžete volitelně odstranit pomocí následujících příkazů.
$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debugVýhody pg_chameleon
Snadné nastavení a konfigurace.
Pohodlné řešení problémů a detekce anomálií s jasnými chybovými zprávami.
Po inicializaci lze do replikace přidat další speciální tabulky, aniž by bylo nutné měnit zbytek konfigurace.
Pro jednu cílovou databázi je možné nastavit více zdrojových databází, což je velmi praktické, pokud slučujete data z jedné nebo více MySQL databází do jedné PostgreSQL databáze.
Můžete se rozhodnout nereplikovat vybrané tabulky.
Nevýhody pg_chameleon
Podporováno pouze s MySQL 5.5 a vyšší jako zdrojová a PostgreSQL 9.5 a vyšší jako cílová databáze.
Každá tabulka musí mít primární nebo jedinečný klíč, jinak jsou tabulky inicializovány v procesu init_replica, ale nejsou replikovány.
Jednosměrná replikace - pouze z MySQL do PostgreSQL. Proto je vhodný pouze pro aktivní-pasivní schéma.
Zdrojem může být pouze databáze MySQL a podpora databáze PostgreSQL jako zdroje je pouze experimentální a omezená (více informací )
Součty pro pg_chameleon
Metoda replikace v pg_chameleon je skvělá pro migraci databáze z MySQL do PostgreSQL. Velkou nevýhodou je, že replikace je pouze jednosměrná, takže databázoví profesionálové ji pravděpodobně nebudou chtít používat k něčemu jinému než k migraci. Ale problém jednosměrné replikace lze vyřešit jiným open source nástrojem – SymmetricDS.
Více se dočtete v oficiální dokumentaci . Nápovědu k příkazovému řádku lze nalézt .
Přehled SymmetricDS
SymmetricDS je nástroj s otevřeným zdrojovým kódem, který replikuje 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ší instance cloudové databáze, například Redshift, a Azure atd. Dostupné funkce: synchronizace databází a souborů, replikace multi-master databáze, filtrovaná synchronizace, transformace a další. Toto je nástroj Java a vyžaduje standardní verzi JRE nebo JDK (verze 8.0 nebo vyšší). Zde můžete zaznamenat změny dat na triggerech ve zdrojové databázi a odeslat je do odpovídající cílové databáze jako dávky.
Schopnosti SymmetricDS
Nástroj je nezávislý na platformě, což znamená, že si data mohou vyměňovat dvě nebo více různých databází.
Relační databáze se synchronizují záznamem změn dat a databáze založené na souborových systémech používají synchronizaci souborů.
Obousměrná replikace pomocí metod push a pull na základě sady pravidel.
Přenos dat je možný přes zabezpečené sítě a sítě s malou šířkou pásma.
Automatické obnovení při obnovení uzlů po selhání a automatické řešení konfliktů.
Cloud kompatibilní a efektivní rozšiřující API.
příklad
SymmetricDS lze nakonfigurovat jedním ze dvou způsobů:
Hlavní (nadřazený) uzel, který centrálně koordinuje replikaci dat mezi dvěma podřízenými (podřízenými) uzly, a výměna dat mezi podřízenými uzly se provádí pouze prostřednictvím nadřazeného uzlu.
Aktivní uzel (uzel 1) může komunikovat za účelem replikace s jiným aktivním uzlem (uzel 2) bez prostředníka.
V obou možnostech dochází k výměně dat pomocí Push a Pull. V tomto příkladu budeme uvažovat konfiguraci aktivní-aktivní. Na popis celé architektury je to příliš dlouhé, tak studujte se dozvíte více o zařízení SymmetricDS.
Instalace SymmetricDS je snadná: stáhněte si open source soubor zip a extrahujte jej, kam chcete. Následující tabulka uvádí umístění instalace a verzi SymmetricDS v tomto příkladu a také verze databáze, 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
DB port
3306
5832
IP adresa
192.168.1.107
192.168.1.112
Verze SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9
Instalační cesta SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20
Název hostitele SymmetricDS
corp-000
obchod-001
Zde nainstalujeme SymmetricDS do /usr/local/symmetric-server-3.9.20 a budou se zde ukládat různé podadresáře a soubory. Zajímají nás podadresáře vzorky a motory. Adresář vzorků obsahuje ukázkové konfigurační soubory s vlastnostmi uzlů a také ukázkové skripty SQL pro rychlé spuštění ukázky.
V adresáři vzorků vidíme tři konfigurační soubory s vlastnostmi uzlu – název ukazuje povahu uzlu v konkrétním schématu.
corp-000.properties
store-001.properties
store-002.propertiesSymmetricDS má všechny potřebné konfigurační soubory pro základní schéma se 3 uzly (volba 1) a stejné soubory lze použít pro schéma se 2 uzly (volba 2). Zkopírujte požadovaný konfigurační soubor z adresáře vzorků do motorů na hostiteli vm1. Dopadne 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=000Tento uzel se v konfiguraci SymmetricDS nazývá corp-000 a o připojení k databázi se stará ovladač mysql jdbc, který používá výše uvedený připojovací řetězec a přihlašovací údaje. Připojujeme se k databázi replica_db a při vytváření schématu se vytvoří tabulky. sync.url zobrazuje odkaz na uzel, který se má synchronizovat.
Uzel 2 na hostiteli vm2 je nakonfigurován jako store-001 a zbytek je specifikován v souboru node.properties níže. Uzel store-001 spouští databázi PostgreSQL a pgdb_replica je databáze k replikaci. registration.url umožňuje hostiteli vm2 kontaktovat hostitele vm1 a získat od něj podrobnosti o konfiguraci.
$> 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=001Dokončený příklad SymmetricDS obsahuje volby pro nastavení obousměrné replikace mezi dvěma databázovými servery (dva uzly). Níže uvedené kroky se provádějí na hostiteli vm1 (corp-000), který vytvoří vzorové schéma se 4 tabulkami. Potom spuštění create-sym-tables pomocí příkazu symadmin vytvoří tabulky adresářů, kde budou uložena pravidla a směr replikace mezi uzly. Nakonec se vzorová data načtou do tabulek.
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.sqlV příkladu jsou tabulky item a item_selling_price automaticky nakonfigurovány tak, aby se replikovaly z corp-000 do store-001, a tabulky prodeje (sale_transaction a sale_return_line_item) jsou automaticky nakonfigurovány tak, aby se replikovaly z store-001 na corp-000. Nyní vytvoříme schéma v databázi PostgreSQL na hostiteli vm2 (store-001), abychom jej připravili na příjem dat z corp-000.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xmlNezapomeňte zkontrolovat, že databáze MySQL na vm1 obsahuje vzorové tabulky a tabulku katalogu SymmetricDS. Všimněte si, že systémové tabulky SymmetricDS (s předponou sym_) jsou aktuálně dostupné pouze na uzlu corp-000, protože tam jsme spustili příkaz create-sym-tables a budeme spravovat replikaci. A v databázi v uzlu store-001 budou pouze 4 ukázkové tabulky bez dat.
Všechno. Prostředí je připraveno ke spuštění procesů sym serveru na obou uzlech, jak je znázorněno níže.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &Záznamy protokolu jsou odesílány do souboru protokolu na pozadí (symetrický.log) ve složce protokolu v adresáři, kde je nainstalován SymmetricDS, a také na standardní výstup. Sym server lze nyní spustit na uzlu store-001.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &Pokud spustíte proces sym serveru na hostiteli vm2, vytvoří se tabulky katalogu SymmetricDS také v databázi PostgreSQL. Pokud spustíte proces sym serveru na obou uzlech, budou se vzájemně koordinovat, aby replikovaly data z corp-000 do store-001. Pokud po několika sekundách provedeme dotaz na všechny 4 tabulky na obou stranách, uvidíme, že replikace proběhla úspěšně. Nebo můžete odeslat bootstrap do store-001 z corp-000 pomocí následujícího příkazu.
vm1$> ./symadmin --engine corp-000 reload-node 001V tomto okamžiku je nový záznam vložen do tabulky položek v databázi MySQL na uzlu corp-000 (hostitel: vm1) a lze zkontrolovat replikaci do databáze PostgreSQL na uzlu store-001 (hostitel: vm2). Vidíme operaci Pull pro přesun dat z corp-000 do 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)Chcete-li provést operaci push k přesunutí dat z store-001 do corp-000, vložíme záznam do tabulky sale_transaction a ověříme, že replikace byla dokončena.
Vidíme úspěšné nastavení obousměrné replikace ukázkových tabulek mezi databázemi MySQL a PostgreSQL. Chcete-li nastavit replikaci pro nové uživatelské tabulky, proveďte následující kroky. Vytvoříme například tabulku t1 a nastavíme její pravidla replikace následovně. Nastavili jsme tedy pouze replikaci z corp-000 do 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)Konfigurace je poté upozorněna na změnu schématu, tj. přidání nové tabulky, pomocí příkazu symadmin s argumentem sync-triggers, který znovu vytvoří spouštěče tak, aby odpovídaly definicím tabulky. Spustí se Send-schema k odeslání změn schématu do úložiště-001 a replikuje se tabulka t1.
vm1$> ./symadmin -e corp-000 --node=001 sync-triggers
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1Výhody SymmetricDS
Snadná instalace a konfigurace včetně hotové sady souborů s parametry pro vytvoření schématu se třemi nebo dvěma uzly.
Databáze napříč platformami a nezávislost na platformě, včetně serverů, notebooků a mobilních zařízení.
Replikujte jakoukoli databázi do jakékoli jiné databáze lokálně, na WAN nebo v cloudu.
Schopnost optimálně pracovat s několika databázemi nebo několika tisíci pro snadnou replikaci.
Placená verze s GUI a výbornou podporou.
Nevýhody SymmetricDS
Chcete-li načíst tabulky katalogu, musíte ručně definovat pravidla a směr replikace na příkazovém řádku pomocí příkazů SQL, což může být nepohodlné.
Nastavení mnoha tabulek pro replikaci může být únavné, pokud nepoužíváte skripty k vytváření příkazů SQL, které definují pravidla a směr replikace.
V protokolech je příliš mnoho informací a někdy je třeba soubor protokolu vyčistit, aby nezabíral příliš mnoho místa.
Shrnutí SymmetricDS
SymmetricDS umožňuje nastavit obousměrnou replikaci mezi dvěma, třemi nebo dokonce několika tisíci uzly za účelem replikace a synchronizace souborů. Jde o unikátní nástroj, který sám o sobě plní mnoho úkolů, jako je automatická obnova dat po dlouhém výpadku uzlu, bezpečná a efektivní komunikace mezi uzly přes HTTPS, automatické řízení konfliktů na základě sady pravidel atd. SymmetricDS replikuje mezi libovolnými databázemi, proto jej lze použít pro širokou škálu scénářů, včetně migrace, upgradu, distribuce, filtrování a transformace dat napříč platformami.
Příklad je založen na úředním od SymmetricDS. V Podrobně popisuje různé koncepty zapojené do nastavení replikace pomocí SymmetricDS.
Zdroj: www.habr.com