Кръстосана репликация между PostgreSQL и MySQL

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

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

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

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

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

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

Базата данни world_x в примера съдържа 4 таблици с редове, които MySQL общността предлага за примера. Може да се изтегли тук. Примерната база данни идва като tar и компресиран архив с инструкции за създаване и импортиране на низове.

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

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

DB порт
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
корп-000
магазин-001

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

В директорията с примери виждаме три конфигурационни файла със свойства на възела - името показва естеството на възела в определена схема.

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

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

Този възел се нарича corp-000 в конфигурацията на SymmetricDS и връзката с базата данни се управлява от драйвера 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 server и на двата възела, както е показано по-долу.

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

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

В този момент нов запис се вмъква в таблицата с елементи в 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 или в облака.
Възможност за оптимална работа с няколко бази данни или няколко хиляди за лесно репликиране.
Платена версия с GUI и отлична поддръжка.

Недостатъци на SymmetricDS

Трябва ръчно да дефинирате правилата и посоката на репликация в командния ред чрез SQL изрази, за да заредите каталожните таблици, което може да бъде неудобно.
Настройването на много таблици за репликация може да бъде досадно, освен ако не използвате скриптове за създаване на SQL изрази, които определят правилата и посоката на репликация.
В регистрационните файлове има твърде много информация и понякога трябва да почистите регистрационния файл, така че да не заема твърде много място.

Резюме на SymmetricDS

SymmetricDS ви позволява да настроите двупосочна репликация между два, три или дори няколко хиляди възела, за да репликирате и синхронизирате файлове. Това е уникален инструмент, който изпълнява много задачи самостоятелно, като автоматично възстановяване на данни след дълъг престой на възел, сигурна и ефективна комуникация между възли през HTTPS, автоматично управление на конфликти въз основа на набор от правила и др. SymmetricDS репликира между всякакви бази данни, следователно може да се използва за голямо разнообразие от сценарии, включително миграция, надграждане, разпространение, филтриране и трансформация на данни между платформи.

Примерът е базиран на официалния бързо ръководство от SymmetricDS. IN ръководство за употреба Описва подробно различните концепции, включени в настройката на репликация със SymmetricDS.

Източник: www.habr.com