Вкрстена репликација помеѓу PostgreSQL и MySQL

Ќе наведам вкрстена репликација помеѓу PostgreSQL и MySQL, како и методи за поставување вкрстена репликација помеѓу двата сервери на бази на податоци. Вообичаено, вкрстено реплицираните бази на податоци се нарекуваат хомогени и тоа е пригоден метод за преместување од еден сервер RDBMS на друг.

Базите на податоци PostgreSQL и MySQL генерално се сметаат за релациони, но со дополнителни екстензии тие нудат NoSQL способности. Овде ќе разговараме за репликација помеѓу PostgreSQL и MySQL од релациона DBMS перспектива.

Нема да ја опишеме целата внатрешна работа, туку само основните принципи за да добиете идеја за конфигурирање на репликација помеѓу серверите на бази на податоци, предностите, ограничувањата и случаите на употреба.

Вообичаено, репликацијата помеѓу два идентични сервери на бази на податоци се врши или во бинарен режим или со користење на прашања помеѓу главен (познат како издавач, главен или активен) и slave (претплатник, подготвеност или пасивен). Целта на репликацијата е да се обезбеди копија во реално време од основната база на податоци на slave страната. Во овој случај, податоците се пренесуваат од господар на роб, односно од активен во пасивен, бидејќи репликацијата се изведува само во една насока. Но, можете да поставите репликација помеѓу две бази на податоци во двете насоки, така што податоците се пренесуваат од slave во master во активно-активна конфигурација. Сето ова, вклучително и каскадната репликација, е можно помеѓу два или повеќе идентични сервери на базата на податоци Активно-активна или активно-пасивна конфигурација зависи од потребата, достапноста на таквите можности во почетната конфигурација или употребата на надворешни конфигурациски решенија и постоечките компромиси.

Опишаната конфигурација е можна помеѓу различни сервери за бази на податоци. Серверот може да се конфигурира да прифаќа реплицирани податоци од друг сервер за бази на податоци и сепак да одржува снимки од реплицираните податоци во реално време. MySQL и PostgreSQL ги нудат повеќето од овие конфигурации внатрешно или преку екстензии од трети страни, вклучувајќи методи на бинарни дневници, заклучување на диск и методи базирани на изјави и редови.

Потребна е вкрстена репликација помеѓу MySQL и PostgreSQL за еднократна миграција од еден сервер на база на податоци на друг. Овие бази на податоци користат различни протоколи, така што не е можно директно да се поврзат. За да воспоставите размена на податоци, можете да користите надворешна алатка со отворен код, на пример pg_chameleon.

Што е pg_chameleon

pg_chameleon е систем за репликација од MySQL до PostgreSQL во Python 3. Ја користи библиотеката со отворен код mysql-репликација, исто така во 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

Верзија на DB сервер
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 (камелеонот е команда) со аргументот 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 заедницата ги нуди како примери. Може да се преземе тука. Примерокот за база на податоци доаѓа како катран и компресирана архива со инструкции за креирање и увоз на редови.

Во базите на податоци 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 (камелеон) ја подготвуваат околината, го додаваат изворот и ја иницијализираат репликата. Аргументот 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 и други примероци на база на податоци во облак, на пр 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

Верзија на DB сервер
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 и таму ќе се складираат разни поддиректориуми и датотеки. Заинтересирани сме за поддиректориумите на примероци и мотори. Директориумот со примероци содржи примери за конфигурациски датотеки со својства на јазли, како и примери на 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

Овој јазол во конфигурацијата SymmetricDS се нарекува corp-000, а врската со базата на податоци ја управува двигателот mysql jdbc, кој ја користи низата за поврзување погоре и ингеренциите за најавување. Се поврзуваме со базата на податоци replica_db и табелите ќе се креираат при креирањето на шемата. sync.url покажува каде да се контактира јазолот за синхронизација.

Јазолот 2 на хостот vm2 е конфигуриран како store-001, а остатокот е наведен во датотеката node.properties подолу. Node store-001 ја извршува базата на податоци PostgreSQL, а pgdb_replica е базата на податоци за репликација. register.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_selling_price автоматски се конфигурираат да се реплицираат од corp-000 во store-001, а табелите за продажба (sale_transaction и sale_return_line_item) автоматски се конфигурираат да се реплицираат од store-001 до corp-000. Сега создаваме шема во базата на податоци PostgreSQL на хост vm2 (store-001) за да ја подготвиме да прима податоци од corp-000.

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xml

Проверете дали базата на податоци на MySQL на vm1 има табели за примери и табели со каталог SymmetricDS. Забележете дека системските табели на SymmetricDS (со префикс sym_) моментално се достапни само на јазол corp-000 бидејќи таму ја извршивме командата create-sym-tables и ќе управуваме со репликацијата. И во базата на податоци на node store-001 ќе има само 4 примерни табели без податоци.

Сите. Околината е подготвена да ги извршува процесите на sym-серверот на двата јазли како што е прикажано подолу.

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &

Записите во дневникот се испраќаат до датотеката за евиденција во заднина (symmetric.log) во папката логови во директориумот каде што е инсталиран SymmetricDS, како и до стандардниот излез. Sym-серверот сега може да се иницира на node 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 до node store-001 од corp-000 со следнава команда.

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

Во овој момент, нов запис е вметнат во табелата со ставки во базата на податоци MySQL на јазол corp-000 (домаќин: vm1), и можете да ја проверите неговата репликација во базата на податоци PostgreSQL на јазол продавница-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 се извршува за да се испратат промените на шемата во јазол продавница-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. ВО Упатство за користење Детално ги опишува различните концепти вклучени во поставувањето на репликацијата со SymmetricDS.

Извор: www.habr.com