Крыжаваная рэплікацыя паміж PostgreSQL і MySQL

Я ў агульных рысах распавяду аб крыжаванай рэплікацыі паміж PostgreSQL і MySQL, а яшчэ аб метадах налады крыжаванай рэплікацыі паміж гэтымі двума серверамі базы дадзеных. Звычайна базы дадзеных у крыжаванай рэплікацыі называюцца аднастайнымі, і гэта зручны метад пераходу з аднаго сервера рэляцыйнай СКБД на іншы.

Базы дадзеных PostgreSQL і MySQL прынята лічыць рэляцыйнымі, але з дадатковымі пашырэннямі яны прапануюць магчымасці NoSQL. Тут мы абмяркуем рэплікацыю паміж PostgreSQL і MySQL, з пункту гледжання рэляцыйных СКБД.

Мы не будзем апісваць усю ўнутраную кухню, толькі базавыя прынцыпы, каб вы атрымалі ўяўленне аб наладзе рэплікацыі паміж серверамі баз дадзеных, перавагах, абмежаваннях і сцэнарах выкарыстання.

Звычайна рэплікацыя паміж двума ідэнтычнымі серверамі баз дадзеных выконваецца альбо ў двайковым рэжыме, альбо з дапамогай запытаў паміж кіроўным вузлом (ён жа выдавец, галоўны ці актыўны) і кіраваным (падпісчык, які чакае ці пасіўны). Мэта рэплікацыі - даць у рэальным часе копію галоўнай базы дадзеных на баку кіраванага. Пры гэтым дадзеныя перадаюцца ад кіроўнага да кіраванага, гэта значыць ад актыўнага да пасіўнага, таму што рэплікацыя выконваецца толькі ў адзін бок. Але можна наладзіць рэплікацыю паміж двума базамі дадзеных у абодва бакі, каб дадзеныя перадаваліся ад кіраванага да кіроўнага ў канфігурацыі «актыўны-актыўны». Усё гэта, у тым ліку каскадная рэплікацыя, магчыма паміж двума і больш ідэнтычнымі серверамі баз дадзеных. .

Апісаная канфігурацыя магчыма паміж рознымі серверамі баз дадзеных. Сервер можна наладзіць для прыёму рэплікаваных дадзеных з іншага сервера баз дадзеных і пры гэтым захоўваць здымкі рэплікаваных дадзеных у рэальным часе. MySQL і PostgreSQL прапануюць большасць з гэтых канфігурацый саматугам або з дапамогай іншых пашырэнняў, уключаючы метады двайковага часопіса, блакаванні дыска і метады на аснове аператараў і радкоў.

Крыжаваная рэплікацыя паміж MySQL і PostgreSQL патрэбна для аднаразовай міграцыі з аднаго сервера баз дадзеных на іншы. Гэтыя базы даных выкарыстоўваюць розныя пратаколы, таму звязаць іх напрамую не атрымаецца. Каб наладзіць абмен дадзенымі, можна выкарыстоўваць вонкавы апенсорс-інструмент, напрыклад pg_chameleon.

Што такое pg_chameleon

pg_chameleon - гэта сістэма рэплікацыі з MySQL у PostgreSQL на Python 3. У ёй выкарыстоўваецца опенсорс-бібліятэка mysql-replication, таксама на Python. Выявы радкоў здабываюцца з табліц MySQL і захоўваюцца як аб'екты JSONB у базе дадзеных PostgreSQL, а потым расшыфроўваюцца функцыяй pl/pgsql і прайграваюцца ў базе дадзеных PostgreSQL.

Магчымасці pg_chameleon

Некалькі схем MySQL з аднаго кластара можна рэплікаваць у адну мэтавую базу дадзеных PostgreSQL з канфігурацыяй "адзін да шматлікіх"
Імёны зыходнай і мэтавай схем не могуць супадаць.
Дадзеныя рэплікацыі можна атрымаць з каскаднай рэплікі MySQL.
Табліцы, якія не могуць рэпліцыравацца ці ствараюць памылкі, выключаюцца.
Кожнай функцыяй рэплікацыі кіруюць дэманы.
Кантроль з дапамогай параметраў і канфігурацыйных файлаў на базе YAML.

Прыклад

Хост
vm1
vm2

версія АС
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Версія сервера БД
MySQL 5.7.26
PostgreSQL 10.5

Порт БД
3306
5433

IP-адрас
192.168.56.102
192.168.56.106

Для пачатку падрыхтуйце ўсе неабходныя кампаненты для ўстаноўкі pg_chameleon. У гэтым прыкладзе ўсталяваны Python 3.6.8, які стварае віртуальнае асяроддзе і актывуе яго.

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

Пасля паспяховай усталёўкі Python3.6 трэба выканаць астатнія патрабаванні, напрыклад стварыць і актываваць віртуальнае асяроддзе. Акрамя таго, pip-модуль абнаўляецца да апошняй версіі і выкарыстоўваецца для ўстаноўкі pg_chameleon. У камандах ніжэй наўмысна усталёўваецца pg_chameleon 2.0.9, хоць апошняя версія - 2.0.10. Гэта трэба, каб пазбегнуць новых багаў у абноўленай версіі.

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

Затым мы выклікаем pg_chameleon (chameleon - гэта каманда) з аргументам set_configuration_files, каб уключыць pg_chameleon і стварыць каталогі і файлы канфігурацыі па змаўчанні.

(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

Цяпер мы ствараем копію config-example.yml як default.yml, каб ён стаў файлам канфігурацыі па змаўчанні. Узор файла канфігурацыі для гэтага прыкладу прыводзіцца ніжэй.

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

Файл канфігурацыі ў гэтым прыкладзе - гэта ўзор файла з pg_chameleon з малаважнымі зменамі ў адпаведнасці з зыходным і мэтавым асяроддзямі, і ніжэй прыводзіцца агляд розных частак файла канфігурацыі.

У файле канфігурацыі default.yml ёсць частка глабальных параметраў (global settings), дзе можна кіраваць такімі наладамі, як размяшчэнне файла блакавання, размяшчэнне логаў, перыяд захоўвання логаў і т. д. Далей ідзе падзел пераазначэння тыпаў (type override), дзе паказаны набор правіл для перавызначэння тыпаў падчас рэплікацыі. У прыкладзе па змаўчанні выкарыстоўваецца правіла пераазначэння тыпу, якое пераўтворыць tinyint(1) у лагічнае значэнне. У наступнай частцы паказваем дэталі падлучэння да мэтавай базы дадзеных. У нашым выпадку гэта база дадзеных PostgreSQL, пазначаная як pg_conn. У апошняй частцы паказваем дадзеныя крыніцы, гэта значыць параметры падлучэння зыходнай базы дадзеных, схему супастаўлення зыходнай і мэтавай баз дадзеных, табліцы, якія трэба прапусціць, час чакання, памяць, памер пакета. Заўважце, што "sources" паказана ў множным ліку, гэта значыць мы можам дадаць некалькі зыходных баз дадзеных для адной мэтавай, каб наладзіць канфігурацыю "многія да аднаго".

База дадзеных world_x у прыкладзе змяшчае 4 табліцы з радкамі, якія супольнасць MySQL прапануе для прыкладу. Яе можна загрузіць тут. Прыклад базы дадзеных пастаўляецца ў выглядзе tar і сціснутага архіва з інструкцыямі па стварэнню і імпарту радкоў.

У базах дадзеных MySQL і PostgreSQL ствараецца адмысловы карыстач з аднолькавым імем usr_replica. У MySQL яму падаюцца дадатковыя правы на чытанне ўсіх табліц, якія рэпліцыруюцца.

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;

На баку PostgreSQL ствараецца база дадзеных db_replica, якая будзе прымаць змены з базы дадзеных MySQL. Карыстальнік usr_replica ў PostgreSQL аўтаматычна наладжваецца як уладальнік двух схем pgworld_x і sch_chameleon, якія ўтрымоўваюць фактычныя рэплікаваныя табліцы і табліцы з каталогамі рэплікацыі адпаведна. За аўтаматычную канфігурацыю адказвае аргумент create_replica_schema, як вы ўбачыце ніжэй.

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

База дадзеных MySQL наладжваецца са зменамі некаторых параметраў, каб падрыхтаваць яе да рэплікацыі, як паказана ніжэй. Трэба будзе перазапусціць сервер баз дадзеных, каб змены ўступілі ў сілу.

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

Цяпер важна праверыць падлучэнне да абодвух сервераў баз дадзеных, каб пры выкананні каманд pg_chameleon не ўзнікла праблем.

На вузле PostgreSQL:

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

На вузле MySQL :

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

Наступныя тры каманды pg_chameleon (chameleon) падрыхтоўваюць асяроддзе, дадаюць крыніцу і ініцыялізуюць рэпліку. Аргумент create_replica_schema у pg_chameleon стварае схему па змаўчанні (sch_chameleon) і схему рэплікацыі (pgworld_x) у базе дадзеных PostgreSQL, як мы ўжо казалі. Аргумент add_source дадае зыходную базу дадзеных у канфігурацыю, счытваючы файл канфігурацыі (default.yml), і ў нашым выпадку гэта mysql, а init_replica ініцыалізуе канфігурацыю на аснове параметраў у файле канфігурацыі.

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

Выходныя дадзеныя гэтых трох каманд відавочна паказваюць на іх паспяховае выкананне. Усе збоі ці сінтаксічныя памылкі паказваюцца ў простых і зразумелых паведамленнях з падказкамі па выпраўленні праблем.

Нарэшце, запусцім рэплікацыю з дапамогай start_replica і атрымаем паведамленне аб паспяховым выкананні.

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

Статус рэплікацыі можна запытаць з дапамогай аргументу show_status, а прагледзець памылкі - з дапамогай аргументу show_errors.

Вынік.

Як мы ўжо казалі, кожнай функцыяй рэплікацыі кіруюць дэманы. Каб прагледзець іх, запытаем табліцу працэсаў камандай Linux ps, як паказана ніжэй.

Вынік.

Рэплікацыя не лічыцца настроенай, пакуль мы не пратэстуем яе ў рэальным часе, як паказана ніжэй. Мы ствараем табліцу, устаўляем пару запісаў у базу дадзеных MySQL і выкліканы аргумент sync_tables у pg_chameleon, каб абнавіць дэманы і рэплікаваць табліцу з запісамі ў базу дадзеных 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.

Каб пацвердзіць вынікі тэсту, запытваем табліцу з базы дадзеных PostgreSQL і выводны радкі.

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

Калі мы выконваем міграцыю, наступныя каманды pg_chameleon будуць яе канчаткам. Каманды трэба выконваць пасля таго, як мы пераканаемся, што радкі ўсіх мэтавых табліц былі рэплікаваны, а вынікам будзе акуратна перанесеная база дадзеных PostgreSQL без спасылак на зыходную базу дадзеных ці схему рэплікацыі (sch_chameleon).

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

Па жаданні наступнымі камандамі можна выдаліць зыходную канфігурацыю і схему рэплікацыі.

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

Перавагі pg_chameleon

Простая настройка і канфігурацыя.
Зручнае ўхіленне непаладак і выяўленне анамалій са зразумелымі паведамленнямі пра памылкі.
У рэплікацыю можна дадаць дадатковыя спецыяльныя табліцы пасля ініцыялізацыі, не мяняючы астатнюю канфігурацыю.
Можна наладзіць некалькі зыходных баз дадзеных для адной мэтавай, і гэта вельмі зручна, калі вы аб'ядноўваеце дадзеныя з адной або некалькіх баз дадзеных MySQL у адной базе дадзеных PostgreSQL.
Можна не рэплікаваць абраныя табліцы.

Недахопы pg_chameleon

Падтрымліваецца толькі з MySQL 5.5/9.5 і вышэй у якасці крыніцы і PostgreSQL XNUMX/XNUMX і вышэй у якасці мэтавай базы дадзеных.
У кожнай табліцы павінен быць першасны ці ўнікальны ключ, інакш табліцы ініцыялізуюцца падчас init_replica, але не рэпліцыруюцца.
Аднабаковая рэплікацыя - толькі з MySQL у PostgreSQL. Таму падыходзіць толькі для схемы "актыўны-пасіўны".
Зыходнай можа быць толькі база дадзеных MySQL, а падтрымка базы дадзеных PostgreSQL як крыніцы толькі эксперыментальная і з абмежаваннямі (даведайцеся больш тут)

Вынікі па pg_chameleon

Метад рэплікацыі ў pg_chameleon выдатна падыходзіць для міграцыі базы дадзеных з MySQL у PostgreSQL. Істотны мінус у тым, што рэплікацыя толькі аднабаковая, таму адмыслоўцы па базах дадзеных ці наўрад захочуць выкарыстаць яго для чагосьці, акрамя міграцыі. Але праблему аднабаковай рэплікацыі можна вырашыць яшчэ адным апенсорс-інструментам – SymmetricDS.

Падрабязней чытайце ў афіцыйнай дакументацыі тут. Даведку па камандным радку можна знайсці тут.

Агляд SymmetricDS

SymmetricDS - гэта апенсорс-інструмент, які рэплікуе любую базу дадзеных у любую іншую распаўсюджаную базу дадзеных: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird і іншыя хмарныя асобнікі БД, напрыклад Redshift, і Azure і т. д. Даступныя функцыі: сінхранізацыя баз дадзеных і файлаў, рэплікацыя некалькіх кіроўных баз дадзеных, фільтраваная сінхранізацыя, пераўтварэнне і іншыя. Гэта інструмент на Java, і патрабуецца стандартны выпуск JRE ці JDK (версіі 8.0 або вышэй). Тут можна запісваць змены дадзеных па трыгерам у зыходнай базе дадзеных і накіроўваць іх у адпаведную мэтавую базу дадзеных у выглядзе пакетаў.

Магчымасці SymmetricDS

Прылада не залежыць ад платформы, гэта значыць дзве ці некалькі розных БД могуць абменьвацца дадзенымі.
Рэляцыйныя БД сінхранізуюцца з дапамогай запісу змены дадзеных, а БД на аснове файлавых сістэм выкарыстоўваюць сінхранізацыю файлаў.
Двухбаковая рэплікацыя з выкарыстаннем метадаў Push і Pull на аснове набору правіл.
Перадача даных магчымая па абароненых сетках і сетках з нізкай прапускной здольнасцю.
Аўтаматычнае аднаўленне пры аднаўленні працы вузлоў пасля збою і аўтаматычнае вырашэнне канфліктаў.
Сумяшчальнасць з воблакам і эфектыўныя API пашырэнняў.

Прыклад

SymmetricDS можна наладзіць у адным з двух варыянтаў:
Вядучы (бацькоўскі) вузел, які цэнтралізавана каардынуе рэплікацыю дадзеных паміж двума вядзёнымі (даччынымі) вузламі, і абмен дадзенымі паміж даччынымі вузламі ажыццяўляецца толькі праз бацькоўскі.
Актыўны вузел (вузел 1) можа абменьвацца дадзенымі для рэплікацыі з іншым актыўным вузлом (вузел 2) без пасярэдніка.

У абодвух варыянтах абмен дадзенымі адбываецца з дапамогай Push і Pull. У гэтым прыкладзе мы разгледзім канфігурацыю "актыўны-актыўны". Апісваць усю архітэктуру занадта доўга, так што вывучыце кіраўніцтва, Каб даведацца больш аб прыладзе SymmetricDS.

Усталяваць SymmetricDS вельмі проста: загрузіце апенсорс-версію zip-файла адсюль і дастаньце яе, куды захочаце. У табліцы ніжэй прыводзяцца звесткі аб месцы ўсталёўкі і версіі SymmetricDS у гэтым прыкладзе, а таксама версіі баз дадзеных, версіі Linux, IP-адрасы і парты для абодвух вузлоў.

Хост
vm1
vm2

версія АС
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Версія сервера БД
MySQL 5.7.26
PostgreSQL 10.5

Порт БД
3306
5832

IP-адрас
192.168.1.107
192.168.1.112

Версія SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9

Шлях усталёўкі SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

Імя вузла SymmetricDS
corp-000
крама-001

Тут мы ўсталёўваны SymmetricDS у /usr/local/symmetric-server-3.9.20, і тут жа будуць захоўвацца розныя ўкладзеныя каталогі і файлы. Нас цікавяць укладзеныя каталогі samples і engines. У каталогу samples захоўваюцца прыклады файлаў канфігурацыі са ўласцівасцямі вузла, а таксама прыклады скрыптоў SQL для хуткага пачатку дэманстрацыі.

У каталогу samples бачым тры файла канфігурацыі са ўласцівасцямі вузла - імя паказвае характар ​​вузла ў вызначанай схеме.

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

У SymmetricDS ёсць усе неабходныя файлы канфігурацыі для базавай схемы з 3 вузлоў (варыянт 1), і тыя ж файлы можна выкарыстоўваць для схемы з 2 вузлоў (варыянт 2). Капіяваны патрэбны файл канфігурацыі з каталога samples у engines на хасце vm1. Атрымліваецца так:

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

Гэты вузел у канфігурацыі SymmetricDS завецца corp-000, а падлучэнне да базы дадзеных апрацоўваецца драйверам mysql jdbc, які выкарыстоўвае радок падлучэння, паказаны вышэй, і ўліковыя дадзеныя для ўваходу. Мы падключаемся да базы дадзеных replica_db, а падчас стварэння схемы будуць створаны табліцы. sync.url паказвае месца сувязі з вузлом для сінхранізацыі.

Вузел 2 на хасце vm2 наладжваецца як store-001, а астатняе паказана ў файле node.properties, які прыводзіцца ніжэй. Вузел store-001 выконвае базу дадзеных PostgreSQL, а pgdb_replica - гэта база дадзеных для рэплікацыі. registration.url дазваляе хасту vm2 звязацца з хастом vm1 і атрымаць ад яго дэталі канфігурацыі.

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

Гатовы прыклад SymmetricDS утрымоўвае параметры для налады двухбаковай рэплікацыі паміж двума серверамі базы дадзеных (двума вузламі). Прыведзеныя ніжэй крокі выконваюцца на хасце vm1 (corp-000), які створыць прыклад схемы з 4 табліцамі. Затым выкананне create-sym-tables камандай symadmin стварае табліцы каталогаў, дзе будуць захоўвацца правілы і кірунак рэплікацыі паміж вузламі. Нарэшце, у табліцы загружаецца прыклад даных.

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

У прыкладзе табліцы item і item_selling_price настроены аўтаматычна для рэплікацыі з corp-000 у store-001, а табліцы sale (sale_transaction і sale_return_line_item) аўтаматычна настроены для рэплікацыі з store-001 у corp-000. Цяпер ствараем схему ў базе дадзеных PostgreSQL на хасце vm2 (store-001), каб падрыхтаваць яе да прыёму дадзеных ад corp-000.

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

Абавязкова правяраем, што ў базе дадзеных MySQL на vm1 ёсць прыклады табліц і табліцы каталогаў SymmetricDS. Заўважце, што сістэмныя табліцы SymmetricDS (з прэфіксам sym_) зараз даступныя толькі на вузле corp-000, таму што тамака мы выканалі каманду create-sym-tables і будзем кіраваць рэплікацыяй. А яшчэ ў базе дадзеных на вузле store-001 будзе ўсяго 4 табліцы прыкладу без дадзеных.

Усё. Серада гатова для запуску серверных працэсаў sym на абодвух вузлах, як паказана ніжэй.

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

Запісы логаў адпраўляюцца ў файл фонавага лога (symmetric.log) у тэчцы логаў у каталогу, дзе ўсталяваны SymmetricDS, а таксама ў стандартныя выходныя дадзеныя. Сервер sym зараз можна ініцыяваць на вузле store-001.

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

Калі запусціць серверны працэс sym на хасце vm2, ён створыць табліцы каталога SymmetricDS яшчэ і ў базе дадзеных PostgreSQL. Калі запусціць серверны працэс sym на абодвух вузлах, яны скаардынуюцца сябар з сябрам, каб рэплікаваць дадзеныя з corp-000 на store-001. Калі праз некалькі секунд мы запытаем усе 4 табліцы па абодва бакі, то ўбачым, што рэплікацыя выканана паспяхова. Ці можна адправіць пачатковую загрузку на вузел store-001 з corp-000 наступнай камандай.

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

На гэтым этапе ў табліцу item у базе дадзеных MySQL на вузле corp-000 (хост: vm1) устаўляецца новы запіс, і можна праверыць яе рэплікацыю ў базу дадзеных PostgreSQL на вузле store-001 (хост: vm2). Мы бачым аперацыю Pull для перамяшчэння даных з corp-000 у store-001.

mysql> insert into item values ('22000002','Jelly Bean');
Query OK, 1 row affected (0.00 sec)

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

Каб выканаць аперацыю Push для перасоўвання дадзеных са store-001 у corp-000, устаўляемы запіс у табліцу sale_transaction і правяраем, што рэплікацыя выканана.

Вынік.

Мы бачым паспяховую настройку двухбаковай рэплікацыі табліц прыкладу паміж базамі дадзеных MySQL і PostgreSQL. Каб наладзіць рэплікацыю для новых карыстацкіх табліц, выконваем наступныя дзеянні. Ствараем табліцу t1 для прыкладу і наладжваем правілы яе рэплікацыі наступным чынам. Так мы наладжваем толькі рэплікацыю з corp-000 у 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)

Затым канфігурацыя атрымлівае апавяшчэнне аб змене схемы, гэта значыць даданні новай табліцы, з дапамогай каманды symadmin з аргументам sync-triggers, які ўзнаўляе трыгеры для супастаўлення азначэнняў табліц. Выконваецца send-schema для адпраўкі змен схемы на вузел store-001, і рэплікацыя табліцы t1 наладжаная.

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

Перавагі SymmetricDS

Простая ўстаноўка і канфігурацыя, у тым ліку гатовы набор файлаў з параметрамі для стварэння схемы з трыма або двума вузламі.
Кросплатформеннасць баз даных і незалежнасць ад платформы, уключаючы серверы, ноўтбукі і мабільныя прылады.
Рэплікацыя любой базы дадзеных у любую іншую базу дадзеных лакальна, у WAN ці ў воблаку.
Магчымасць аптымальнай працы з парай баз даных або некалькімі тысячамі для зручнай рэплікацыі.
Платная версія з графічным інтэрфейсам і выдатнай падтрымкай.

Недахопы SymmetricDS

Трэба ўручную вызначаць у камандным радку правілы і кірунак рэплікацыі праз аператары SQL для загрузкі табліц каталогаў, што бывае няёмка.
Наладжваць шмат табліц для рэплікацыі бывае стомна, калі не выкарыстоўваць скрыпты для стварэння аператараў SQL, якія вызначаюць правілы і кірунак рэплікацыі.
У логі заносіцца занадта шмат інфармацыі, і часам трэба наводзіць парадак у файле лога, каб ён не займаў занадта шмат месца.

Вынікі па SymmetricDS

SymmetricDS дазваляе наладжваць двухбаковую рэплікацыю паміж двума, трыма і нават некалькімі тысячамі вузлоў, каб выконваць рэплікацыю і сінхранізаваць файлы. Гэта ўнікальная прылада, які самастойна выконвае шматлікія задачы, напрыклад аўтаматычнае ўзнаўленне дадзеных пасля працяглага прастою на вузле, абаронены і эфектыўны абмен дадзенымі паміж вузламі па HTTPS, аўтаматычнае кіраванне канфліктамі на аснове набору правіл і т. д. SymmetricDS выконвае рэплікацыю паміж любымі базамі дадзеных, таму яго можна выкарыстоўваць для самых розных сцэнараў, у тым ліку міграцыю, пераход на новую версію, распаўсюджванне, фільтраванне і пераўтварэнне дадзеных на розных платформах.

Прыклад створаны на аснове афіцыйнага кароткага кіраўніцтва па SymmetricDS. У кіраўніцтве карыстальніка падрабязна апісваюцца розныя паняцці, звязаныя з настройкай рэплікацыі з дапамогай SymmetricDS.

Крыніца: habr.com