Artykuł replikacji

Artykuł replikacji to pojedynczy obiekt bazy danych, taki jak tabela lub procedura, objęty procesem synchronizacji danych.

Rola artykułu replikacji w bazie danych

Artykuł replikacji to pojedynczy obiekt bazy danych objęty mechanizmem synchronizacji między co najmniej dwoma jej wystąpieniami. W zależności od użytej technologii takim obiektem może być tabela, widok, procedura składowana, funkcja albo inny element schematu, jednak najczęściej replikowane są tabele zawierające dane operacyjne. Artykuł nie oznacza całej bazy ani całego serwera. Jest konkretną jednostką wybraną do przesyłania zmian, dzięki czemu replikacja może obejmować tylko potrzebny zakres danych.

W konfiguracji replikacji artykuł jest zwykle przypisany do publikacji, zestawu synchronizowanych obiektów lub podobnej struktury konfiguracyjnej. Po stronie źródłowej określa się, jakie dane mają być udostępniane, a po stronie docelowej wskazuje się sposób ich odtworzenia. Definicja artykułu może obejmować nazwę obiektu, zakres kolumn, filtr wierszy, sposób mapowania nazw oraz reguły przetwarzania zmian. Szczegółowe możliwości zależą od konkretnego silnika bazy danych, dlatego ustawień jednego systemu nie należy automatycznie przenosić do innego.

Jakie informacje opisują synchronizowany obiekt

Najważniejszym elementem artykułu jest wskazanie obiektu źródłowego, na przykład tabeli wraz ze schematem i nazwą. W przypadku tabeli istotne są również kolumny, klucz główny oraz zależności wykorzystywane do jednoznacznego identyfikowania wierszy. Mechanizm replikacji musi wiedzieć, którą zmianę zastosować w miejscu docelowym, dlatego brak stabilnego identyfikatora może ograniczać dostępne tryby synchronizacji albo wymagać dodatkowej konfiguracji.

Artykuł może określać, czy przekazywane są wszystkie wiersze, czy tylko podzbiór wybrany przez warunek filtrujący. Filtrowanie poziome ogranicza liczbę replikowanych rekordów, natomiast filtrowanie pionowe może ograniczać zestaw kolumn. Trzeba przy tym uwzględnić zależności między tabelami. Przeniesienie tabeli podrzędnej bez odpowiadających jej rekordów nadrzędnych może prowadzić do naruszenia kluczy obcych lub do niespójnych danych. Również zmiana definicji tabeli, dodanie kolumny albo modyfikacja typu danych może wymagać osobnego procesu aktualizacji konfiguracji replikacji.

Przepływ zmian od źródła do celu

Po zapisaniu transakcji w bazie źródłowej informacja o zmianie musi zostać zarejestrowana w sposób obsługiwany przez dany mechanizm replikacji. Następnie zmiana jest odczytywana, przygotowywana do przesłania i przekazywana do systemu docelowego. W zależności od architektury może być stosowana replikacja synchroniczna albo asynchroniczna. W pierwszym wariancie potwierdzenie operacji może zależeć od zapisania zmiany w wielu miejscach, natomiast w drugim źródło i cel mogą przez pewien czas zawierać różne wersje danych.

Artykuł replikacji nie jest kopią wykonywaną jednorazowo. Zwykle obejmuje początkowe utworzenie danych w miejscu docelowym, a następnie obsługę kolejnych operacji, takich jak INSERT, UPDATE i DELETE. Jeżeli przesyłanie zmian zostanie przerwane, system może gromadzić oczekujące rekordy, znaczniki albo informacje w dzienniku zmian. Po przywróceniu komunikacji konieczne jest sprawdzenie, czy zaległe operacje zostały zastosowane we właściwej kolejności. Opóźnienie między zatwierdzeniem zmiany a jej pojawieniem się w bazie docelowej określa się jako lag replikacji.

Kontrola spójności i diagnostyka artykułu

Diagnostyka artykułu replikacji powinna zaczynać się od potwierdzenia, że wskazany obiekt istnieje po stronie źródłowej i docelowej oraz ma zgodny schemat. Następnie sprawdza się stan procesu synchronizacji, liczbę oczekujących zmian, ostatni poprawnie przetworzony punkt oraz komunikaty błędów. Szczególnie ważne są błędy dotyczące uprawnień, niedostępności połączenia, konfliktu kluczy, niezgodnych typów danych i braku miejsca na dzienniki lub pliki tymczasowe.

Sama obecność obiektu w bazie docelowej nie potwierdza poprawnej replikacji. Należy porównać wybrane dane, sprawdzić świeżość ostatniej zmiany oraz zweryfikować, czy operacje usunięcia i aktualizacji są obsługiwane tak samo jak dodawanie rekordów. W systemach wieloźródłowych trzeba dodatkowo analizować konflikty, czyli sytuacje, w których ten sam rekord został zmieniony niezależnie w kilku miejscach. Przy planowaniu naprawy należy zachować ostrożność, ponieważ ponowne zainicjalizowanie artykułu lub ręczne usuwanie kolejki zmian może spowodować utratę oczekujących operacji. Poprawna procedura zależy od silnika bazy danych, rodzaju replikacji i sposobu prowadzenia dziennika zmian.