Přehled křížové replikace PostgreSQL a MySQL

Tento blog je zaměřen na vysvětlení přehledu křížové replikace mezi PostgreSQL a MySQL a další diskusi o metodách konfigurace křížové replikace mezi dvěma databázovými servery. Tradičně se databáze zapojené do nastavení křížové replikace nazývají heterogenní databáze, což je dobrý přístup k přesunu z jednoho RDBMS serveru na druhý.

Databáze PostgreSQL i MySQL jsou konvenčně databázemi RDBMS, ale nabízejí také funkci NoSQL s přidanými rozšířeními, abyste měli to nejlepší z obou světů. Tento článek se zaměřuje na diskuzi o replikaci mezi PostgreSQL a MySQL z pohledu RDBMS.

Vyčerpávající vysvětlení vnitřních částí replikace není v působnosti tohoto blogu, nicméně některé základní prvky budou diskutovány, aby publikum porozumělo tomu, jak je replikace konfigurována mezi databázovými servery, výhody, omezení a možná některé známé případy použití.

Obecně se replikace mezi dvěma identickými databázovými servery dosahuje buď v binárním režimu nebo v dotazovacím režimu mezi hlavním uzlem (jinak nazývaným vydavatel, primární nebo aktivní) a podřízeným uzlem (předplatitelský, pohotovostní nebo pasivní). Cílem replikace je poskytnout kopii hlavní databáze na straně slave v reálném čase, kde jsou data přenášena z master na slave, čímž se vytvoří aktivní-pasivní nastavení, protože replikace je nakonfigurována pouze jedním způsobem. Na druhou stranu replikaci mezi dvěma databázemi lze konfigurovat oběma způsoby, takže data lze také přenášet z podřízené zpět na hlavní, čímž se vytvoří konfigurace aktivní-aktivní. To vše lze konfigurovat mezi dvěma nebo více identickými databázovými servery, které mohou také zahrnovat kaskádovou replikaci. Konfigurace aktivní-aktivní nebo aktivní-pasivní skutečně závisí na obchodních potřebách, dostupnosti takových funkcí v nativní konfiguraci nebo na využití externích řešení pro konfiguraci a použitelných kompromisech.

Výše zmíněnou konfiguraci lze provést s různými databázovými servery, přičemž databázový server lze konfigurovat tak, aby přijímal replikovaná data z jiného zcela odlišného databázového serveru a stále udržoval snímek replikovaných dat v reálném čase. Databázové servery MySQL i PostgreSQL nabízejí většinu výše uvedených konfigurací buď ve své vlastní nativitě, nebo s pomocí rozšíření třetích stran, včetně metody binárního protokolu, metody diskového bloku, metody založené na příkazech a metodách založených na řádcích.

Požadavek na konfiguraci křížové replikace mezi MySQL a PostgreSQL skutečně přichází jako výsledek snahy o jednorázovou migraci s cílem přesunout se z jednoho databázového serveru na druhý. Protože obě databáze používají různé protokoly, nemohou spolu přímo mluvit. K dosažení tohoto komunikačního toku existuje externí open source nástroj, jako je pg_chameleon.

Pozadí pg_chameleon

pg_chameleon je replikační systém MySQL na PostgreSQL vyvinutý v Pythonu 3. Používá knihovnu s otevřeným zdrojovým kódem nazvanou mysql-replication, která je také vyvinuta pomocí Pythonu. Tato funkce zahrnuje stahování obrázků řádků tabulek MySQL a jejich ukládání jako objekty JSONB do databáze PostgreSQL, která je dále dekódována funkcí pl/pgsql a přehrání těchto změn proti databázi PostgreSQL.

Funkce pg_chameleon

• Více schémat MySQL ze stejného klastru lze replikovat do jedné cílové databáze PostgreSQL a vytvořit tak nastavení replikace mnoho ku jedné
• Názvy zdrojových a cílových schémat mohou být neidentické
• Data replikace lze získat z kaskádové repliky MySQL
• Tabulky, které se nereplikují nebo generují chyby, jsou vyloučeny
• Každá replikační funkce je spravována pomocí démonů
• Řízeno pomocí parametrů a konfiguračních souborů založených na konstrukci YAML

Ukázka

Nejprve si připravte nastavení se všemi předpoklady potřebnými k instalaci pg_chameleon. V tomto demu je nainstalován Python 3.6.8, který vytváří virtuální prostředí a aktivuje jej pro použití.

$> 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 jsou splněny další dodatečné požadavky, jako je vytvoření a aktivace virtuálního prostředí. Kromě toho je modul pip upgradován na nejnovější verzi a používá se k instalaci pg_chameleon. V níže uvedených příkazech byl záměrně nainstalován pg_chameleon 2.0.9, zatímco nejnovější verze je 2.0.10. Děje se tak, aby se předešlo případným nově zavedený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

Dalším krokem je vyvolání pg_chameleon (chameleon je příkaz) s argumentem set_configuration_files, aby pg_chameleon mohl vytvářet 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/
copying configuration  example in /root/.pg_chameleon/configuration//config-example.yml

Nyní vytvořte kopii souboru config-example.yml jako default.yml, aby se stal výchozím konfiguračním souborem. Vzorový konfigurační soubor použitý pro toto demo 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 použitý v této ukázce je ukázkový soubor, který je dodáván s pg_chameleon s drobnými úpravami, aby vyhovoval zdrojovému a cílovému prostředí, a následuje shrnutí různých částí konfiguračního souboru.

Konfigurační soubor default.yml má sekci „globální nastavení“, která řídí podrobnosti, jako je umístění souboru zámku, umístění protokolování a období uchování atd. Následující sekce je sekce „přepsání typu“, což je sada pravidel, která mají být přepsána. typů během replikace. Standardně se používá pravidlo přepsání vzorového typu, které převádí tinyint(1) na booleovskou hodnotu. Další částí je část s podrobnostmi o připojení k cílové databázi, což je v našem případě databáze PostgreSQL, označená jako „pg_conn“. Poslední částí je zdrojová část, která obsahuje všechny podrobnosti o nastavení připojení ke zdrojové databázi, mapování schématu mezi zdrojem a cílem, jakékoli tabulky k přeskočení včetně časového limitu, paměti a nastavení velikosti dávky. Všimněte si „zdrojů“, které označují, že k jednomu cíli může být více zdrojů, aby se vytvořilo nastavení replikace mnoho ku jednomu.

V tomto demu je použita databáze „world_x“, což je vzorová databáze se 4 tabulkami obsahujícími vzorové řádky, kterou komunita MySQL nabízí pro účely demonstrací, a lze ji stáhnout zde. Vzorová databáze je dodávána jako tar a komprimovaný archiv spolu s pokyny k jejímu vytvoření a importu řádků do ní.

V databázích MySQL i PostgreSQL je vytvořen vyhrazený uživatel se stejným jménem jako usr_replica, kterému jsou dále udělena další oprávnění v MySQL, aby měl přístup pro čtení ke všem tabulkám, které se replikují.

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 vytvoří databáze, která bude přijímat změny z databáze MySQL, která se jmenuje „db_replica“. Uživatel „usr_replica“ v PostgreSQL je automaticky nakonfigurován jako vlastník dvou schémat, jako je „pgworld_x“ a „sch_chameleon“, která obsahují skutečné replikované tabulky a katalogové tabulky replikace. Tato automatická konfigurace se provádí pomocí argumentu create_replica_schema, který je uveden dále.

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

Databáze MySQL je nakonfigurována s několika změnami parametrů, aby byla připravena na replikaci, jak je uvedeno níže, a změny se projeví až po restartování databázového serveru.

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

V tomto okamžiku je důležité otestovat konektivitu k oběma databázovým serverům, abyste se ujistili, že při provádění příkazů pg_chameleon nedochází k žádným problémům.

V uzlu PostgreSQL:

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

V uzlu MySQL:

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

Další tři příkazy pg_chameleon (chameleon) jsou tam, kde nastaví prostředí, přidá zdroj a inicializuje repliku. Argument „create_replica_schema“ pg_chameleon vytváří výchozí schéma (sch_chameleon) a schéma replikace (pgworld_x) v databázi PostgreSQL, jak již bylo diskutováno. Argument „add_source“ přidá zdrojovou databázi do konfigurace načtením konfiguračního souboru (default.yml), což je v tomto případě „mysql“, zatímco „init_replica“ inicializuje konfiguraci na základě nastavení konfiguračního souboru.

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

Výstup výše uvedených tří příkazů je samozřejmý a ukazuje úspěch každého příkazu s evidentní výstupní zprávou. Jakékoli selhání nebo syntaktické chyby jsou jasně zmíněny v jednoduchých a jasných zprávách, čímž se navrhují a vybízejí k nápravným akcím.

Posledním krokem je spuštění replikace pomocí „start_replica“, jejíž úspěch je indikován výstupní nápovědou, jak je uvedeno níže.

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

Na stav replikace se lze dotázat pomocí argumentu „show_status“, zatímco chyby lze zobrazit pomocí argumentu „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

Jak bylo uvedeno výše, každá z replikačních funkcí je spravována pomocí démonů, které lze zobrazit dotazem na tabulku procesů pomocí příkazu Linux „ps“, který je uveden níže.

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

Žádné nastavení replikace není dokončeno, dokud není podrobeno testu „použití v reálném čase“, který byl simulován níže. Zahrnuje vytvoření tabulky a vložení několika záznamů do databáze MySQL, následně je vyvolán argument „sync_tables“ pg_chameleon, aby se aktualizovali démoni, aby replikovali tabulku spolu s jejími 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.

Test je potvrzen dotazem na tabulku z databáze PostgreSQL, aby odpovídala řádkům.

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

Pokud se jedná o projekt migrace, následující příkazy pg_chameleon označí konec úsilí o migraci. Příkazy by měly být provedeny poté, co se potvrdí, že řádky všech cílových tabulek byly replikovány napříč, a výsledkem bude čistě migrovaná databáze PostgreSQL bez jakýchkoli 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 --debug

Následující příkazy volitelně zruší zdrojovou konfiguraci a schéma replikace.

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

Výhody používání pg_chameleon

• Jednoduché nastavení a méně komplikovaná konfigurace
• Bezbolestné odstraňování problémů a detekce anomálií se snadno srozumitelným výstupem chyb
• Po inicializaci lze do replikace přidat další tabulky adhoc, aniž by se změnila jakákoli další konfigurace
• Pro jednu cílovou databázi lze nakonfigurovat více zdrojů, což je užitečné v projektech konsolidace ke sloučení dat z jedné nebo více databází MySQL do jediné databáze PostgreSQL
• Replikaci vybraných tabulek lze přeskočit

Nevýhody použití pg_chameleon

• Podporováno pouze od MySQL 5.5 a novější jako databáze Origin a PostgreSQL 9.5 a novější pro cílovou databázi
• Vyžaduje, aby každá tabulka měla primární nebo jedinečný klíč, jinak se tabulky inicializují během procesu init_replica, ale replikace se nezdaří
• Jednosměrná replikace, tj. z MySQL na PostgreSQL. Tím je jeho použití omezeno pouze na aktivní-pasivní nastavení
• Zdrojovou databází může být pouze databáze MySQL, zatímco podpora databáze PostgreSQL jako zdroje je experimentální s dalšími omezeními (další informace získáte kliknutím sem)

shrnutí pg_chameleon

Replikační přístup nabízený pg_chameleon je příznivý pro migraci databáze MySQL na PostgreSQL. Jedno z významných omezení jednosměrné replikace však může odradit databázové profesionály, aby ji přijali pro cokoli jiného než migraci. Tuto nevýhodu jednosměrné replikace lze vyřešit pomocí dalšího open source nástroje nazvaného SymmetricDS.

Chcete-li nástroj prostudovat podrobněji, podívejte se prosím na oficiální dokumentaci zde. Odkaz na příkazový řádek lze získat zde.

Přehled SymmetricDS

SymmetricDS je nástroj s otevřeným zdrojovým kódem, který je schopen replikovat jakoukoli databázi do jakékoli jiné databáze, z oblíbeného seznamu databázových serverů, jako jsou Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird a další cloudové instance databáze, jako je Redshift a Azure atd. Některé z nabídek zahrnují synchronizaci databází a souborů, replikaci s více mastery, filtrovanou synchronizaci a transformaci. Nástroj je vyvíjen pomocí Java a vyžaduje standardní edici (verze 8.0 nebo vyšší) JRE nebo JDK. Funkce zahrnuje zachycení změn dat pomocí spouštěčů ve zdrojové databázi a jejich směrování do zúčastněné cílové databáze jako odchozí dávky

Funkce SymmetricDS

• Nezávislý na platformě, což znamená, že dvě nebo více různých databází mohou spolu komunikovat, jakákoli databáze s jakoukoli jinou databází
• Relační databáze dosahují synchronizace pomocí sběru dat změn, zatímco systémy založené na souborových systémech využívají synchronizaci souborů
• Obousměrná replikace pomocí metody Push and Pull, která se provádí na základě nastavených pravidel
• Přenos dat může probíhat také v zabezpečených sítích s nízkou šířkou pásma
• Automatické obnovení během obnovení zhrouceného uzlu a automatické řešení konfliktů
• Připraveno pro cloud a obsahuje výkonná rozhraní API pro rozšíření

Ukázka

SymmetricDS lze nakonfigurovat v jedné ze dvou možností:

• Hlavní (nadřazený) uzel, který funguje jako centralizovaný prostředník koordinující replikaci dat mezi dvěma podřízenými (podřízenými) uzly, ve kterém může komunikace mezi dvěma podřízenými uzly probíhat pouze prostřednictvím nadřazeného uzlu.
• Aktivní uzel (node1) se může replikovat do az jiného aktivního uzlu (node2) bez jakéhokoli prostředníka.

V obou možnostech komunikace mezi uzly probíhá prostřednictvím událostí „Push“ a „Pull“. V tomto demu bude vysvětlena konfigurace aktivní-aktivní mezi dvěma uzly. Úplná architektura může být vyčerpávající, proto doporučujeme čtenářům, aby si prohlédli uživatelskou příručku, která je k dispozici zde, aby se dozvěděli více o vnitřnostech SymmetricDS.

Instalace SymmetricDS je stejně jednoduchá jako stažení open source verze souboru zip odtud a její rozbalení na vhodném místě. Podrobnosti o umístění instalace a verzi SymmetricDS v této ukázce jsou uvedeny v tabulce níže spolu s dalšími podrobnostmi týkajícími se verzí databáze, verzí Linuxu, IP adres a komunikačního portu pro oba zúčastněné uzly.

Domovem instalace je v tomto případě „/usr/local/symmetric-server-3.9.20“, což bude domovský adresář SymmetricDS, který obsahuje různé další podadresáře a soubory. Dva z podadresářů, které jsou nyní důležité, jsou „samples“ a „engines“. Adresář vzorků obsahuje ukázky konfiguračního souboru vlastností uzlů kromě ukázkových skriptů SQL pro nastartování rychlé ukázky.

Následující tři konfigurační soubory vlastností uzlu lze vidět v adresáři „samples“ s názvy označujícími povahu uzlu v daném nastavení.

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

Protože SymmetricDS přichází se všemi potřebnými konfiguračními soubory pro podporu základního nastavení se 3 uzly (volba 1), je vhodné použít stejné konfigurační soubory také pro nastavení nastavení se 2 uzly (volba 2). Zamýšlený konfigurační soubor je zkopírován z adresáře „samples“ do „engines“ na hostiteli vm1 a vypadá následovně.

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

Název tohoto uzlu v konfiguraci SymmetricDS je „corp-000“, přičemž připojení k databázi je zpracováno ovladačem mysql jdbc pomocí připojovacího řetězce, jak je uvedeno výše, spolu s přihlašovacími údaji. Databáze pro připojení je „replica_db“ a tabulky budou vytvořeny během vytváření vzorového schématu. „sync.url“ označuje místo, kde se má uzel kontaktovat za účelem synchronizace.

Uzel 2 na hostiteli vm2 je nakonfigurován jako „store-001“, přičemž ostatní podrobnosti jsou nakonfigurovány v souboru node.properties, který je zobrazen níže. Uzel „store-001“ provozuje databázi PostgreSQL s „pgdb_replica“ jako databází pro replikaci. Adresa „registration.url“ umožňuje hostiteli „vm2“ komunikovat s hostitelem „vm1“ za účelem získání podrobností 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=001

Předkonfigurovaná výchozí ukázka SymmetricDS obsahuje nastavení 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. Spuštění „create-sym-tables“ pomocí příkazu „symadmin“ dále vytvoří katalogové tabulky, které ukládají a řídí pravidla a směr replikace mezi uzly. Nakonec jsou ukázkové tabulky načteny ukázkovými daty.

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

Ukázkové tabulky „item“ a „item_selling_price“ jsou automaticky nakonfigurovány tak, aby se replikovaly z corp-000 do obchodu-001, zatímco tabulky prodeje (sale_transaction a sale_return_line_item) jsou automaticky konfigurovány z replikace z obchodu-001 na corp-000. Dalším krokem je vytvoření vzorového schématu v databázi PostgreSQL na hostiteli vm2 (store-001), aby bylo možné jej připravit 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.xml

V této fázi je důležité ověřit existenci ukázkových tabulek a tabulek katalogu SymmetricDS v databázi MySQL na vm1. Všimněte si, že systémové tabulky SymmetricDS (tabulky s předponou „sym_“) jsou v tomto okamžiku dostupné pouze v uzlu corp-000, protože tam byl proveden příkaz „create-sym-tables“, což bude místo. k řízení a správě replikace. Kromě toho bude databáze uzlů store-001 obsahovat pouze 4 ukázkové tabulky bez dat.

Prostředí je nyní připraveno ke spuštění „sym“ serverových procesů na obou uzlech, jak je uvedeno níže.

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

Položky protokolu jsou odesílány do souboru protokolu na pozadí (symetrický.log) v adresáři protokolů v umístění instalace SymmetricDS a také na standardní výstup. Server „sym“ lze nyní spustit na uzlu store-001.

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

Spuštění procesu „sym“ serveru na hostiteli vm2 vytvoří tabulky katalogu SymmetricDS také v databázi PostgreSQL. Spuštění procesu „sym“ serveru na obou uzlech je přiměje ke vzájemné koordinaci za účelem replikace dat z corp-000 do store-001. Po několika sekundách dotazování na všechny čtyři tabulky na obou stranách zobrazí výsledky úspěšné replikace. Alternativně lze počáteční zatížení odeslat do uzlu store-001 z corp-000 pomocí příkazu níže.

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

V tomto okamžiku je do tabulky „item“ v databázi MySQL v uzlu corp-000 (hostitel:vm1) vložen nový záznam a lze ověřit, že se úspěšně replikoval do databáze PostgreSQL v uzlu store-001 (hostitel:vm2 ). Toto ukazuje událost „Pull“ 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)

Událost „Push“ dat z obchodu-001 do corp-000 lze dosáhnout vložením záznamu do tabulky „sale_transaction“ a potvrzením jeho replikace.

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

To znamená úspěšnou konfiguraci obousměrné replikace ukázkových tabulek mezi MySQL a PostgreSQL databází. Zatímco konfiguraci replikace pro nově vytvořené uživatelské tabulky lze provést pomocí následujících kroků. Pro ukázku je vytvořena ukázková tabulka „t1“ a pravidla její replikace jsou nakonfigurována podle postupu níže. Kroky pouze konfigurují replikaci z corp-000 na 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)

Poté je konfigurace upozorněna na změnu schématu přidání nové tabulky vyvoláním příkazu symadmin s argumentem „sync-triggers“, který znovu vytvoří spouštěče, aby odpovídaly definicím tabulky. Následně spusťte příkaz „send-schema“ pro odeslání změn schématu do uzlu store-001, po kterém bude replikace tabulky „t1“ úspěšně nakonfigurována.

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

Výhody používání SymmetricDS

• Instalace a konfigurace bez námahy včetně předem nakonfigurované sady souborů parametrů pro vytvoření nastavení se 3 nebo 2 uzly
• Databáze pro různé platformy a nezávislá na platformě, včetně serverů, notebooků a mobilních zařízení
• Replikujte jakoukoli databázi do jakékoli jiné databáze, ať už on-prem, WAN nebo cloud
• Schopný optimálně zpracovávat několik databází až několik tisíc databází pro bezproblémovou replikaci dat
• Komerční verze softwaru nabízí konzolu pro správu řízenou grafickým uživatelským rozhraním s vynikajícím balíčkem podpory

Nevýhody používání SymmetricDS

• Ruční konfigurace příkazového řádku může zahrnovat definování pravidel a směru replikace pomocí příkazů SQL k načtení tabulek katalogu, což může být nepohodlné pro správu
• Nastavení velkého počtu tabulek pro replikaci bude vyčerpávající úsilí, pokud se nevyužije nějaká forma skriptování pro generování příkazů SQL definujících pravidla a směr replikace
• Soubor protokolu zaplňuje mnoho informací protokolování, což vyžaduje pravidelnou údržbu souboru protokolu, aby soubor protokolu nemohl zaplnit disk

Souhrn SymmetricDS

SymmetricDS nabízí možnost nastavit obousměrnou replikaci mezi 2 uzly, 3 uzly a tak dále pro několik tisíc uzlů pro replikaci dat a dosažení synchronizace souborů. Jedná se o unikátní nástroj, který provádí mnoho samoopravných úkolů údržby, jako je automatická obnova dat po delších odstávkách v uzlu, bezpečná a efektivní komunikace mezi uzly pomocí HTTPS a automatické řízení konfliktů na základě nastavených pravidel. , 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.