Przegląd replikacji krzyżowej PostgreSQL i MySQL

Ten blog ma na celu wyjaśnienie przeglądu replikacji krzyżowej między PostgreSQL i MySQL oraz dalsze omówienie metod konfigurowania replikacji krzyżowej między dwoma serwerami baz danych. Tradycyjnie bazy danych biorące udział w konfiguracji replikacji krzyżowej nazywane są heterogenicznymi bazami danych, co jest dobrym podejściem do przejścia z jednego serwera RDBMS na drugi.

Zarówno bazy danych PostgreSQL, jak i MySQL są konwencjonalnie bazami danych RDBMS, ale oferują również funkcję NoSQL z dodatkowymi rozszerzeniami, aby mieć to, co najlepsze z obu światów. Ten artykuł skupia się na omówieniu replikacji między PostgreSQL i MySQL z perspektywy RDBMS.

Wyczerpujące wyjaśnienie dotyczące elementów wewnętrznych replikacji nie jest objęte zakresem tego bloga, jednak niektóre podstawowe elementy zostaną omówione, aby dać odbiorcom zrozumienie, w jaki sposób jest skonfigurowana replikacja między serwerami baz danych, jakie są jej zalety, ograniczenia i być może niektóre znane przypadki użycia.

Ogólnie replikacja między dwoma identycznymi serwerami baz danych odbywa się w trybie binarnym lub w trybie zapytania między węzłem głównym (inaczej zwanym wydawcą, podstawowym lub aktywnym) a węzłem podrzędnym (subskrybującym, rezerwowym lub pasywnym). Celem replikacji jest dostarczenie kopii bazy danych master w czasie rzeczywistym po stronie slave, gdzie dane są przesyłane z mastera do slavea, tworząc w ten sposób konfigurację aktywno-pasywną, ponieważ replikacja jest skonfigurowana tylko w jedną stronę. Z drugiej strony replikację między dwiema bazami danych można skonfigurować w obie strony, dzięki czemu dane mogą być również przesyłane z urządzenia podrzędnego z powrotem do urządzenia nadrzędnego, ustanawiając konfigurację aktywny-aktywny. Wszystko to można skonfigurować między dwoma lub większą liczbą identycznych serwerów baz danych, które mogą również obejmować replikację kaskadową. Konfiguracja aktywnych-aktywnych lub aktywnych-pasywnych naprawdę zależy od potrzeb biznesowych, dostępności takich funkcji w konfiguracji natywnej lub wykorzystania zewnętrznych rozwiązań do konfiguracji i odpowiednich kompromisów.

Wspomnianą powyżej konfigurację można zrealizować za pomocą różnych serwerów baz danych, przy czym serwer bazy danych może być skonfigurowany tak, aby akceptował zreplikowane dane z innego zupełnie innego serwera bazy danych i nadal zachowywał migawkę replikowanych danych w czasie rzeczywistym. Zarówno serwery baz danych MySQL, jak i PostgreSQL oferują większość konfiguracji omówionych powyżej we własnej natywnej lub z pomocą rozszerzeń innych firm, w tym metody dziennika binarnego, metody bloku dysku, metod opartych na instrukcjach i opartych na wierszach.

Wymóg skonfigurowania replikacji krzyżowej między MySQL i PostgreSQL jest tak naprawdę wynikiem jednorazowej migracji w celu przejścia z jednego serwera bazy danych na inny. Ponieważ obie bazy danych korzystają z różnych protokołów, nie mogą bezpośrednio komunikować się ze sobą. Aby osiągnąć ten przepływ komunikacji, istnieje zewnętrzne narzędzie typu open source, takie jak pg_chameleon.

Tło pg_kameleon

pg_chameleon to system replikacji MySQL do PostgreSQL opracowany w Pythonie 3. Wykorzystuje bibliotekę open source o nazwie mysql-replication, która jest również rozwijana przy użyciu Pythona. Funkcjonalność polega na pobieraniu obrazów wierszy tabel MySQL i przechowywaniu ich jako obiektów JSONB w bazie danych PostgreSQL, która jest dalej dekodowana przez funkcję pl/pgsql i odtwarzaniu tych zmian w bazie danych PostgreSQL.

Funkcje pg_kameleon

• Wiele schematów MySQL z tego samego klastra można zreplikować do pojedynczej docelowej bazy danych PostgreSQL, tworząc konfigurację replikacji wiele-do-jednego
• Nazwy źródłowego i docelowego schematu mogą nie być identyczne
• Dane replikacji można pobrać z kaskadowej repliki MySQL
• Tabele, które nie replikują się lub nie generują błędów, są wykluczone
• Każdą funkcją replikacji zarządza się za pomocą demonów
• Kontrolowane za pomocą parametrów i plików konfiguracyjnych opartych na konstrukcji YAML

Demo

Na początek przygotuj instalację ze wszystkimi wymaganiami wstępnymi potrzebnymi do zainstalowania pg_chameleon. W tym demo Python 3.6.8 jest zainstalowany, tworząc wirtualne środowisko i aktywując je do użytku.

$> 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 udanej instalacji Pythona3.6 spełnione są dalsze dodatkowe wymagania, takie jak tworzenie i aktywacja środowiska wirtualnego. Oprócz tego moduł pip zaktualizowany do najnowszej wersji i służy do instalacji pg_chameleon. W poniższych poleceniach celowo zainstalowano pg_chameleon 2.0.9, podczas gdy najnowsza wersja to 2.0.10. Odbywa się to w celu uniknięcia wszelkich nowo wprowadzonych 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ępnym krokiem jest wywołanie pg_kameleon (kameleon to polecenie) z argumentem set_configuration_files, aby umożliwić pg_kameleonowi tworzenie domyślnych katalogów i plików konfiguracyjnych.

(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 utwórz kopię pliku config-example.yml jako default.yml, aby uczynić go domyślnym plikiem konfiguracyjnym. Przykładowy plik konfiguracyjny użyty w tej demonstracji 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 użyty w tym demo to przykładowy plik, który jest dostarczany z pg_chameleon z drobnymi edycjami w celu dopasowania do środowiska źródłowego i docelowego, a poniżej znajduje się podsumowanie różnych sekcji pliku konfiguracyjnego.

Plik konfiguracyjny default.yml zawiera sekcję „ustawienia globalne”, która kontroluje szczegóły, takie jak lokalizacja pliku blokady, lokalizacje rejestrowania i okres przechowywania itp. Następna sekcja to sekcja „zastąpienie typu”, która jest zestawem reguł do zastąpienia typy podczas replikacji. Domyślnie używana jest reguła nadpisania typu próbki, która konwertuje tinyint(1) na wartość logiczną. Następna sekcja to sekcja szczegółów połączenia z docelowym połączeniem z bazą danych, która w naszym przypadku jest bazą danych PostgreSQL, oznaczoną przez „pg_conn”. Ostatnia sekcja to sekcja źródłowa, która zawiera wszystkie szczegóły ustawień połączenia źródłowej bazy danych, mapowanie schematu między źródłem a miejscem docelowym, wszelkie tabele do pominięcia, w tym ustawienia limitu czasu, pamięci i rozmiaru wsadu. Zwróć uwagę na „źródła” oznaczające, że może istnieć wiele źródeł do jednego miejsca docelowego, tworząc konfigurację replikacji wiele-do-jednego.

W tym demo używana jest baza danych „world_x”, która jest przykładową bazą danych z 4 tabelami zawierającymi przykładowe wiersze, którą społeczność MySQL oferuje do celów demonstracyjnych i można ją pobrać stąd. Przykładowa baza danych jest dostarczana w postaci smoły i skompresowanego archiwum wraz z instrukcjami dotyczącymi jej tworzenia i importowania do niej wierszy.

Dedykowany użytkownik jest tworzony zarówno w bazach danych MySQL, jak i PostgreSQL o tej samej nazwie co usr_replica, któremu dodatkowo przyznaje się dodatkowe uprawnienia w MySQL umożliwiające dostęp 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, która będzie akceptować zmiany z bazy danych MySQL o nazwie „db_replica”. Użytkownik „usr_replica” w PostgreSQL jest automatycznie konfigurowany jako właściciel dwóch schematów, takich jak „pgworld_x” i „sch_chameleon”, które zawierają odpowiednio rzeczywiste zreplikowane tabele i tabele katalogów replikacji. Ta automatyczna konfiguracja jest wykonywana za pomocą argumentu create_replica_schema, wskazanego 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 kilkoma zmianami parametrów w celu przygotowania jej do replikacji, jak pokazano poniżej, i wymaga ponownego uruchomienia serwera bazy danych, aby zmiany odniosły skutek.

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

W tym momencie ważne jest przetestowanie połączenia z obydwoma serwerami baz danych, aby upewnić się, że nie ma problemów podczas wykonywania 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

Kolejne trzy polecenia pg_chameleon (kameleon) to miejsce, w którym konfiguruje środowisko, dodaje źródło i inicjuje replikę. Argument „create_replica_schema” pg_chameleon tworzy domyślny schemat (sch_chameleon) i schemat replikacji (pgworld_x) w bazie danych PostgreSQL, co zostało już omówione. Argument „add_source” dodaje źródłową bazę danych do konfiguracji poprzez odczytanie pliku konfiguracyjnego (default.yml), którym w tym przypadku jest „mysql”, natomiast „init_replica” inicjuje konfigurację na podstawie ustawień 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 powyższych trzech poleceń są oczywiste i wskazują na sukces każdego polecenia z wyraźnym komunikatem wyjściowym. Wszelkie niepowodzenia lub błędy składniowe są wyraźnie wymienione w prostych i prostych komunikatach, sugerując w ten sposób i podpowiadając działania naprawcze.

Ostatnim krokiem jest rozpoczęcie replikacji za pomocą „start_replica”, której powodzenie jest wskazywane przez wskazówkę wyjściową, jak pokazano poniżej.

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

Status replikacji można sprawdzić za pomocą argumentu „show_status”, podczas gdy błędy można wyświetlić za pomocą argumentu „show_errors”.

$> chameleon show_status --source mysql  
OUTPUT: 
  Source id  Source name    Type    Status    Consistent    Read lag    Last read    Replay lag    Last replay
-----------  -------------  ------  --------  ------------  ----------  -----------  ------------  -------------
          1  mysql          mysql   running   No            N/A                      N/A

== Schema mappings ==
Origin schema    Destination schema
---------------  --------------------
world_x          pgworld_x

== Replica status ==
---------------------  ---
Tables not replicated  0
Tables replicated      4
All tables             4
Last maintenance       N/A
Next maintenance       N/A
Replayed rows
Replayed DDL
Skipped rows
---------------------  ---
$> chameleon show_errors --config default 
output: There are no errors in the log

Jak wspomniano wcześniej, każda funkcja replikacji jest zarządzana za pomocą demonów, które można wyświetlić, wysyłając zapytanie do tabeli procesów za pomocą polecenia „ps” systemu Linux, przedstawionego poniżej.

$>  ps -ef|grep chameleon
root       763     1  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       764   763  0 19:20 ?        00:00:01 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       765   763  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql

Żadna konfiguracja replikacji nie jest ukończona, dopóki nie zostanie poddana testowi „stosowania w czasie rzeczywistym”, który został zasymulowany jak poniżej. Obejmuje to utworzenie tabeli i wstawienie kilku rekordów do bazy danych MySQL, a następnie wywoływany jest argument „sync_tables” pg_chameleon w celu zaktualizowania demonów w celu zreplikowania tabeli wraz z jej 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.

Test jest potwierdzany przez zapytanie tabeli z bazy danych PostgreSQL w celu odzwierciedlenia wierszy.

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

Jeśli jest to projekt migracyjny, następujące polecenia pg_chameleon będą oznaczać koniec prac związanych z migracją. Polecenia powinny zostać wykonane po potwierdzeniu, że wiersze wszystkich tabel docelowych zostały zreplikowane, a wynikiem będzie czysta migracja bazy danych PostgreSQL bez żadnych 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ące polecenia usuną konfigurację źródła i schemat replikacji.

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

Zalety korzystania z pg_chameleon

• Prosta konfiguracja i mniej skomplikowana konfiguracja
• Bezbolesne rozwiązywanie problemów i wykrywanie anomalii z łatwym do zrozumienia komunikatami o błędach
• Do replikacji można dodać dodatkowe tabele adhoc po inicjalizacji, bez zmiany jakiejkolwiek innej konfiguracji
• Wiele źródeł można skonfigurować dla jednej docelowej bazy danych, co jest przydatne w projektach konsolidacyjnych do łączenia danych z jednej lub większej liczby baz danych MySQL w jedną bazę danych PostgreSQL
• Wybrane tabele można pominąć z replikacji

Wady korzystania z pg_chameleon

• Obsługiwane tylko od MySQL 5.5 i nowszych jako baza danych Origin i PostgreSQL 9.5 i nowszych jako baza danych docelowych
• Wymaga, aby każda tabela miała klucz podstawowy lub unikalny, w przeciwnym razie tabele zostaną zainicjowane podczas procesu init_replica, ale ich replikacja nie powiedzie się
• Replikacja jednokierunkowa, np. MySQL do PostgreSQL. Ograniczając w ten sposób jego użycie tylko do konfiguracji aktywno-pasywnej
• Źródłowa baza danych może być tylko bazą danych MySQL, podczas gdy obsługa bazy danych PostgreSQL jako źródła jest eksperymentalna z dalszymi ograniczeniami (kliknij tutaj, aby dowiedzieć się więcej)

pg_kameleon Podsumowanie

Podejście replikacyjne oferowane przez pg_chameleon sprzyja migracji bazy danych MySQL do PostgreSQL. Jednak jedno z istotnych ograniczeń replikacji jednokierunkowej może zniechęcić specjalistów ds. baz danych do zastosowania jej w innych celach niż migracja. Tę wadę replikacji jednokierunkowej można rozwiązać za pomocą jeszcze innego narzędzia typu open source o nazwie SymmetricDS.

Aby bardziej szczegółowo zapoznać się z narzędziem, zapoznaj się z oficjalną dokumentacją tutaj. Informacje o wierszu poleceń można znaleźć tutaj.

Przegląd SymmetricDS

SymmetricDS to narzędzie typu open source, które jest w stanie replikować dowolną bazę danych do dowolnej innej bazy danych, z popularnej listy serwerów baz danych, takich jak Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird i inne instancje baz danych oparte na chmurze, takie jak Redshift i Azure itp. Niektóre z ofert obejmują synchronizację baz danych i plików, replikację z wieloma wzorcami, filtrowaną synchronizację i transformację. Narzędzie zostało opracowane przy użyciu języka Java, wymagającego standardowej edycji (wersja 8.0 lub nowsza) JRE lub JDK. Funkcjonalność polega na przechwytywaniu zmian danych przez wyzwalacze w źródłowej bazie danych i kierowaniu ich do uczestniczącej docelowej bazy danych jako partii wychodzących

Funkcje SymmetricDS

• Niezależne od platformy, co oznacza, że ​​dwie lub więcej odmiennych baz danych może komunikować się ze sobą, każda baza danych z dowolną inną bazą danych
• Relacyjne bazy danych osiągają synchronizację za pomocą przechwytywania danych zmian, podczas gdy systemy oparte na systemie plików wykorzystują synchronizację plików
• Dwukierunkowa replikacja przy użyciu metody Push and Pull, która jest realizowana na podstawie ustalonych reguł
• Transfer danych może również odbywać się w bezpiecznych sieciach o małej przepustowości
• Automatyczne odzyskiwanie podczas wznawiania uszkodzonego węzła i automatyczne rozwiązywanie konfliktów
• Gotowy do chmury i zawiera rozbudowane interfejsy API rozszerzeń

Demo

SymmetricDS można skonfigurować w jednej z dwóch opcji:

• Węzeł nadrzędny (nadrzędny), który działa jako scentralizowany pośrednik koordynujący replikację danych między dwoma węzłami podrzędnymi (podrzędnymi), w którym komunikacja między dwoma węzłami podrzędnymi może odbywać się tylko za pośrednictwem rodzica.
• Aktywny węzeł (węzeł 1) może replikować się do i z innego aktywnego węzła (węzeł 2) bez żadnego pośrednika.

W obu opcjach komunikacja między węzłami odbywa się poprzez zdarzenia „Push” i „Pull”. W tym demo zostanie wyjaśniona konfiguracja aktywny-aktywny między dwoma węzłami. Pełna architektura może być wyczerpująca, dlatego zachęcamy czytelników do zapoznania się z podręcznikiem użytkownika dostępnym tutaj, aby dowiedzieć się więcej o elementach wewnętrznych SymmetricDS.

Instalacja SymmetricDS jest tak prosta, jak pobranie stąd wersji open source pliku zip i rozpakowanie go w dogodnej lokalizacji. Szczegóły lokalizacji instalacji i wersji SymmetricDS w tym demo są zgodne z poniższą tabelą, wraz z innymi szczegółami dotyczącymi wersji baz danych, wersji Linuksa, adresów IP i portu komunikacyjnego dla obu uczestniczących węzłów.

Strona główna instalacji w tym przypadku to „/usr/local/symmetric-server-3.9.20”, która będzie katalogiem domowym SymmetricDS, który zawiera różne inne podkatalogi i pliki. Dwa z podkatalogów, które mają teraz znaczenie, to „próbki” i „silniki”. Katalog przykładów zawiera przykładowe pliki konfiguracyjne właściwości węzła oprócz przykładowych skryptów SQL, aby rozpocząć szybkie demo.

Następujące trzy pliki konfiguracyjne właściwości węzła można zobaczyć w katalogu „samples” z nazwami wskazującymi na charakter węzła w danej konfiguracji.

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

Ponieważ SymmetricDS jest dostarczany ze wszystkimi niezbędnymi plikami konfiguracyjnymi do obsługi podstawowej konfiguracji z 3 węzłami (opcja 1), wygodnie jest użyć tych samych plików konfiguracyjnych do skonfigurowania konfiguracji z 2 węzłami (opcja 2). Zamierzony plik konfiguracyjny jest kopiowany z katalogu „samples” do „silników” na hoście vm1 i wygląda jak poniżej.

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

Nazwa tego węzła w konfiguracji SymmetricDS to „corp-000” z połączeniem z bazą danych obsługiwanym przez sterownik mysql jdbc przy użyciu ciągu połączenia, jak podano powyżej, wraz z danymi logowania. Baza danych do połączenia to „replica_db”, a tabele zostaną utworzone podczas tworzenia przykładowego schematu. „sync.url” wskazuje lokalizację, w której można skontaktować się z węzłem w celu synchronizacji.

Węzeł 2 na hoście vm2 jest skonfigurowany jako „store-001”, a pozostałe szczegóły są skonfigurowane w pliku node.properties, pokazanym poniżej. Węzeł „store-001” uruchamia bazę danych PostgreSQL, z „pgdb_replica” jako bazą danych do replikacji. „registration.url” umożliwia hostowi „vm2” komunikację z hostem „vm1” w celu pobrania 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

Wstępnie skonfigurowana domyślna wersja demonstracyjna SymmetricDS zawiera ustawienia umożliwiające konfigurację dwukierunkowej replikacji między dwoma serwerami baz danych (dwa węzły). Poniższe kroki są wykonywane na hoście vm1 (corp-000), co spowoduje utworzenie przykładowego schematu zawierającego 4 tabele. Ponadto wykonanie polecenia „create-sym-tables” za pomocą polecenia „symadmin” spowoduje utworzenie tabel katalogu, które przechowują i kontrolują reguły oraz kierunek replikacji między węzłami. Na koniec tabele demonstracyjne są ładowane przykładowymi danymi.

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

Tabele demonstracyjne „item” i „item_selling_price” są automatycznie konfigurowane do replikacji z corp-000 do store-001, podczas gdy tabele sprzedaży (sale_transaction i sale_return_line_item) są automatycznie konfigurowane do replikacji ze sklepu-001 do corp-000. Następnym krokiem jest utworzenie przykładowego schematu w bazie danych PostgreSQL na hoście vm2 (store-001), w celu przygotowania go 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

Na tym etapie ważne jest zweryfikowanie istnienia tabel demonstracyjnych i tabel katalogowych SymmetricDS w bazie danych MySQL na vm1. Uwaga, tabele systemowe SymmetricDS (tabele z prefiksem „sym_”) są w tym momencie dostępne tylko w węźle corp-000, ponieważ tam właśnie zostało wykonane polecenie „create-sym-tables”, które będzie miejscem do kontroli i zarządzania replikacją. Ponadto baza danych węzłów store-001 będzie zawierać tylko 4 tabele demonstracyjne bez żadnych danych.

Środowisko jest teraz 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 zarówno do pliku dziennika w tle (symmetric.log) w katalogu dzienników w lokalizacji instalacji SymmetricDS, jak i na standardowe wyjście. 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 &

Uruchomienie procesu serwera „sym” na hoście vm2 spowoduje utworzenie tabel katalogowych SymmetricDS również w bazie danych PostgreSQL. Rozpoczęcie procesu serwera „sym” na obu węzłach spowoduje, że będą one koordynować się ze sobą w celu replikacji danych z corp-000 do store-001. Po kilku sekundach wykonanie kwerendy we wszystkich czterech tabelach po obu stronach spowoduje wyświetlenie pomyślnych wyników replikacji. Alternatywnie, początkowe ładowanie można również wysłać do węzła store-001 z corp-000 za pomocą poniższego polecenia.

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

W tym momencie nowy rekord jest wstawiany do tabeli „item” w bazie danych MySQL w węźle corp-000 (host:vm1) i można zweryfikować, czy został pomyślnie zreplikowany do bazy danych PostgreSQL w węźle store-001 (host:vm2 ). Pokazuje zdarzenie „Pull” 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)

Zdarzenie „Push” danych ze sklepu-001 do corp-000 można osiągnąć, wstawiając rekord do tabeli „sale_transaction” i potwierdzając jego replikację.

pgdb_replica=# insert into "sale_transaction" ("tran_id", "store_id", "workstation", "day", "seq") values (1000, '001', '3', '2007-11-01', 100);
vm1$> [[email protected] ~]#  mysql -uroot -p'admin123' -D replica_db -e "select * from sale_transaction";
+---------+----------+-------------+------------+-----+
| tran_id | store_id | workstation | day        | seq |
+---------+----------+-------------+------------+-----+
|     900 | 001      | 3           | 2012-12-01 |  90 |
|    1000 | 001      | 3           | 2007-11-01 | 100 |
|    2000 | 002      | 2           | 2007-11-01 | 200 |
+---------+----------+-------------+------------+-----+

Oznacza to pomyślną konfigurację dwukierunkowej replikacji tabel demonstracyjnych między bazą danych MySQL i PostgreSQL. Natomiast konfigurację replikacji dla nowo tworzonych tabel użytkowników można osiągnąć wykonując następujące kroki. Na potrzeby demonstracji tworzona jest przykładowa tabela „t1”, a zasady jej replikacji są konfigurowane zgodnie z poniższą procedurą. Kroki konfigurują 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)

Po tym konfiguracja zostanie powiadomiona o zmianie schematu dodania nowej tabeli poprzez wywołanie polecenia symadmin z argumentem „sync-triggers”, który odtworzy wyzwalacze, aby pasowały do ​​definicji tabeli. Następnie wykonaj „send-schema”, aby wysłać zmiany schematu do węzła store-001, po czym replikacja tabeli „t1” zostanie pomyślnie skonfigurowana.

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

Zalety korzystania z SymmetricDS

• Bezproblemowa instalacja i konfiguracja, w tym wstępnie skonfigurowany zestaw plików parametrów do zbudowania konfiguracji 3-węzłowej lub 2-węzłowej
• Włączona wieloplatformowa baza danych i niezależna od platformy, w tym serwery, laptopy i urządzenia mobilne
• Replikuj dowolną bazę danych do dowolnej innej bazy danych, lokalnie, WAN lub w chmurze
• Zdolne do optymalnej obsługi kilku baz danych do kilku tysięcy baz danych w celu płynnej replikacji danych
• Komercyjna wersja oprogramowania oferuje konsolę zarządzania opartą na GUI z doskonałym pakietem wsparcia

Wady korzystania z SymmetricDS

• Ręczna konfiguracja wiersza poleceń może obejmować definiowanie reguł i kierunku replikacji za pomocą instrukcji SQL w celu załadowania tabel katalogu, co może być niewygodne w zarządzaniu
• Ustawienie dużej liczby tabel do replikacji będzie wyczerpującym wysiłkiem, chyba że do wygenerowania instrukcji SQL definiujących zasady i kierunek replikacji zostanie wykorzystana jakaś forma skryptów
• Dużo informacji o logowaniu zaśmiecających plik dziennika, co wymaga okresowej konserwacji pliku dziennika, aby uniemożliwić zapełnienie dysku przez plik dziennika

Podsumowanie SymmetricDS

SymmetricDS oferuje możliwość skonfigurowania replikacji dwukierunkowej między 2 węzłami, 3 węzłami itd. dla kilku tysięcy węzłów w celu replikacji danych i osiągnięcia synchronizacji plików. Jest to unikalne narzędzie, które wykonuje wiele samonaprawiających się zadań konserwacyjnych, takich jak automatyczne odzyskiwanie danych po dłuższych przestojach w węźle, bezpieczna i wydajna komunikacja między węzłami za pomocą HTTPS oraz automatyczne zarządzanie konfliktami w oparciu o ustalone reguły , etc. The essential feature of replicating any database to any other database makes SymmetricDS ready to be deployed for a number of use cases including migration, version and patch upgrade, distribution, filtering and transformation of data across diverse platforms.

The demo was created by referring to the official quick-start tutorial of SymmetricDS which can be accessed from here. The user guide can be found here, which provides a detailed account of various concepts involved in a SymmetricDS replication setup.