CDC DDL
Moduł odpowiedzialny za replikację schematów tabel na bazach danych.
Moduł GOLDENORE CDC DDL (Data Definition Language) odpowiada za replikację schematów tabel z baz danych Oracle za pomocą konektora źródłowego (Debezium Connector for Oracle).
Czym jest DDL?
DDL (Data Definition Language) - grupa instrukcji w języku SQL, służących do definiowania struktur danych. Możemy zaliczyć do nich polecenia takie jak CREATE, ALTER i DROP. Za pomocą instrukcji DDL nie zmieniamy danych na tabeli ale jej strukturę.
Przykłady
CREATE TABLE ot.persons(
person_id NUMBER GENERATED BY DEFAULT AS IDENTITY,
first_name VARCHAR2(50) NOT NULL,
last_name VARCHAR2(50) NOT NULL,
PRIMARY KEY(person_id)
);
ALTER TABLE ot.persons ADD birth_date DATE NOT NULL;
ALTER TABLE ot.persons DROP COLUMN last_name;Jak działa replikacja DDL?
Replikacja w dużym uproszczeniu polega na kopiowaniu tabel z jednej bazy na drugą. Do wykonania tego potrzebujemy rozwiązania, które będzie monitorowało zmiany schematów na źródłowej bazie i wysyłało informację o zmianach na bazę docelową. Używamy do tego mechanizmu Apache Kafka, a dokładniej do monitorowania zmian i wysyłania informacji o nich, używamy konektora źródłowego Debezium Connector for Oracle.
Debezium Connector for Oracle
Zadaniem konektora jest przechwytywanie zmian na bazie danych Oracle i wysłanie takich informacji do Kafki. Konektor można skonfigurować, aby przechwytywał zmiany dla określonego zbioru schematów i tabel oraz ignorował konkretne schematy czy tabele.
Schema change topic
Jedną z informacji, które się przechwytuje jest właśnie informacja o zmianach schematów, a wysyłane są one na tak zwany "Schema change topic". Wysyłane są do niego informacje o zmianach schematów tabel, które są uwzględnione w monitorowaniu. Nazwa tego topicu określona jest w konfiguracji konektora, pod polem:
"schema.history.internal.kafka.topic"Zasada działania modułu DDL
W momencie dodania nowego konektora docelowego lub zmiany konfiguracji w istniejącym konektorze docelowym, aby aktywna była replikacja DDL, wysyłany jest komunikat do modułu DDL z informacjami:
nazwa konektora
konfiguracja
czy będą wykonywane DDL'e z tzw. "przeszłości"
Następnie sprawdzamy czy jest już aktywna replikacja dla danego konektora, jeśli nie to rozpoczynamy replikację, a w przeciwnym wypadku restartujemy replikację uwzględniając nową konfigurację.
Gdy replikacja jest już aktywna, nasłuchiwany jest schema.history.internal.kafka.topic i odpowiednie zmiany pojawiające się, zostają wykonane na docelowej bazie danych.
Execute history i Offset
Konektor źródłowy Debezium dla Oracle wysyła zmiany DDL na topic Kafki niezależnie czy mamy utworzony konektor docelowy. Może dojść do takiej sytuacji, w której nie będzie aktywnej replikacji DDL dla żadnego konektora docelowego, a zmiany DDL będą wysyłane na topic Kafki. Następnie po utworzeniu konektora docelowego z aktywną replikacją DDL, musimy zdecydować czy chcemy wykonać na bazie docelowej zmiany schematów, które zachodziły przed utworzeniem czy chcemy, aby replikowane były tylko zmiany, które dopiero się pojawią. Do tego służy zmienna Execute history, określając czy chcemy wykonać zmiany schematów "z przeszłości".
transforms.route.replacement
Replikując informacje między bazami danych mamy następujące informacje:
Nazwa bazy danych ($1)
Nazwa schematu ($2)
Nazwa tabeli ($3)
Zmienna transforms.route.replacement określa gdzie będzie zapisana replikowana informacja na bazie docelowej. Domyślnie jest to nazwa_schematu.nazwa_tabeli ($2.$3) ale można chcieć zapisywać np. na docelowej bazie danych na inny schemat. Wtedy ustawiamy naszą zmienną na:
"transforms.route.replacement": "inna_nazwa_schematu.$3"Restartowanie konektora przy ALTER TABLE ... ADD ...
Przy wykonywaniu na bazie źródłowej zapytania zawierającego ALTER TABLE ... ADD ... trzeba zrestartować konektor docelowy, a dokładniej usunąć i utworzyć na nowo. Spowodowane jest to tym, że konektor docelowy pobiera schemat bazy danych w momencie utworzenia i potem go nie aktualizuje. Oznacza to, że jeśli w trakcie jego działania dodamy nową kolumnę, nie będzie on o tym wiedział i przy najbliższym dodaniu danych do bazy, przy próbie zreplikowania danych na bazę docelową, zostanie wyrzucony błąd, ponieważ konektor docelowy będzie próbował dodać dane do kolumny, która nie istnieje.
Szczegóły kontenera
Nazwa obrazu
cdc-ddl
Nazwa w repozytorium
goldenore/cdc/ddl
Port
8082
Zależność
PostgreSQL Database
Last updated