W imię spójności
-
- Tomasz Kopacz,
- 01.03.2004
Tak naprawdę replikacja ma na celu przeniesienie "dokumentów biznesowych", a transport danych z tabel jest tylko środkiem do osiągnięcia tego celu. Można - zamiast w ogóle tworzyć mechanizmy na poziomie bazy danych - zdefiniować interfejsy przekazywania dokumentów pomiędzy systemami w oddziałach i centrali. Warto pamiętać, że większość baz danych łatwo współpracuje z pakietami do tworzenia usług sieciowych i pozwala udostępnić kwerendy/procedury przechowywane tak, by można się było do nich odwołać jak za pośrednictwem HTTP.
Zamiast wykorzystywać standardowy "pakiet do replikacji", można go napisać samodzielnie. Większość baz danych oferuje pewne mechanizmy, które takie operacje ułatwią (DTS, import/eksport danych do różnych schematów itp.). Są też zestawy narzędzi ułatwiających tworzenie tego typu rozwiązań.
Dobrym przykładem jest seria produktów SQL Compare firmy Red Gate. Można się nimi posłużyć jak narzędziami "ostatniego ratunku". Pakiet pozwala szybko porównać zawartość/schemat 2 baz danych i natychmiast przygotować listę konfliktów - czy to w danych, czy w schemacie bazy.
Ta sama funkcjonalność jest dostępna również programistom za pośrednictwem SQL Toolkit. Pakiet zawiera wiele gotowych "klocków", które można złożyć we własne rozwiązanie. W ten sposób to, co zwykle jest wykonywane ręcznie, można zautomatyzować - zarówno fazę okresowego przenoszenia danych, jak i rozwiązywania konfliktów. SQL Compare nie wymaga instalowania dodatkowych struktur danych w bazach itp. Jest produktem, który działa "z zewnątrz" bazy - automatycznie analizuje, co tak naprawdę trzeba przenieść.
Bez ideału
Bez względu na zastosowane rozwiązania i używane narzędzia replikacja jest złożonym i skomplikowanym problemem. Trudno tu o rozwiązanie uniwersalne, a tym bardziej o takie, które nie ma żadnych niedogodności. Replikacja to zagadnienie z pogranicza rozproszonych transakcji i integracji systemów - granica między tymi zagadnieniami jest bardzo płynna.
Najmniej problemów, a w zasadzie brak problemów z replikacją występuje jedynie w sytuacji, gdy baza docelowa (przyjmująca dane) jest skonfigurowana "tylko do odczytu". Tylko wtedy unika się problemów ze spójnością i konfliktów, które nieodłącznie towarzyszą replikowaniu tych samych danych do wielu lokalizacji.
Jeżeli zdalni użytkownicy (np. pracownicy oddziału terenowego) nie mogą samodzielnie wpływać na zawartość lokalnych baz, z punktu widzenia architektury systemu sytuacja jest wręcz idealna. Szkopuł w tym, że takie rozwiązanie techniczne jest zwykle nie do zaakceptowania z punktu widzenia potrzeb biznesowych.
Podstawowy problem z replikacją jest związany z konfliktami, które wynikają z równoległej aktualizacji tych samych danych w różnych lokalizacjach. W przypadku firmy handlowej z wieloma oddziałami może być tak, że cennik i asortyment są narzucane przez centralę. W takim przypadku można opublikować widok "tylko do odczytu" dla wszystkich oddziałów. Jeżeli każdy oddział może samodzielnie wprowadzać klientów, może się zdarzyć - że dwa oddziały wprowadzą tę samą osobę jako różnych klientów - coś, co w "porządnym" systemie nie powinno się zdarzyć. Innym przykładem, w którym pojawi się konflikt, może być operacja wystawienia/korygowania faktury. Jeżeli np. centrala poprawi coś w dokumencie, a równocześnie oddział wprowadzi własne modyfikacje - przy synchronizacji danych natychmiast pojawi się problem.
Dużą część konfliktów przy replikacji można rozwiązać nie na poziomie technologicznym, ale organizacji pracy, np. przyjmując, że jeżeli oddział wystawi fakturę i prześle ją do centrali, to tylko centrala może go zmienić. Nawet jednak mimo takich zabiegów, wyjątki będą się zdarzać. Aby było ich jak najmniej, replikację trzeba uwzględnić już na etapie projektowania aplikacji. Można oczywiście przyjąć, że zwykle konfliktów nie ma. Jeśli się pojawią, ich rozstrzygnięcie leży w gestii administratora bazy lub innej wskazanej osoby. W większości przypadków od systemów oczekuje się jednak większej "inteligencji".
Pierwszy i najprostszy sposób unikania konfliktów to zapewnienie prawidłowych kluczy głównych w replikowanej tabeli. Rozwiązań w tym względzie jest wiele. Można np. skorzystać z liczb typu GUID - globalnych unikatowych identyfikatorów generowanych na podstawie odpowiednich algorytmów z uwzględnieniem np. adresu MAC karty sieciowej. Alternatywnie zakres identyfikatorów można podzielić pomiędzy punkty, które się replikują - np. oddział I ma zakres 0-1000, II - 1001-2000 itp. Nie zabezpieczy to jednak przed utworzeniem w dwu oddziałach dwóch identycznych klientów z dwoma różnymi identyfikatorami.
W przypadku konfliktów aktualizacji/usunięcia często jest stosowane kryterium "wagi". Przykładowo, aktualizacje centrali mogą neutralizować zmiany wprowadzane przez oddział (serwer o wyższym priorytecie wygrywa) itp. Jednak w takim przypadku programista musi zapewnić mechanizm, dzięki któremu pracownik oddziału będzie mógł zorientować się, że jego zmiany zostały wycofane. Można też stosować kryterium czasu. To zadanie sprowadza się do tego, że jest wprowadzana "najstarsza" zmiana.
Mimo znanych od lat metod unikania konfliktów w replikacji i tak w wielu rozwiązaniach konieczne jest stosowanie własnych algorytmów, które, niestety, często sprowadzają się do przedstawienia użytkownikowi listy zmian z pytaniem, która z nich ma być utrwalona. Niemal każdy mechanizm replikacyjny pozwala na podłączenie własnych zasad rozwiązywania konfliktów - czy to jako zestaw reguł w Oracle Stream, czy procedura przechowywana w SQL Server.
