Преглед на кръстосаната репликация на PostgreSQL и MySQL

Този блог има за цел да обясни преглед на кръстосаната репликация между PostgreSQL и MySQL и допълнително да обсъди методите за конфигуриране на кръстосана репликация между двата сървъра на бази данни. Традиционно базите данни, участващи в настройката за кръстосана репликация, се наричат ​​хетерогенни бази данни, което е добър подход за преминаване от един RDBMS сървър към друг.

И двете бази данни PostgreSQL и MySQL са конвенционални RDBMS бази данни, но те също така предлагат NoSQL възможности с добавени разширения, за да имат най-доброто от двата свята. Тази статия се фокусира върху обсъждането на репликацията между PostgreSQL и MySQL от гледна точка на RDBMS.

Изчерпателно обяснение за вътрешните елементи на репликацията не е в обхвата на този блог, но някои основни елементи ще бъдат обсъдени, за да се даде на аудиторията разбиране за това как е конфигурирана репликацията между сървърите на бази данни, предимствата, ограниченията и може би някои известни случаи на употреба.

Като цяло репликацията между два идентични сървъра на база данни се постига или в двоичен режим, или в режим на заявка между главен възел (наричан иначе издател, първичен или активен) и подчинен възел (абонат, резервен или пасивен). Целта на репликацията е да осигури копие в реално време на главната база данни от страна на подчинената, където данните се прехвърлят от главен към подчинен, като по този начин се образува активно-пасивна настройка, тъй като репликацията е конфигурирана да се извършва само по един начин. От друга страна, репликацията между две бази данни може да бъде конфигурирана и в двете посоки, така че данните също да могат да се прехвърлят от подчинен обратно към главен, установявайки активна-активна конфигурация. Всичко това може да бъде конфигурирано между два или повече идентични сървъри на бази данни, които могат също да включват каскадна репликация. Конфигурацията активен-активен или активен-пасивен наистина зависи от бизнес нуждите, наличието на такива функции в собствената конфигурация или използването на външни решения за конфигуриране и приложимите компромиси.

Посочената по-горе конфигурация може да се осъществи с различни сървъри на база данни, като сървърът на база данни може да бъде конфигуриран да приема репликирани данни от друг напълно различен сървър на база данни и все пак да поддържа моментна снимка в реално време на данните, които се реплицират. И двете сървъри на база данни 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 конструкция

Демо

За начало подгответе настройката с всички предпоставки, необходими за инсталиране на 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 има раздел „глобални настройки“, който контролира подробности като местоположение на заключващия файл, места за регистриране и период на запазване и т.н. Следващият раздел е разделът „отмяна на типа“, който представлява набор от правила за отмяна типове по време на репликация. По подразбиране се използва правило за отмяна на типа пример, което преобразува tinyint(1) в булева стойност. Следващият раздел е секцията с подробности за връзката на дестинацията с база данни, която в нашия случай е PostgreSQL база данни, обозначена с „pg_conn“. Последният раздел е секцията източник, която съдържа всички подробности за настройките за връзка с базата данни източник, картографиране на схемата между източник и местоназначение, всякакви таблици за пропускане, включително настройки за изчакване, памет и размер на партидата. Обърнете внимание на „източниците“, които означават, че може да има множество източници към една дестинация, за да се формира настройка за репликация много към едно.

В тази демонстрация се използва база данни „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 се създава база данни, която ще приема промени от MySQL база данни, която е наречена „db_replica“. Потребителят „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 (хамелеон) са мястото, където настройва средата, добавя източник и инициализира реплика. Аргументът „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“.

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

Както беше обсъдено по-рано, всяка от функциите за репликация се управлява с помощта на демони, които могат да се видят чрез запитване на таблицата на процесите с помощта на командата „ps“ на Linux, показана по-долу.

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

Нито една настройка на репликацията не е завършена, докато не бъде поставена на теста „прилагане в реално време“, който е симулиран, както е показано по-долу. Това включва създаване на таблица и вмъкване на няколко записа в базата данни 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

• Лесна за настройка и по-малко сложна конфигурация
• Безболезнено отстраняване на неизправности и откриване на аномалии с лесен за разбиране изход за грешки
• Допълнителни adhoc таблици могат да бъдат добавени към репликацията след инициализация, без да се променя каквато и да е друга конфигурация
• Много източника могат да бъдат конфигурирани за една база данни местоназначение, което е полезно при проекти за консолидация за обединяване на данни от една или повече бази данни на MySQL в една база данни PostgreSQL.
• Избраните таблици могат да бъдат пропуснати от репликиране

Недостатъци от използването на pg_chameleon

• Поддържа се само от MySQL 5.5 нагоре като база данни Origin и PostgreSQL 9.5 нататък за база данни местоназначение
• Изисква всяка таблица да има първичен или уникален ключ, в противен случай таблиците се инициализират по време на процеса 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, като се изисква стандартно издание (версия 8.0 или по-нова) на JRE или JDK. Функционалността включва промени в данните, които се улавят от тригери в базата данни източник и ги насочват към участваща дестинационна база данни като изходящи пакети

Характеристики на SymmetricDS

• Независими от платформата, което означава, че две или повече различни бази данни могат да комуникират една с друга, всяка база данни с всяка друга база данни
• Релационните бази данни постигат синхронизация, използвайки улавяне на данни за промяна, докато системите, базирани на файлова система, използват синхронизиране на файлове
• Двупосочна репликация с помощта на метод Push and Pull, който се постига въз основа на зададени правила
• Прехвърлянето на данни може да се извършва и през защитени мрежи с ниска честотна лента
• Автоматично възстановяване по време на възобновяване на повреден възел и автоматично разрешаване на конфликти
• Подготвен за облак и съдържа мощни API за разширения

Демо

SymmetricDS може да бъде конфигуриран в една от двете опции:

• Главен (родителски) възел, който действа като централизиран посредник, координиращ репликацията на данни между два подчинени (подчинени) възела, в който комуникацията между двата дъщерни възела може да се осъществява само чрез родителския.
• Един активен възел (възел 1) може да се репликира към и от друг активен възел (възел 2) без никакъв посредник.

И в двете опции комуникацията между възлите се осъществява чрез събития „Push“ и „Pull“. В тази демонстрация ще бъде обяснена активна-активна конфигурация между два възела. Пълната архитектура може да бъде изчерпателна, така че читателите се насърчават да проверят ръководството за потребителя, достъпно тук, за да научат повече за вътрешните елементи на SymmetricDS.

Инсталирането на SymmetricDS е толкова просто, колкото да изтеглите версията на zip файл с отворен код от тук и да го извлечете на удобно място. Подробностите за местоположението на инсталиране и версията на SymmetricDS в тази демонстрация са съгласно таблицата по-долу, заедно с други подробности, отнасящи се до версиите на базата данни, версиите на Linux, ip адресите и комуникационния порт за двата участващи възли.

Началото за инсталиране в този случай е “/usr/local/symmetric-server-3.9.20”, което ще бъде началната директория на SymmetricDS, която съдържа различни други поддиректории и файлове. Две от поддиректориите, които са важни сега, са „проби“ и „двигатели“. Директорията с примери съдържа примерни конфигурационни файлове със свойства на възел в допълнение към примерните SQL скриптове за стартиране на бърза демонстрация.

Следните три конфигурационни файла със свойства на възел могат да се видят в директорията „проби“ с имена, указващи естеството на възела в дадена настройка.

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

На този етап е важно да се провери съществуването на демонстрационни таблици и каталожни таблици на SymmetricDS в базата данни MySQL на vm1. Забележете, системните таблици на 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. След няколко секунди, запитването на всички четири таблици от двете страни ще покаже успешните резултати от репликация. Като алтернатива може да се изпрати и първоначално натоварване до възела store-001 от corp-000 с командата по-долу.

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

В този момент нов запис се вмъква в таблицата „item” в базата данни на MySQL на възел corp-000 (хост:vm1) и може да се провери дали е репликиран успешно в базата данни PostgreSQL на възел store-001 (хост:vm2 ). Това показва събитието „Издърпване“ на данни от 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“ и потвърждаването му за репликиране.

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

Това бележи успешната конфигурация на двупосочна репликация на демонстрационни таблици между 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

• Без усилие инсталиране и конфигуриране, включително предварително конфигуриран набор от файлове с параметри за изграждане на настройка с 3 или 2 възела
• Разрешена база данни за различни платформи и независима от платформата, включително сървъри, лаптопи и мобилни устройства
• Репликирайте всяка база данни във всяка друга база данни, независимо дали е локална, WAN или облачна
• В състояние оптимално да обработва няколко бази данни до няколко хиляди бази данни, за да репликира данните безпроблемно
• Комерсиална версия на софтуера предлага управлявана от GUI конзола за управление с отличен пакет за поддръжка

Недостатъци от използването на SymmetricDS

• Ръчната конфигурация на командния ред може да включва дефиниране на правила и посока на репликация чрез SQL изрази за зареждане на каталожни таблици, което може да е неудобно за управление
• Създаването на голям брой таблици за репликация ще бъде изчерпателно усилие, освен ако не се използва някаква форма на скриптове за генериране на SQL изрази, определящи правила и посока на репликация
• Изобилие от информация за регистриране претрупва регистрационния файл, като по този начин изисква периодична поддръжка на регистрационния файл, за да не позволи на регистрационния файл да запълни диска

Резюме на SymmetricDS

SymmetricDS предлага възможност за настройка на двупосочна репликация между 2 възела, 3 възела и т.н. за няколко хиляди възли за репликиране на данни и постигане на синхронизация на файлове. Това е уникален инструмент, който изпълнява много от задачите за самовъзстановяване на поддръжка, като автоматично възстановяване на данни след продължителни периоди на престой във възел, сигурна и ефективна комуникация между възли с помощта на HTTPS и автоматично управление на конфликти въз основа на зададени правила , 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.