Replikacja krzyżowa między PostgreSQL a MySQL

W skrócie opowiem o replikacji krzyżowej między PostgreSQL a MySQL oraz o metodach konfigurowania replikacji krzyżowej między tymi dwoma serwerami baz danych. Zazwyczaj bazy danych w replikacji krzyżowej nazywane są jednorodnymi, a to wygodna metoda przejścia z jednego serwera relacyjnej bazy danych na inny.

Bazy danych PostgreSQL i MySQL są uważane za relacyjne, ale dzięki dodatkowym rozszerzeniom oferują możliwości NoSQL. Tutaj omówimy replikację między PostgreSQL a MySQL z perspektywy relacyjnych baz danych.

Nie będziemy opisywać całej wewnętrznej kuchni, tylko podstawowe zasady, abyś miał pojęcie o konfiguracji replikacji między serwerami baz danych, jej zaletach, ograniczeniach oraz scenariuszach użycia.

Zazwyczaj replikacja między dwoma identycznymi serwerami baz danych odbywa się w trybie binarnym lub za pomocą zapytań między węzłem głównym (wydawcą, głównym lub aktywnym) a węzłem podrzędnym (subskrybentem, oczekującym lub pasywnym). Celem replikacji jest dostarczenie w czasie rzeczywistym kopii głównej bazy danych po stronie węzła podrzędnego. Dane są przesyłane od węzła głównego do podrzędnego, czyli z aktywnego do pasywnego, ponieważ replikacja odbywa się tylko w jedną stronę. Można jednak skonfigurować replikację między dwiema bazami danych w obie strony, aby dane były przesyłane od węzła podrzędnego do głównego w konfiguracji „aktywny-aktywny”. Wszystko to, w tym replikacja kaskadowa, możliwe jest między dwoma lub więcej identycznymi serwerami baz danych. Konfiguracja „aktywny-aktywny” lub „aktywny-pasywny” zależy od potrzeb, dostępności takich możliwości w pierwotnej konfiguracji lub wykorzystania zewnętrznych rozwiązań do konfiguracji oraz istniejących kompromisów.

Opisana konfiguracja jest możliwa między różnymi serwerami baz danych. Serwer można skonfigurować do odbierania replikowanych danych z innego serwera baz danych, jednocześnie zachowując zrzuty replikowanych danych w czasie rzeczywistym. MySQL i PostgreSQL oferują większość z tych konfiguracji samodzielnie lub za pomocą zewnętrznych rozszerzeń, w tym metody dziennika binarnego, blokady dysków oraz metody oparte na operatorach i wierszach.

Replikacja krzyżowa między MySQL a PostgreSQL jest potrzebna do jednorazowej migracji z jednego serwera bazy danych na inny. Te bazy danych używają różnych protokołów, więc nie można je połączyć bezpośrednio. Aby zorganizować wymianę danych, można użyć zewnętrznego narzędzia open source, takiego jak pg_chameleon.

Co to jest pg_chameleon

pg_chameleon to system replikacji z MySQL do PostgreSQL w Pythonie 3. Wykorzystuje on open source'ową bibliotekę mysql-replication, również napisaną w Pythonie. Obrazy wierszy są wydobywane z tabel MySQL i zapisywane jako obiekty JSONB w bazie danych PostgreSQL, a następnie dekodowane funkcją pl/pgsql i odtwarzane w bazie danych PostgreSQL.

Możliwości pg_chameleon

Kilka schematów MySQL z jednego klastra można replikować do jednej docelowej bazy danych PostgreSQL w konfiguracji "jeden do wielu".
Nazwy schematów źródłowego i docelowego nie mogą się pokrywać.
Dane replikacji można wydobywać z kaskadowej repliki MySQL.
Tabele, które nie mogą być replikowane lub powodują błędy, są wykluczane.
Każdą funkcją replikacji zarządzają demony.
Kontrola poprzez parametry i pliki konfiguracyjne na bazie YAML.

Przykład

Host
vm1
vm2

Wersja systemu operacyjnego
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Wersja serwera bazy danych
MySQL 5.7.26
PostgreSQL 10.5

Port bazy danych
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 zainstalowano Pythona 3.6.8, który tworzy i aktywuje wirtualne środowisko.

$> 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 należy zrealizować pozostałe wymagania, na przykład utworzyć i aktywować wirtualne środowisko. Ponadto moduł pip jest aktualizowany do najnowszej wersji i używany do instalacji pg_chameleon. W poniższych poleceniach celowo instalujemy pg_chameleon w wersji 2.0.9, mimo że najnowsza wersja to 2.0.10. Ma to na celu uniknięcie 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 (chameleon to komenda) z argumentem set_configuration_files, aby włączyć pg_chameleon i utworzyć katalogi oraz pliki konfiguracyjne domyślne.

(venv) $> chameleon set_configuration_files
utworzenie katalogu /root/.pg_chameleon
utworzenie katalogu /root/.pg_chameleon/configuration/
utworzenie katalogu /root/.pg_chameleon/logs/
utworzenie katalogu /root/.pg_chameleon/pid/
kopiowanie przykładowej konfiguracji do /root/.pg_chameleon/configuration//config-example.yml

Teraz tworzymy kopię config-example.yml jako default.yml, aby stał się domyślnym plikiem konfiguracyjnym. Przykład pliku konfiguracyjnego dla tego przypadku przedstawiono 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 wzór pliku z pg_chameleon z niewielkimi zmianami zgodnie z oryginalnym i docelowym środowiskiem, a poniżej przedstawiono przegląd różnych sekcji pliku konfiguracyjnego.

W pliku konfiguracyjnym default.yml znajduje się sekcja globalnych ustawień (global settings), w której można zarządzać takimi ustawieniami, jak lokalizacja pliku blokady, lokalizacja logów, okres przechowywania logów itp. Następnie znajdujemy sekcję zmiany typów (type override), w której wskazany jest zestaw reguł do nadpisywania typów podczas replikacji. W przykładzie domyślnym użyte jest reguła zmiany typu, która przekształca tinyint(1) w wartość logiczną. W następnej sekcji podajemy dane połączenia z docelową bazą danych. W naszym przypadku jest to baza danych PostgreSQL, oznaczona jako pg_conn. W ostatniej sekcji podajemy dane źródłowe, czyli parametry połączenia z oryginalną bazą danych, mapowanie schematów oryginalnej i docelowej bazy danych, tabele, które należy pominąć, czas oczekiwania, pamięć, rozmiar partii. Zauważ, że „sources” jest podane w liczbie mnogiej, co oznacza, że możemy dodać kilka baz danych źródłowych do jednej docelowej, aby dostosować konfigurację „wielu do jednego”.

Baza danych world_x w przykładzie zawiera 4 tabele z wierszami, które społeczność MySQL oferuje jako przykład. Można ją załadować tutaj. Przykład bazy danych dostarczany jest jako archiwum tar i skompresowany z instrukcjami dotyczącymi tworzenia i importowania wierszy.

W bazach danych MySQL i PostgreSQL tworzony jest specjalny użytkownik o tej samej nazwie usr_replica. W MySQL przyznawane są mu dodatkowe uprawnienia do odczytu 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 będzie przyjmować zmiany z bazy danych 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ą faktycznie replikowane tabele oraz tabele z katalogami replikacji odpowiednio. Automatyczna konfiguracja jest realizowana przez argument create_replica_schema, o czym przekonasz się 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 konfigurowana z wprowadzeniem zmian w niektórych parametrach, aby przygotować ją do replikacji, jak pokazano poniżej. Należy zrestartować serwer baz danych, aby zmiany weszły w życie.

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

Obecnie ważne jest, aby sprawdzić połączenie z obiema bazami danych, aby podczas wykonywania poleceń pg_chameleon nie wystąpiły problemy.

Na węźle PostgreSQL:

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

Na węźle MySQL:

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

Następujące trzy polecenia pg_chameleon (chameleon) przygotowują środowisko, dodają źródło i inicjalizują replikę. Argument create_replica_schema w pg_chameleon tworzy schemat domyślny (sch_chameleon) i schemat replikacji (pgworld_x) w bazie danych PostgreSQL, jak już wspomniano. Argument add_source dodaje źródłową bazę danych do konfiguracji, odczytując plik konfiguracyjny (default.yml), a w naszym przypadku to mysql, a init_replica inicjalizuje konfigurację na podstawie parametrów w pliku konfiguracyjnym.

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

Wyniki tych trzech poleceń jasno wskazują na ich pomyślne wykonanie. Wszystkie błędy lub błędy składniowe są zgłaszane w prostych i zrozumiałych komunikatach, zawierających wskazówki dotyczące rozwiązywania problemów.

Na koniec uruchomimy replikację za pomocą start_replica i otrzymamy komunikat o pomyślnym wykonaniu.

$> chameleon start_replica --config default --source mysql 
wyjście: Rozpoczynanie procesu replikacji dla źródła mysql

Status replikacji można sprawdzić za pomocą argumentu show_status, a błędy można przeglądać za pomocą argumentu show_errors.

Wynik.

Jak już wspomniano, każdą funkcją replikacji zarządzają demony. Aby je zobaczyć, możemy zapytać tabelę procesów za pomocą polecenia Linux ps, jak pokazano poniżej.

Wynik.

Replikacja nie jest uznawana 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 zapisami w bazie danych PostgreSQL.

mysql> create table t1 (n1 int primary key, n2 varchar(10));
Zapytanie OK, 0 wierszy dotkniętych (0.01 sek)
mysql> insert into t1 values (1,'one');
Zapytanie OK, 1 wiersz dotknięty (0.00 sek)
mysql> insert into t1 values (2,'two');
Zapytanie OK, 1 wiersz dotknięty (0.00 sek)

$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Rozpoczęto proces synchronizacji tabel dla źródła mysql.

Aby potwierdzić wyniki testu, zapytujemy tabelę z bazy danych PostgreSQL i wyświetlamy 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 wykonywać po upewnieniu się, że wszystkie rekordy w docelowych tabelach zostały zreplikowane, a wynikiem będzie starannie przeniesiona 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

Opcjonalnie, następującymi poleceniami można usunąć pierwotną konfigurację i schemat replikacji.

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

Zalety pg_chameleon

Prosta konfiguracja i ustawienia.
Łatwe rozwiązywanie problemów i identyfikacja anomalii przy pomocy zrozumiałych komunikatów o błędach.
Do replikacji można dodać dodatkowe specjalne tabele po inicjalizacji, nie zmieniając pozostałej konfiguracji.
Można skonfigurować wiele źródłowych baz danych dla jednej docelowej, co jest bardzo wygodne, gdy łączysz dane z jednej lub kilku baz danych MySQL w jednej bazie danych PostgreSQL.
Wybrane tabele można nie replikować.

Wady pg_chameleon

Obsługuje tylko MySQL 5.5 i nowsze jako źródło oraz PostgreSQL 9.5 i nowsze jako docelową bazę danych.
Każda tabela musi mieć klucz podstawowy lub unikalny, w przeciwnym razie tabele są inicjowane w procesie init_replica, ale nie są replikowane.
Replikacja jednostronna — tylko z MySQL do PostgreSQL. Dlatego nadaje się tylko do schematu „aktywny-pasywny”.
Źródłową bazą danych może być tylko MySQL, a wsparcie dla bazy danych PostgreSQL jako źródła jest tylko eksperymentalne i ma ograniczenia (dowiedz się więcej tutaj)

Podsumowanie pg_chameleon

Metoda replikacji w pg_chameleon świetnie nadaje się do migracji bazy danych z MySQL do PostgreSQL. Znacznym minusem jest to, że replikacja jest tylko jednostronna, dlatego specjaliści od baz danych raczej nie będą chcieli jej używać do niczego poza migracją. Jednak problem jednostronnej replikacji można rozwiązać za pomocą jeszcze jednego narzędzia open source — SymmetricDS.

Więcej informacji znajdziesz w oficjalnej dokumentacji tutaj. Dokumentację pomocy w wierszu poleceń można znaleźć tutaj.

Przegląd SymmetricDS

SymmetricDS to narzędzie open source, które replikuje dowolną bazę danych do innej powszechnie stosowanej bazy danych: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird i inne chmurowe instancje baz danych, takie jak Redshift i Azure itp. Dostępne funkcje: synchronizacja baz danych i plików, replikacja wielu wiodących baz danych, filtrowana synchronizacja, konwersja i inne. To narzędzie w Javie wymaga standardowej wersji JRE lub JDK (wersja 8.0 lub nowsza). Można rejestrować zmiany danych na podstawie wyzwalaczy w źródłowej bazie danych i kierować je do odpowiedniej docelowej bazy danych w postaci paczek.

Możliwości SymmetricDS

Narzędzie jest niezależne od platformy, co oznacza, że dwie lub więcej różnych baz danych mogą wymieniać się danymi.
Relacyjne bazy danych są synchronizowane poprzez rejestrowanie zmian danych, a bazy danych oparte na systemach plikowych wykorzystują synchronizację plików.
Dwustronna replikacja z wykorzystaniem metod Push i Pull na podstawie zestawu zasad.
Przesyłanie danych jest możliwe przez zabezpieczone sieci oraz sieci o niskiej przepustowości.
Automatyczne przywracanie po wznowieniu pracy węzłów po awarii oraz automatyczne rozwiązywanie konfliktów.
Kompatybilność z chmurą oraz efektywne API rozszerzeń.

Przykład

SymmetricDS można skonfigurować na jeden z dwóch sposobów:
Węzeł nadrzędny, który centralnie koordynuje replikację danych między dwoma węzłami podrzędnymi, a wymiana danych między węzłami podrzędnymi odbywa się tylko przez węzeł nadrzędny.
Aktywny węzeł (węzeł 1) może wymieniać dane do replikacji z innym aktywnym węzłem (węzeł 2) bez pośrednika.

W obu wariantach wymiana danych odbywa się za pomocą Push i Pull. W tym przykładzie zaprezentujemy konfigurację 'aktywny-aktywny'. Opisanie całej architektury zajmie zbyt dużo czasu, więc zajrzyj do przewodnik, aby dowiedzieć się więcej o architekturze SymmetricDS.

Zainstalowanie SymmetricDS jest bardzo proste: pobierz wersję open-source w formacie zip stąd i wypakuj ją w dowolnym miejscu. W poniższej tabeli znajdują się informacje o lokalizacji instalacji i wersji SymmetricDS w tym przykładzie, a także wersje baz danych, wersje Linux, adresy IP i porty dla obu węzłów.

Host
vm1
vm2

Wersja systemu operacyjnego
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Wersja serwera bazy danych
MySQL 5.7.26
PostgreSQL 10.5

Port bazy danych
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
corp-000
store-001

Tutaj instalujemy SymmetricDS w /usr/local/symmetric-server-3.9.20, a różne zagnieżdżone katalogi i pliki będą przechowywane w tym miejscu. Interesują nas zagnieżdżone katalogi samples i engines. W katalogu samples znajdują się przykłady plików konfiguracyjnych z właściwościami węzła, a także przykłady skryptów SQL do szybkiego uruchamiania demonstracji.

W katalogu samples widzimy trzy pliki konfiguracyjne z właściwościami węzła — nazwa wskazuje na charakter węzła w określonej schemacie.

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

W SymmetricDS znajdują się wszystkie niezbędne pliki konfiguracyjne dla podstawowej schemy z 3 węzłami (wariant 1), a te same pliki można użyć dla schemy z 2 węzłami (wariant 2). Kopiujemy potrzebny plik konfiguracyjny z katalogu samples do engines na hoście vm1. Wygląda to 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żej podany łańcuch połączenia oraz dane logowania. Łączymy się z bazą danych replica_db, a podczas tworzenia schemy zostaną utworzone tabele. sync.url pokazuje miejsce połączenia z węzłem do synchronizacji.

Węzeł 2 na hoście vm2 jest konfigurowany jako store-001, a reszta jest określona w pliku node.properties, który jest podany poniżej. Węzeł store-001 obsługuje bazę danych PostgreSQL, a pgdb_replica to baza danych do replikacji. registration.url umożliwia hostowi vm2 nawiązanie połączenia z hostem vm1 i uzyskanie 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

Gotowy przykład SymmetricDS zawiera parametry do konfiguracji dwukierunkowej replikacji między dwoma serwerami baz danych (dwoma węzłami). Poniższe kroki są wykonywane na hoście vm1 (corp-000), który utworzy przykładową schemę z 4 tabelami. Następnie wykonanie polecenia create-sym-tables za pomocą symadmin tworzy tabele katalogów, gdzie będą przechowywane zasady i kierunek replikacji między węzłami. Na koniec do tabeli wczytywane 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 przykładzie tabele item i item_selling_price są automatycznie konfigurowane do replikacji z corp-000 do store-001, a tabele sale (sale_transaction i sale_return_line_item) są automatycznie konfigurowane do replikacji z store-001 do corp-000. Teraz tworzymy schemę w bazie danych PostgreSQL na hoście vm2 (store-001), aby przygotować ją do odbioru danych z corp-000.

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

Koniecznie sprawdzamy, czy w bazie danych MySQL na vm1 są przykładowe tabele i tabele katalogów SymmetricDS. Zauważ, że tabele systemowe SymmetricDS (z prefiksem sym_) są obecnie dostępne tylko na węźle corp-000, ponieważ tam wykonaliśmy polecenie create-sym-tables i będziemy zarządzać replikacją. Dodatkowo w bazie danych na węźle store-001 będzie tylko 4 przykładowe tabele bez danych.

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

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

Rejestry logów są wysyłane do pliku logu w tle (symmetric.log) w folderze logów w katalogu, gdzie zainstalowano SymmetricDS, a także do standardowego wyjścia. Serwer sym można teraz zainicjować na węźle store-001.

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

Jeżeli uruchomimy proces serwera sym na hoście vm2, utworzy on tabele katalogu SymmetricDS także w bazie danych PostgreSQL. Gdy uruchomimy proces serwera sym na obu węzłach, będą one współpracować ze sobą w celu replikacji danych z corp-000 na store-001. Jeśli po kilku sekundach zapytamy o wszystkie 4 tabele po obu stronach, zobaczymy, że replikacja zakończyła się pomyślnie. Można również wysłać wstępne załadowanie do węzła store-001 z corp-000 następującą komendą.

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

Na tym etapie do tabeli item w bazie danych MySQL na węźle corp-000 (host: vm1) dodawany jest nowy wpis, który można sprawdzić pod kątem replikacji w bazie danych PostgreSQL na węźle store-001. Widzimy operację Pull w celu przeniesienia danych z corp-000 do 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)

Aby wykonać operację Push w celu przeniesienia danych z store-001 do corp-000, dodajemy wpis do tabeli sale_transaction i sprawdzamy, czy replikacja została wykonana.

Wynik.

Widzimy udane skonfigurowanie dwustronnej replikacji tabel przykładu między bazami danych MySQL a PostgreSQL. Aby skonfigurować replikację dla nowych tabel użytkowników, wykonujemy następujące kroki. Tworzymy tabelę t1 jako przykład i konfigurujemy zasady jej replikacji w następujący sposób. W ten sposób konfigurowana jest tylko replikacja 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)

Następnie konfiguracja otrzymuje powiadomienie o zmianie schematu, czyli dodaniu nowej tabeli, za pomocą polecenia symadmin z argumentem sync-triggers, które odtwarza wyzwalacze do dopasowania definicji tabel. Wykonywana jest send-schema w celu wysłania zmian schematu do węzła store-001, a replikacja tabeli t1 jest skonfigurowana.

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

Zalety SymmetricDS

Prosta instalacja i konfiguracja, w tym gotowy zestaw plików z parametrami do tworzenia schematu z trzema lub dwoma węzłami.
Krosplatformowość baz danych i niezależność od platformy, w tym serwery, laptopy i urządzenia mobilne.
Replikacja dowolnej bazy danych do innej bazy danych lokalnie, w WAN lub w chmurze.
Możliwość optymalnej pracy z parą baz danych lub z kilkoma tysiącami w celu wygodnej replikacji.
Płatna wersja z graficznym interfejsem i doskonałym wsparciem.

Wady SymmetricDS

Trzeba ręcznie określać w wierszu poleceń zasady i kierunek replikacji za pomocą operatorów SQL do załadowania tabel katalogów, co bywa niewygodne.
Konfiguracja wielu tabel do replikacji może być uciążliwa, jeśli nie korzysta się ze skryptów do tworzenia operatorów SQL, które definiują zasady i kierunek replikacji.
Do logów trafia zbyt wiele informacji, a czasem trzeba uporządkować plik loga, aby nie zajmował zbyt dużo miejsca.

Podsumowanie SymmetricDS

SymmetricDS umożliwia konfigurowanie dwukierunkowej replikacji między dwoma, trzema a nawet kilkoma tysiącami węzłów, aby realizować replikację i synchronizować pliki. To unikalne narzędzie, które samodzielnie wykonuje wiele zadań, takich jak automatyczne przywracanie danych po długim okresie przestoju na węźle, zabezpieczona i efektywna wymiana danych między węzłami przez HTTPS, automatyczne zarządzanie konfliktami na podstawie zestawu zasad itd. SymmetricDS wykonuje replikację między dowolnymi bazami danych, dlatego można go używać w różnych scenariuszach, w tym migracji, przeprowadzce na nową wersję, dystrybucji, filtrowaniu i transformacji danych na różnych platformach.

Przykład został stworzony na podstawie oficjalnego krótkiego przewodnika po SymmetricDS. W podręczniku użytkownika Szczegółowo opisano różne pojęcia związane z konfiguracją replikacji za pomocą SymmetricDS.

Źródło: habr.com