Replikacja filtrowana

Replikacja filtrowana synchronizuje tylko wybrane wiersze lub kolumny artykułu, według zdefiniowanego warunku.

Na czym polega replikacja filtrowana

Replikacja filtrowana to mechanizm kopiowania tylko określonego podzbioru danych z jednego systemu do drugiego. Zamiast przekazywać całą tabelę, bazę albo kompletny zbiór zmian, system replikuje rekordy spełniające zdefiniowany warunek. Filtrowanie może dotyczyć wierszy, kolumn albo obu tych elementów jednocześnie. Przykładowo do repliki mogą trafiać wyłącznie rekordy dotyczące konkretnego oddziału, zakresu dat lub statusu, a z każdej tabeli można przekazywać tylko kolumny potrzebne aplikacji raportowej.

Warunek filtrowania jest oceniany względem danych źródłowych albo względem rejestrowanych zmian, zależnie od architektury konkretnego silnika. W praktyce oznacza to, że mechanizm musi rozstrzygnąć nie tylko, czy nowy rekord spełnia warunek, lecz także co zrobić po zmianie wartości używanej w filtrze. Rekord może wtedy zostać dopisany do repliki, usunięty z niej albo zaktualizowany. Replikacja filtrowana nie jest więc zwykłym jednorazowym eksportem, lecz regułą obowiązującą podczas dalszej synchronizacji.

Filtrowanie wierszy, kolumn i zmian

Filtr wierszy ogranicza zakres rekordów przekazywanych do odbiorcy. Warunek może opierać się na jednej kolumnie lub na kilku kolumnach połączonych operacjami logicznymi. Jeżeli tabela zawiera dane wielu jednostek organizacyjnych, filtr może wybierać jeden identyfikator jednostki. W innym zastosowaniu może ograniczać zbiór do rekordów oznaczonych jako aktywne albo utworzonych w określonym przedziale czasu. Należy jednak rozróżnić filtr trwały od warunku używanego wyłącznie przy początkowym kopiowaniu: nie każdy mechanizm stosuje tę samą regułę do późniejszych zmian.

Filtr kolumn usuwa z repliki wskazane pola albo pozostawia tylko kolumny dozwolone przez konfigurację. Zmniejsza to rozmiar przesyłanych danych, ale może wpływać na możliwość odtworzenia operacji po stronie odbiorcy. Kolumna pominięta w replice może być potrzebna do identyfikacji rekordu, kontroli zależności, spełnienia ograniczeń integralności lub obliczenia warunku filtrowania. Dlatego konfiguracja musi uwzględniać klucze oraz pola wymagane przez sam mechanizm replikacji, nawet jeśli nie są wyświetlane użytkownikom końcowym.

Spójność po zmianie warunku

Najwięcej problemów pojawia się wtedy, gdy rekord przestaje spełniać filtr albo zaczyna go spełniać po aktualizacji. Jeżeli zmieniona zostanie kolumna określająca przynależność rekordu do repliki, odbiorca musi otrzymać informację o odpowiedniej zmianie zakresu danych. W zależności od rozwiązania może to oznaczać usunięcie rekordu z repliki, jego dodanie albo wykonanie pełniejszej synchronizacji. Samo filtrowanie nie gwarantuje automatycznie, że wszystkie zależności między tabelami pozostaną zachowane.

Przykładowo tabela zamówień może zostać ograniczona do jednego regionu, podczas gdy tabela pozycji zamówień będzie zawierała rekordy zależne od zamówień z wielu regionów. Taka konfiguracja może prowadzić do osieroconych wierszy, błędów kluczy obcych albo niepełnych wyników zapytań. Przy projektowaniu filtrów trzeba więc przeanalizować relacje, klucze główne, klucze obce, indeksy oraz kolejność stosowania zmian. Istotne jest także ustalenie, czy odbiorca ma być tylko do odczytu, czy może sam modyfikować replikowane dane. Dwukierunkowa synchronizacja wymaga dodatkowych zasad rozstrzygania konfliktów i nie wynika automatycznie z samego filtrowania.

Dobór i kontrola konfiguracji repliki

Przed uruchomieniem replikacji filtrowanej warto określić dokładny zakres danych, częstotliwość zmian oraz wymagania dotyczące kompletności. Filtr powinien być jednoznaczny, stabilny i możliwie tani w wykonaniu. Warunki oparte na nieindeksowanych kolumnach mogą zwiększać koszt odczytu i obciążać system źródłowy. Z kolei filtr zależny od czasu może powodować, że rekordy z czasem opuszczają replikę, co wymaga świadomego zaplanowania retencji i obsługi aktualizacji.

Kontrola działania powinna obejmować porównywanie liczby rekordów, identyfikatorów oraz sum kontrolnych wybranych kolumn po obu stronach. Należy sprawdzać zarówno nowe rekordy, jak i aktualizacje zmieniające wartości używane w filtrze. Warto również monitorować opóźnienie synchronizacji, błędy walidacji, odrzucone zmiany i stan początkowego kopiowania. Test powinien obejmować przypadki graniczne: rekord spełniający warunek, rekord niespełniający warunku, zmianę klasyfikacji oraz usunięcie danych źródłowych.

Replikacja filtrowana jest przydatna wtedy, gdy odbiorca potrzebuje tylko określonego wycinka danych, lecz wymaga precyzyjnego zaprojektowania reguł. Błędny filtr może dać replikę pozornie działającą, ale niekompletną albo niespójną z powiązanymi tabelami. W środowisku, w którym występują problemy z synchronizacją, należy analizować konfigurację źródła i odbiorcy, dzienniki zmian, definicje filtrów oraz zależności między tabelami, a nie tylko pojedynczy komunikat o błędzie.