Replikacja jednostronna

Replikacja jednostronna przekazuje zmiany wyłącznie od wydawcy do subskrybentów, bez zapisu w drugą stronę.

Jak działa przepływ zmian w replikacji jednostronnej

Replikacja jednostronna to model synchronizacji, w którym jeden system pełni rolę wydawcy, a pozostałe systemy są subskrybentami. Wydawca jest źródłem zmian, natomiast subskrybenci otrzymują przekazywane dane i odtwarzają je we własnych zasobach. Kierunek przepływu jest określony z góry: od wydawcy do subskrybentów. Modyfikacja wykonana na subskrybencie nie staje się automatycznie zmianą źródłową i nie wraca do wydawcy w ramach tego samego mechanizmu.

Źródłem replikowanych zmian mogą być między innymi operacje dodawania, aktualizowania i usuwania rekordów. System replikacyjny musi wykryć taką zmianę, zapisać informację potrzebną do jej przekazania, dostarczyć ją do subskrybenta oraz zastosować w odpowiedniej kolejności. W zależności od rozwiązania informacje o zmianach są pobierane z dziennika transakcyjnego, mechanizmu śledzenia zmian albo innego rejestru prowadzonego przez oprogramowanie. Replikacja nie jest więc zwykłym kopiowaniem całego katalogu lub pliku, lecz kontrolowanym przenoszeniem określonych zmian pomiędzy instancjami.

Role wydawcy, subskrybenta i procesu dostarczania

Wydawca przechowuje dane referencyjne i udostępnia zmiany do dalszego rozpowszechniania. Subskrybent utrzymuje lokalną kopię danych, która może służyć do odczytu, raportowania, wyszukiwania albo pracy aplikacji zależnej od aktualnego obrazu źródła. Pomiędzy tymi elementami działa proces dostarczający, odpowiedzialny za odczyt zmian, przesłanie ich przez sieć i wykonanie po stronie odbiorcy. W praktyce mogą występować także składniki pośrednie, takie jak kolejka, bufor albo repozytorium przejściowe.

Ważną cechą tego modelu jest rozdzielenie prawa do modyfikowania danych od prawa do ich odczytu. Subskrybent może być technicznie dostępny dla użytkowników, ale jego lokalne zmiany nie powinny być traktowane jako równorzędne ze zmianami w wydawcy. Jeżeli aplikacja zapisuje dane jednocześnie w kilku kopiach, jednostronna replikacja nie rozwiązuje konfliktów między tymi zapisami. Może natomiast zapewnić przewidywalny kierunek aktualizacji, pod warunkiem że zapisy źródłowe są wykonywane w jednym, jasno określonym miejscu.

Opóźnienia, kolejność i niespójność kopii

Replikacja jednostronna może działać synchronicznie albo asynchronicznie, zależnie od zastosowanego systemu. W wariancie synchronicznym potwierdzenie operacji może zależeć od zapisania danych także po stronie odbiorcy, co ogranicza ryzyko utraty ostatnich zmian, ale zwiększa zależność wydajności od sieci i dostępności subskrybenta. W wariancie asynchronicznym wydawca może potwierdzić zapis przed zastosowaniem go na subskrybencie. Powstaje wtedy opóźnienie replikacji, czyli czas pomiędzy pojawieniem się zmiany u wydawcy a jej widocznością u odbiorcy.

Chwilowa różnica między kopiami nie musi oznaczać awarii. Może wynikać z obciążenia procesu dostarczającego, przerwy sieciowej, dużej liczby zmian albo wolnego wykonania operacji na subskrybencie. Problem pojawia się wtedy, gdy zaległości rosną, przesyłanie zatrzymuje się lub zmiany są odrzucane. Podczas diagnostyki sprawdza się między innymi czas ostatniej poprawnie zastosowanej zmiany, liczbę oczekujących operacji, błędy połączenia, dostępność miejsca oraz zgodność schematu danych. Należy również ustalić, czy usunięcie rekordu u wydawcy jest prawidłowo przekazywane do subskrybenta, ponieważ pozostawione rekordy mogą powodować pozorną zgodność przy jednoczesnym narastaniu nieaktualnych danych.

Kontrola poprawności i zastosowania praktyczne

Jednostronna replikacja jest przydatna wtedy, gdy potrzebna jest dodatkowa kopia danych bez wprowadzania wielokierunkowego zapisu. Subskrybent może obsługiwać odczyty, generowanie raportów lub lokalną pracę aplikacji, a główny system pozostaje miejscem, w którym zatwierdzane są zmiany. Takie rozdzielenie pomaga ograniczyć obciążenie wydawcy, lecz nie zastępuje automatycznie kopii zapasowej. Replika może bowiem odziedziczyć błędne usunięcie, uszkodzoną zmianę albo opóźnienie, dlatego procedura odtwarzania powinna być testowana niezależnie.

Podczas sprawdzania działania replikacji warto porównać kontrolowaną liczbę rekordów, znaczniki czasu lub identyfikatory ostatnich zmian po obu stronach. Trzeba też zweryfikować, czy proces po przerwie potrafi wznowić pracę bez pomijania operacji oraz czy ponowne zastosowanie tej samej zmiany nie prowadzi do niepożądanego duplikowania danych. Istotne są również uprawnienia techniczne, stabilność połączenia, wolne miejsce na dzienniki i jasne rozróżnienie między błędem transmisji a błędem zapisu. W środowisku z laptopem lub komputerem PC takie mechanizmy zwykle znajdują się poza lokalnym sprzętem użytkownika, na serwerze albo w usłudze bazodanowej. Diagnostyka komputera może jednak obejmować sprawdzenie połączenia sieciowego, klienta używanego przez aplikację, komunikatów systemowych oraz tego, czy urządzenie otrzymuje aktualne dane z właściwego subskrybenta.