Przygotowanie baz danych do replikacji

Do działania pełnego przepływu replikacyjnego należy wykonać czynności na bazie źródłowej oraz docelowej, przed uruchomieniem mechanizmu replikacji.

Pamiętaj aby upewnić się, że posiadasz:

Dostęp sieciowy do źródłowej bazy danych GOCDC
Dostęp sieciowy do docelowej bazy danych z maszyny hostującej GOCDC

Bazy źródłowe

PostgreSQL

W celu odczytywania i przetwarzania zmian w bazie danych należy posiadać Plug-in wyjścia dekodowania logicznego. Może być konieczne zainstalowanie wybranego plug-in wyjściowego. Przed uruchomieniem serwera PostgreSQL należy skonfigurować plug-in replikacji, które korzysta z wybranego plug-in wyjściowego. Plug-in może być jednym z następujących:

decoderbufsjest oparty na Protobuf i utrzymywany przez społeczność Debezium.
pgoutputto standardowa wtyczka wyjściowa dekodowania logicznego w PostgreSQL 10+. Jest utrzymywany przez społeczność PostgreSQL i używany przez sam PostgreSQL do replikacji logicznej . Ta wtyczka jest zawsze obecna, więc nie trzeba instalować żadnych dodatkowych bibliotek. Konektor Debezium interpretuje surowy strumień zdarzeń replikacji bezpośrednio na zdarzenia zmian.

Zanim użyjesz konektora PostgreSQL do monitorowania zmian wprowadzonych na serwerze PostgreSQL, zdecyduj, której wtyczki do dekodowania logicznego zamierzasz użyć. Jeśli planujesz nie używać natywnej pgoutputobsługi strumienia replikacji logicznej, musisz zainstalować wtyczkę dekodowania logicznego na serwerze PostgreSQL. Następnie włącz gniazdo replikacji i skonfiguruj użytkownika z uprawnieniami wystarczającymi do przeprowadzenia replikacji.

Obecnie obsługiwane są tylko bazy danych z kodowaniem znaków UTF-8. W przypadku kodowania znaków jednobajtowych nie jest możliwe prawidłowe przetwarzanie ciągów znaków zawierających rozszerzone znaki kodu ASCII.

Czynności potrzebne do uruchomienia mechanizmu cdc

Włączenie mechanizmu replikacji : Logical Replication

SELECT * from pg_settings where name ='wal_level';

Powyższa komenda sprawdza wal_level.

ALTER SYSTEM SET wal_level = logical;

Powyższa komenda zmienia w PostgreSQL wal_level na logical. Pamiętaj po zmianie wymagane jest zrestartowanie kontenera bazy danych.

Oracle

Niezbędne są następujące konfiguracje:

Archive logs
Redo logs
Supplemental logging
Users and tablespaces/schemas in CDB and PDB

Archive logs

SELECT LOG_MODE FROM V$DATABASE

Jeśli kolumna zawiera ARCHIVELOG, rejestrowanie archiwum jest włączone. Jeśli kolumna zawiera wartość NOARCHIVELOG, rejestrowanie archiwum nie jest włączone i konieczna jest dalsza konfiguracja.

Ograniczenia

Virtual Columns - Obecnie w replikacji nie wspieramy tego typu kolumny. Wszystkie operacje Insert, Update będę powodowały ustwienie pola na wartość null.

Aktywacja trybu ARCHIVELOG na bazie danych

Na początek trzeba ustawić dwa parametry:

db_recovery_file_dest_size - ilość pamięci do przechowywania logów
db_recovery_file_dest - lokalizacja na dysku, gdzie logi będą przechowywane

Aby ustawić poniższe wartości, zmienić tryb bazy oraz sprawdzić czy tryb bazy danych się zmienił, należy wykonać poniższe polecenia:

ALTER SYSTEM SET db_recovery_file_dest_size = 10G;
ALTER SYSTEM SET db_recovery_file_dest = '/opt/oracle/oradata/ORCLCDB' scope=spfile;
SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
ARCHIVE LOG LIST;

Redo logs

Dostępne są dwie strategie dla redo logów:

redo_log_catalog - okresowe dopisywanie danych do logów
online_catalog - dane do logów nie są dopisywanie okresowo.

Jeśli chcesz śledzić zmiany DDL, musisz mieć aktywną strategię redo_log_catalog.

W celu poprawienia jakości działania logów, kluczowe jest, aby zmiejszyć częstość zmiany grupy logów, poprzez zwiększenie rozmiaru logów do 400MB (domyślnie jest to 200MB).

Aby sprawdzić swoje grupy i ich rozmiar należy wykonać polecenie:

SELECT GROUP#, BYTES/1024/1024 SIZE_MB, STATUS FROM V$LOG ORDER BY 1;

Przykładowy wynik:

    GROUP#    SIZE_MB STATUS
---------- ---------- ----------------
	 1	  200 INACTIVE
	 2	  200 INACTIVE
	 3	  200 CURRENT

Powyższy wynik mówi nam, że mamy 3 grupy po 200MB każda. Status grupy oznacza:

INACTIVE - Oracle zainicjalizowało grupę logów i nie jest aktualnie w użyciu
ACTIVE - Oracle zainicjalizowało grupę logów i jest aktualnie w użyciu
CURRENT - Oracle aktualnie zapisuje dane do tej grupy logów
UNUSED - Oracle nie zainicjalizowało grupy logów i nie jest aktualnie w użyciu

Następnie, aby móc dokonać zmiany, musimy wiedzieć jaka jest lokalizacja na dysku dla poszczególnych grup logów. Możemy to sprawdzić za pomocą polecenia:

SELECT GROUP#, MEMBER FROM V$LOGFILE ORDER BY 1, 2;

Przykładowy wynik:

    GROUP# MEMBER
---------- ---------------------------------------------------
	 1 /opt/oracle/oradata/ORCLCDB/redo01.log
	 2 /opt/oracle/oradata/ORCLCDB/redo02.log
	 3 /opt/oracle/oradata/ORCLCDB/redo03.log

Aby zmienić rozmiar grupy logów należy ją usunąć i stworzyć na nowo z rozmiarem 400MB. Usunięcie grupy logów jest możliwe tylko jeśli jest ona w stanie INACTIVE lub UNUSED. W naszym przypadku grupa 1 jest w stanie INACTIVE, więc musimy wyczyścić grupę, usunąć i stworzyć na nowo:

ALTER DATABASE CLEAR LOGFILE GROUP 1;
ALTER DATABASE DROP LOGFILE GROUP 1;
ALTER DATABASE ADD LOGFILE GROUP 1 ('/opt/oracle/oradata/ORCLCDB/redo01.log') size 400M REUSE;

Taką operację należy wykonać dla każdej grupy. Aby zmienić aktualnie używaną grupę należy wykonać polecenie:

ALTER SYSTEM SWITCH LOGFILE;

Supplemental Logging

Ponieważ Debezium polega na LogMiner, supplemental logging musi być aktywowane, aby przechwytywać zmiany danych dla Oracle. Dostępne są dwie strategie:

Database supplemental logging
Table supplemental logging

Minimalne ustawienie do działana replikacji wymaga ustawienia strategii Database Supplemental Logging:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Użytkownik replikacyjny

Aby konektor Debezium Oracle mógł przechwytywać zdarzenia zmiany danych, musi być uruchomiony za pomocą użytkownika posiadającego odpowiednie uprawnienia.

Poniżej przedstawiony jest proces tworzenia użytkownika:

sqlplus sys/top_secret@//localhost:1521/ORCLCDB as sysdba
  CREATE TABLESPACE logminer_tbs DATAFILE '/opt/oracle/oradata/ORCLCDB/logminer_tbs.dbf'
    SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
  exit;

sqlplus sys/top_secret@//localhost:1521/ORCLPDB1 as sysdba
  CREATE TABLESPACE logminer_tbs DATAFILE '/opt/oracle/oradata/ORCLCDB/ORCLPDB1/logminer_tbs.dbf'
    SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
  exit;

sqlplus sys/top_secret@//localhost:1521/ORCLCDB as sysdba

  CREATE USER c##dbzuser IDENTIFIED BY dbz
    DEFAULT TABLESPACE logminer_tbs
    QUOTA UNLIMITED ON logminer_tbs
    CONTAINER=ALL;

  GRANT CREATE SESSION TO c##dbzuser CONTAINER=ALL;
  GRANT SET CONTAINER TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ON V_$DATABASE to c##dbzuser CONTAINER=ALL;
  GRANT FLASHBACK ANY TABLE TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ANY TABLE TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT_CATALOG_ROLE TO c##dbzuser CONTAINER=ALL;
  GRANT EXECUTE_CATALOG_ROLE TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ANY TRANSACTION TO c##dbzuser CONTAINER=ALL;
  GRANT LOGMINING TO c##dbzuser CONTAINER=ALL;

  GRANT CREATE TABLE TO c##dbzuser CONTAINER=ALL;
  GRANT LOCK ANY TABLE TO c##dbzuser CONTAINER=ALL;
  GRANT CREATE SEQUENCE TO c##dbzuser CONTAINER=ALL;

  GRANT EXECUTE ON DBMS_LOGMNR TO c##dbzuser CONTAINER=ALL;
  GRANT EXECUTE ON DBMS_LOGMNR_D TO c##dbzuser CONTAINER=ALL;

  GRANT SELECT ON V_$LOG TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ON V_$LOG_HISTORY TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ON V_$LOGMNR_LOGS TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ON V_$LOGMNR_CONTENTS TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ON V_$LOGMNR_PARAMETERS TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ON V_$LOGFILE TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ON V_$ARCHIVED_LOG TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ON V_$ARCHIVE_DEST_STATUS TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ON V_$TRANSACTION TO c##dbzuser CONTAINER=ALL;

  GRANT SELECT ON V_$MYSTAT TO c##dbzuser CONTAINER=ALL;
  GRANT SELECT ON V_$STATNAME TO c##dbzuser CONTAINER=ALL;

W celu uzyskania szczegółowych informacji dotyczących poszczególnych uprawnień, proszę udać się na stronę: https://debezium.io/documentation/reference/stable/connectors/oracle.html#creating-users-for-the-connector

SQL Server

Bazy docelowe

Wspierane bazy docelowe to bazy relacyjne:

Oracle
PostgreSQL
SQL Server
SQLite

Aby bezpiecznie korzystać z konektorów docelowych, zaleca się stworzenie użytkownika na bazie docelowej z uprawnieniami przedstawionymi poniżej:

CREATE USER dbzuser IDENTIFIED BY dbz
DEFAULT TABLESPACE USERS
QUOTA UNLIMITED ON USERS
 
GRANT select, update, insert, delete any table to dbzuser

PreviousWdrażanie NextUruchomienie oprogramowanie

Last updated 1 month ago