Replikacja krzyżowa pomiędzy PostgreSQL i MySQL

Opiszę replikację krzyżową pomiędzy PostgreSQL i MySQL, a także metody konfigurowania replikacji krzyżowej pomiędzy dwoma serwerami baz danych. Zwykle replikowane bazy danych nazywane są jednorodnymi i jest to wygodna metoda przenoszenia z jednego serwera RDBMS na drugi.

Bazy danych PostgreSQL i MySQL są ogólnie uważane za relacyjne, ale z dodatkowymi rozszerzeniami oferują możliwości NoSQL. Tutaj omówimy replikację pomiędzy PostgreSQL i MySQL z perspektywy relacyjnego systemu DBMS.

Nie będziemy opisywać całego wewnętrznego działania, tylko podstawowe zasady, abyś miał pojęcie o konfiguracji replikacji pomiędzy serwerami baz danych, zaletach, ograniczeniach i przypadkach użycia.

Zazwyczaj replikacja między dwoma identycznymi serwerami baz danych odbywa się w trybie binarnym lub przy użyciu zapytań między serwerem głównym (czyli wydawcą, serwerem głównym lub aktywnym) a serwerem podrzędnym (abonentem, w trybie gotowości lub pasywnym). Celem replikacji jest zapewnienie kopii w czasie rzeczywistym głównej bazy danych po stronie urządzenia podrzędnego. W tym przypadku dane przesyłane są z mastera na slave, czyli z aktywnego na pasywny, ponieważ replikacja odbywa się tylko w jednym kierunku. Można jednak skonfigurować replikację pomiędzy dwiema bazami danych w obu kierunkach, tak aby dane były przesyłane z urządzenia slave do urządzenia master w konfiguracji aktywny-aktywny. Wszystko to, łącznie z replikacją kaskadową, jest możliwe pomiędzy dwoma lub większą liczbą identycznych serwerów baz danych.Konfiguracja typu aktywny-aktywny lub aktywny-pasywny zależy od potrzeb, dostępności takich możliwości w początkowej konfiguracji lub wykorzystania zewnętrznych rozwiązań konfiguracyjnych i istniejących kompromisów.

Opisana konfiguracja jest możliwa pomiędzy różnymi serwerami baz danych. Serwer można skonfigurować tak, aby akceptował replikowane dane z innego serwera bazy danych i nadal utrzymywał migawki replikowanych danych w czasie rzeczywistym. MySQL i PostgreSQL oferują większość tych konfiguracji we własnym zakresie lub za pośrednictwem rozszerzeń innych firm, w tym metody dziennika binarnego, blokowanie dysku oraz metody oparte na instrukcjach i wierszach.

Do jednorazowej migracji z jednego serwera bazy danych na inny wymagana jest replikacja krzyżowa pomiędzy MySQL i PostgreSQL. Te bazy danych korzystają z różnych protokołów, więc nie jest możliwe ich bezpośrednie powiązanie. Aby nawiązać wymianę danych, można skorzystać z zewnętrznego narzędzia typu open source, np. pg_chameleon.

Co to jest pg_chameleon

pg_chameleon to system replikacji z MySQL do PostgreSQL w Pythonie 3. Wykorzystuje bibliotekę mysql-replication typu open source, również w Pythonie. Obrazy wierszy są wyodrębniane z tabel MySQL i przechowywane jako obiekty JSONB w bazie danych PostgreSQL, a następnie odszyfrowywane za pomocą funkcji pl/pgsql i odtwarzane w bazie danych PostgreSQL.

Funkcje pg_chameleon

Wiele schematów MySQL z tego samego klastra można replikować do pojedynczej docelowej bazy danych PostgreSQL w konfiguracji „jeden do wielu”
Nazwy schematu źródłowego i docelowego nie mogą być takie same.
Dane replikacji można pobrać z kaskadowej repliki MySQL.
Tabele, które nie mogą się replikować lub powodować błędów, są wykluczone.
Każda funkcja replikacji jest kontrolowana przez demony.
Sterowanie za pomocą parametrów i plików konfiguracyjnych opartych na YAML.

Przykład

Gospodarz
vm1
vm2

Wersja systemu operacyjnego
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Wersja serwera DB
MySQL 5.7.26
PostgreSQL 10.5

portu DB
3306
5433

Adres IP
192.168.56.102
192.168.56.106

Na początek przygotuj wszystkie niezbędne komponenty do instalacji pg_chameleon. W tym przykładzie instalowany jest język Python 3.6.8, który tworzy i aktywuje środowisko wirtualne.

$> 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

Po pomyślnej instalacji Pythona 3.6 musisz spełnić pozostałe wymagania, takie jak utworzenie i aktywacja środowiska wirtualnego. Dodatkowo moduł pip jest aktualizowany do najnowszej wersji i używany do instalacji pg_chameleon. Poniższe polecenia celowo instalują pg_chameleon 2.0.9, chociaż najnowsza wersja to 2.0.10. Jest to konieczne, aby uniknąć nowych błędów w zaktualizowanej wersji.

$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9

Następnie wywołujemy pg_chameleon (kameleon jest poleceniem) z argumentem set_configuration_files, aby włączyć pg_chameleon i utworzyć domyślne katalogi i pliki konfiguracyjne.

(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

Teraz tworzymy kopię config-example.yml jako default.yml, aby stał się domyślnym plikiem konfiguracyjnym. Przykładowy plik konfiguracyjny dla tego przykładu znajduje się poniżej.

$> 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:

Plik konfiguracyjny w tym przykładzie to przykładowy plik pg_chameleon z niewielkimi modyfikacjami dostosowanymi do środowiska źródłowego i docelowego. Poniżej znajduje się przegląd różnych sekcji pliku konfiguracyjnego.

W pliku konfiguracyjnym default.yml znajduje się sekcja ustawień globalnych, w której możesz zarządzać ustawieniami takimi jak lokalizacja pliku blokady, lokalizacja logów, okres przechowywania logów itp. Następnie następuje sekcja override typu, w której zestaw reguł zastępowania typów podczas replikacji. Przykład domyślnie przedstawia regułę przesłaniania typu, która konwertuje tinyint(1) na wartość logiczną. W kolejnej sekcji określamy szczegóły połączenia z docelową bazą danych. W naszym przypadku jest to baza danych PostgreSQL oznaczona jako pg_conn. W ostatniej sekcji wskazujemy dane źródłowe, czyli parametry połączenia źródłowej bazy danych, schemat mapowania pomiędzy bazą źródłową i docelową, tabele, które należy pominąć, czas oczekiwania, pamięć, wielkość pakietu. Należy pamiętać, że „źródła” to liczba mnoga, co oznacza, że ​​możemy dodać wiele źródłowych baz danych do pojedynczej docelowej bazy danych, aby skonfigurować konfigurację „wiele do jednego”.

Przykładowa baza danych world_x zawiera 4 tabele z wierszami, które społeczność MySQL podaje jako przykłady. Można go pobrać tutaj. Przykładowa baza danych ma postać spakowanego archiwum tar i zawiera instrukcje dotyczące tworzenia i importowania wierszy.

W bazach danych MySQL i PostgreSQL tworzony jest specjalny użytkownik o tej samej nazwie usr_replica. W MySQL nadawane są dodatkowe prawa odczytu do wszystkich replikowanych tabel.

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;

Po stronie PostgreSQL tworzona jest baza danych db_replica, która akceptuje zmiany z bazy MySQL. Użytkownik usr_replica w PostgreSQL jest automatycznie konfigurowany jako właściciel dwóch schematów, pgworld_x i sch_chameleon, które zawierają odpowiednio rzeczywiste zreplikowane tabele i tabele katalogu replikacji. Argument create_replica_schema odpowiada za automatyczną konfigurację, co zobaczysz poniżej.

postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASE

Baza danych MySQL jest skonfigurowana z pewnymi zmianami parametrów w celu przygotowania jej do replikacji, jak pokazano poniżej. Aby zmiany zaczęły obowiązywać, konieczne będzie ponowne uruchomienie serwera bazy danych.

$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1

Teraz ważne jest sprawdzenie połączenia z obydwoma serwerami baz danych, aby nie było problemów przy uruchamianiu poleceń pg_chameleon.

W węźle PostgreSQL:

$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x

W węźle MySQL:

$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica

Następne trzy polecenia pg_chameleon (kameleon) przygotowują środowisko, dodają źródło i inicjują replikę. Argument create_replica_schema funkcji pg_chameleon tworzy domyślny schemat (sch_chameleon) i schemat replikacji (pgworld_x) w bazie danych PostgreSQL, jak już omówiliśmy. Argument add_source dodaje do konfiguracji źródłową bazę danych poprzez odczytanie pliku konfiguracyjnego (default.yml), w naszym przypadku jest to mysql, a init_replica inicjuje konfigurację w oparciu o parametry z pliku konfiguracyjnego.

$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debug

Dane wyjściowe tych trzech poleceń wyraźnie wskazują, że zostały one wykonane pomyślnie. Wszelkie awarie lub błędy składniowe są zgłaszane w prostych, przejrzystych komunikatach ze wskazówkami, jak rozwiązać problem.

Na koniec rozpoczynamy replikację za pomocą start_replica i otrzymujemy komunikat o powodzeniu.

$> chameleon start_replica --config default --source mysql 
output: Starting the replica process for source mysql

O stan replikacji można zapytać za pomocą argumentu show_status, a błędy można wyświetlić za pomocą argumentu show_errors.

Wynik.

Jak już powiedzieliśmy, każda funkcja replikacji jest kontrolowana przez demony. Aby je wyświetlić, wysyłamy zapytanie do tabeli procesów za pomocą polecenia ps systemu Linux, jak pokazano poniżej.

Wynik.

Replikacja nie jest uważana za skonfigurowaną, dopóki nie przetestujemy jej w czasie rzeczywistym, jak pokazano poniżej. Tworzymy tabelę, wstawiamy kilka rekordów do bazy danych MySQL i wywołujemy argument sync_tables w pg_chameleon, aby zaktualizować demony i replikować tabelę z rekordami do bazy danych 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.

Aby potwierdzić wyniki testu, wysyłamy zapytanie do tabeli z bazy danych PostgreSQL i wyprowadzamy wiersze.

$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
 n1 |  n2
----+-------
  1 | one
  2 | two

Jeśli przeprowadzamy migrację, następujące polecenia pg_chameleon zakończą ją. Polecenia należy wykonać, gdy mamy pewność, że wiersze wszystkich tabel docelowych zostały zreplikowane, a wynikiem będzie starannie zmigrowana baza danych PostgreSQL bez odniesień do źródłowej bazy danych lub schematu replikacji (sch_chameleon).

$> chameleon stop_replica --config default --source mysql 
$> chameleon detach_replica --config default --source mysql --debug

W razie potrzeby możesz użyć poniższych poleceń, aby usunąć oryginalną konfigurację i schemat replikacji.

$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debug

Zalety pg_chameleon

Łatwa instalacja i konfiguracja.
Z łatwością rozwiązuj problemy i identyfikuj anomalie dzięki przejrzystym komunikatom o błędach.
Dodatkowe tabele specjalne można dodać do replikacji po inicjalizacji bez zmiany reszty konfiguracji.
Możliwe jest skonfigurowanie wielu źródłowych baz danych dla jednej docelowej bazy danych, co jest bardzo przydatne, jeśli łączysz dane z jednej lub większej liczby baz danych MySQL w jedną bazę danych PostgreSQL.
Nie musisz replikować wybranych tabel.

Wady pg_chameleon

Obsługiwane tylko z MySQL 5.5 i nowszym jako źródłem oraz PostgreSQL 9.5 i nowszym jako docelową bazą danych.
Każda tabela musi mieć klucz podstawowy lub unikalny, w przeciwnym razie tabele zostaną zainicjowane podczas procesu init_replica, ale nie zostaną zreplikowane.
Replikacja jednokierunkowa - tylko z MySQL do PostgreSQL. Dlatego nadaje się tylko do obwodu „aktywno-pasywnego”.
Źródłem może być wyłącznie baza danych MySQL, a obsługa bazy danych PostgreSQL jako źródła ma charakter wyłącznie eksperymentalny i z ograniczeniami (dowiedz się więcej tutaj)

Wyniki dla pg_chameleon

Metoda replikacji w pg_chameleon doskonale nadaje się do migracji bazy danych z MySQL do PostgreSQL. Istotną wadą jest to, że replikacja jest tylko jednokierunkowa, więc specjaliści zajmujący się bazami danych raczej nie będą chcieli używać jej do celów innych niż migracja. Ale problem replikacji jednokierunkowej można rozwiązać za pomocą innego narzędzia open source - SymmetricDS.

Przeczytaj więcej w oficjalnej dokumentacji tutaj. Można znaleźć pomoc dotyczącą wiersza poleceń tutaj.

Przegląd SymmetricDS

SymmetricDS to narzędzie typu open source, które replikuje dowolną bazę danych do dowolnej innej popularnej bazy danych: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird i inne instancje baz danych w chmurze, np. Redshift i Azure itp. Dostępne funkcje: synchronizacja baz danych i plików, replikacja baz danych typu multi-master, synchronizacja filtrowana, transformacja i inne. Jest to narzędzie Java i wymaga standardowej wersji środowiska JRE lub JDK (wersja 8.0 lub wyższa). Tutaj można rejestrować zmiany danych wyzwalaczy w źródłowej bazie danych i przesyłać je do odpowiedniej docelowej bazy danych w formie partii.

Funkcje SymmetricDS

Narzędzie jest niezależne od platformy, co oznacza, że ​​dwie lub więcej różnych baz danych może wymieniać dane.
Relacyjne bazy danych są synchronizowane przy użyciu rekordów zmian danych, podczas gdy bazy danych oparte na systemie plików korzystają z synchronizacji plików.
Replikacja dwukierunkowa z wykorzystaniem metod Push i Pull w oparciu o zbiór reguł.
Przesyłanie danych jest możliwe w bezpiecznych sieciach o niskiej przepustowości.
Automatyczne odzyskiwanie, gdy węzły wznawiają działanie po awarii i automatyczne rozwiązywanie konfliktów.
Kompatybilne z chmurą i wydajne interfejsy API rozszerzeń.

Przykład

SymmetricDS można skonfigurować na jeden z dwóch sposobów:
Węzeł główny (nadrzędny), który centralnie koordynuje replikację danych pomiędzy dwoma węzłami podrzędnymi (podrzędnymi), a komunikacja między węzłami podrzędnymi odbywa się wyłącznie za pośrednictwem węzła nadrzędnego.
Aktywny węzeł (węzeł 1) może komunikować się w celu replikacji z innym aktywnym węzłem (węzeł 2) bez pośrednika.

W obu wariantach wymiana danych odbywa się za pomocą technologii Push i Pull. W tym przykładzie rozważymy konfigurację aktywny-aktywny. Opisanie całej architektury zajęłoby zbyt dużo czasu, więc przeprowadź badania. руководствоaby dowiedzieć się więcej o urządzeniu SymmetricDS.

Instalacja SymmetricDS jest bardzo prosta: pobierz wersję zip o otwartym kodzie źródłowym stąd i zabierz go gdziekolwiek chcesz. Poniższa tabela zawiera informacje o lokalizacji instalacji i wersji SymmetricDS w tym przykładzie, a także wersje baz danych, wersje systemu Linux, adresy IP i porty dla obu węzłów.

Gospodarz
vm1
vm2

Wersja systemu operacyjnego
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Wersja serwera DB
MySQL 5.7.26
PostgreSQL 10.5

portu DB
3306
5832

Adres IP
192.168.1.107
192.168.1.112

Wersja SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9

Ścieżka instalacji SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

Nazwa węzła SymmetricDS
korpus-000
sklep-001

Tutaj instalujemy SymmetricDS w /usr/local/symmetric-server-3.9.20 i będą tam przechowywane różne podkatalogi i pliki. Interesują nas podkatalogi próbek i silników. Katalog próbek zawiera przykładowe pliki konfiguracyjne z właściwościami węzła, a także przykładowe skrypty SQL umożliwiające szybkie rozpoczęcie pracy.

W katalogu próbek widzimy trzy pliki konfiguracyjne z właściwościami węzła - nazwa pokazuje charakter węzła w określonym schemacie.

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

SymmetricDS posiada wszystkie niezbędne pliki konfiguracyjne do podstawowego projektu 3-węzłowego (opcja 1), a te same pliki mogą być użyte do projektu 2-węzłowego (opcja 2). Skopiuj wymagany plik konfiguracyjny z katalogu próbek do silników na hoście vm1. Okazuje się tak:

$> 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

Ten węzeł w konfiguracji SymmetricDS nosi nazwę corp-000, a połączenie z bazą danych jest obsługiwane przez sterownik mysql jdbc, który wykorzystuje powyższe parametry połączenia i dane logowania. Łączymy się z bazą danych repliki_db i podczas tworzenia schematu zostaną utworzone tabele. sync.url pokazuje, gdzie skontaktować się z węzłem w celu synchronizacji.

Węzeł 2 na hoście vm2 jest skonfigurowany jako store-001, a resztę określono w pliku node.properties poniżej. Magazyn węzła-001 obsługuje bazę danych PostgreSQL, a pgdb_replica jest bazą danych replikacji. rejestracja.url umożliwia hostowi vm2 skontaktowanie się z hostem vm1 i otrzymanie od niego szczegółów konfiguracji.

$> 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

Wypełniony przykład SymmetricDS zawiera parametry umożliwiające skonfigurowanie replikacji dwukierunkowej pomiędzy dwoma serwerami baz danych (dwoma węzłami). Poniższe kroki są wykonywane na hoście vm1 (corp-000), który utworzy przykładowy schemat z 4 tabelami. Następnie uruchomienie create-sym-tables za pomocą komendy symadmin tworzy tabele katalogów, w których będą przechowywane reguły i kierunek replikacji pomiędzy węzłami. Na koniec do tabel ładowane są przykładowe dane.

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

W tym przykładzie tabele item i item_selling_price są automatycznie skonfigurowane do replikacji ze sklepu-000 do sklepu-001, a tabele sprzedaży (sale_transaction i sale_return_line_item) są automatycznie skonfigurowane do replikacji ze sklepu-001 do corp-000. Teraz tworzymy schemat w bazie danych PostgreSQL na hoście vm2 (store-001), aby przygotować go na odbiór danych z corp-000.

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

Pamiętaj, aby sprawdzić, czy baza danych MySQL na vm1 zawiera przykładowe tabele i tabele katalogu SymmetricDS. Należy zauważyć, że tabele systemowe SymmetricDS (z prefiksem sym_) są obecnie dostępne tylko w węźle corp-000, ponieważ tam uruchomiliśmy polecenie create-sym-tables i będziemy zarządzać replikacją. A w bazie danych węzła store-001 będą tylko 4 przykładowe tabele bez danych.

Wszystko. Środowisko jest gotowe do uruchomienia procesów serwera sym na obu węzłach, jak pokazano poniżej.

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

Wpisy dziennika są wysyłane do pliku dziennika w tle (symmetric.log) w folderze logs w katalogu, w którym zainstalowany jest SymmetricDS, a także na standardowe wyjście. Serwer sym może teraz zostać zainicjowany w węźle store-001.

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

Jeśli uruchomisz proces serwera sym na hoście vm2, utworzy on również tabele katalogu SymmetricDS w bazie danych PostgreSQL. Jeśli uruchomisz proces serwera sym na obu węzłach, będą one koordynować ze sobą replikację danych z korpusu 000 do magazynu 001. Jeśli po kilku sekundach wykonamy zapytanie do wszystkich 4 tabel po obu stronach, zobaczymy, że replikacja przebiegła pomyślnie. Możesz też wysłać pasek startowy do węzła store-001 z corp-000 za pomocą następującego polecenia.

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

W tym momencie nowy rekord jest wstawiany do tabeli pozycji w bazie danych MySQL w węźle corp-000 (host: vm1) i możesz sprawdzić jego replikację do bazy danych PostgreSQL w węźle store-001 (host: vm2). Widzimy operację Pull, która przenosi dane z korpusu-000 do magazynu-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)

Aby wykonać operację Push w celu przeniesienia danych ze sklepu-001 do corp-000, wstawiamy rekord do tabeli sale_transaction i sprawdzamy, czy replikacja przebiegła pomyślnie.

Wynik.

Widzimy pomyślną konfigurację dwukierunkowej replikacji przykładowych tabel pomiędzy bazami danych MySQL i PostgreSQL. Aby skonfigurować replikację dla nowych tabel użytkowników, wykonaj następujące kroki: Tworzymy na przykład tabelę t1 i konfigurujemy jej reguły replikacji w następujący sposób. W ten sposób konfigurujemy tylko replikację z corp-000 do 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)

Konfiguracja jest następnie powiadamiana o zmianie schematu, czyli dodaniu nowej tabeli, za pomocą polecenia symadmin z argumentem sync-triggers, które odtwarza wyzwalacze w celu odwzorowania definicji tabel. Wykonywany jest schemat wysyłania w celu wysłania zmian schematu do magazynu węzła 001 i skonfigurowana jest replikacja tabeli t1.

vm1$> ./symadmin -e corp-000 --node=001 sync-triggers    
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1

Korzyści z SymmetricDS

Łatwa instalacja i konfiguracja, łącznie z gotowym zestawem plików z parametrami umożliwiającymi utworzenie obwodu trójwęzłowego lub dwuwęzłowego.
Wieloplatformowe bazy danych i niezależność od platform, w tym serwerów, laptopów i urządzeń mobilnych.
Replikuj dowolną bazę danych do dowolnej innej bazy danych lokalnie, w sieci WAN lub w chmurze.
Możliwość optymalnej pracy z kilkoma bazami danych lub kilkoma tysiącami dla wygodnej replikacji.
Wersja płatna z graficznym interfejsem użytkownika i doskonałym wsparciem.

Wady SymmetricDS

Aby załadować tabele katalogu, należy ręcznie zdefiniować reguły i kierunek replikacji w wierszu poleceń za pomocą instrukcji SQL, co może być niewygodne.
Konfigurowanie wielu tabel do replikacji może być uciążliwe, chyba że używasz skryptów do tworzenia instrukcji SQL definiujących reguły i kierunek replikacji.
W logach zapisywanych jest zbyt dużo informacji i czasami trzeba uporządkować plik logu, aby nie zajmował zbyt dużo miejsca.

Wyniki dla SymmetricDS

SymmetricDS umożliwia skonfigurowanie replikacji dwukierunkowej pomiędzy dwoma, trzema, a nawet kilkoma tysiącami węzłów w celu replikacji i synchronizacji plików. To unikalne narzędzie, które samodzielnie realizuje wiele zadań, takich jak automatyczne odzyskiwanie danych po długim okresie przestoju na węźle, bezpieczna i wydajna wymiana danych pomiędzy węzłami poprzez HTTPS, automatyczne zarządzanie konfliktami w oparciu o zbiór reguł itp. SymmetricDS wykonuje replikacja między dowolnymi bazami danych, dlatego można go używać w wielu różnych scenariuszach, w tym w migracji, migracji, dystrybucji, filtrowaniu i transformacji danych na różnych platformach.

Przykład opiera się na urzędniku Szybka porada przez SymmetricDS. W instrukcja obsługi Opisuje szczegółowo różne koncepcje związane z konfiguracją replikacji za pomocą SymmetricDS.

Źródło: www.habr.com