Кръстосана репликация между 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

След успешната инсталация на Python 3.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
създаване на директория /root/.pg_chameleon
създаване на директория /root/.pg_chameleon/configuration/
създаване на директория /root/.pg_chameleon/logs/
създаване на директория /root/.pg_chameleon/pid/
копиране на конфигурационния пример в /root/.pg_chameleon/configuration//config-example.yml

Сега създаваме копие на config-example.yml като default.yml, за да стане файлът за конфигурация по подразбиране. Примерен файл за конфигурация за този пример е предоставен по-долу.

$> cat default.yml
---
#глобални настройки
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 позволява на потребителя да преодолява стандартното преобразуване на тип в различен.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

#postgres  целева връзка
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 #пропуска вмъквания в таблицата delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #пропуска изтривания в схемата 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: Стартиране на процеса на репликация за източник mysql

Статусът на репликацията може да бъде запитан с параметъра show_status, а грешките могат да се прегледат с параметъра show_errors.

Резултат.

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

Резултат.

Репликацията не се счита за настроена, докато не я тестваме в реално време, както е показано по-долу. Създаваме таблица, вставяме няколко записа в базата данни MySQL и извикваме параметъра sync_tables в pg_chameleon, за да обновим демоните и репликираме таблицата с записите в базата данни PostgreSQL.

mysql> create table t1 (n1 int primary key, n2 varchar(10));
Запитването е ОК, 0 реда засегнати (0.01 сек)
mysql> insert into t1 values (1,'one');
Запитването е ОК, 1 ред засегнат (0.00 сек)
mysql> insert into t1 values (2,'two');
Запитването е ОК, 1 ред засегнат (0.00 сек)

$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Процесът на синхронизация на таблиците за източник mysql стартира.

За да потвърдим резултатите от теста, ще запитаме таблицата от базата данни 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 и по-висока версия като източник и 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 и изисква стандартно издание на 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
store-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