Перехресна реплікація між 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 і вище як джерело та 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
магазин-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