Косместна репликация между 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
създаване на директория /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 има раздел за глобални параметри, където можете да управлявате настройки като местоположение на файл за заключване, местоположение на логовете, период на съхранение на логовете и др. Следва раздел за замяна на типове, в който е посочен набор от правила за замяна на типовете по време на репликацията. В примера по подразбиране се използва правило за замяна на типа, което преобразува 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));
Запитване OK, 0 реда засегнати (0.01 сек)
mysql> insert into t1 values (1,'one');
Запитване OK, 1 ред засегнат (0.00 сек)
mysql> insert into t1 values (2,'two');
Запитване OK, 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