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.

Schemat działania replikacji DDL

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"

Więcej informacji na temat konektora Debezium dla Oracle znajduje się w dokumentacji: https://debezium.io/documentation/reference/stable/connectors/oracle.html#oracle-overview

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".

Dla wartości "true" zostaną wykonane zmiany schematów "z przeszłości", a dla wartości "false" będą wykonane tylko przyszłe zmiany.

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

Właściwości	docker
Nazwa obrazu	cdc-ddl
Nazwa w repozytorium	goldenore/cdc/ddl
Port	8082
Zależność	PostgreSQL Database