W imię spójności

Standardowe mechanizmy do replikacji baz danych można wykorzystać do budowy systemu IT lub rozwiązania integracyjnego.

Standardowe mechanizmy do replikacji baz danych można wykorzystać do budowy systemu IT lub rozwiązania integracyjnego.

Replikacja jest przydatna w wielu sytuacjach. Najczęściej potrzeba replikacji danych ujawnia się, gdy firma działająca dotychczas w jednej lokalizacji zaczyna tworzyć sieć oddziałów terenowych. Budowa niezawodnych łączy stałych do centrali, by umożliwić zdalnym pracownikom pracę online, to zwykle duże wyzwanie organizacyjne, a niezależnie od tego także finansowe. Replikacja jest tu naturalnym sprzymierzeńcem.

Drugim typowym zastosowaniem mechanizmów replikacyjnych jest zwiększenie niezawodności systemu informatycznego. Z punktu widzenia złożoności zadania replikacja jest znacznie prostsza niż integrowanie informacji pochodzące z wielu różnych oddziałów na poziomie aplikacji. Klaster typu failover w wielu przypadkach można zastąpić instalacją, w której drugi serwer przejmie zadanie pierwszego po "ręcznym" przełączeniu i to mając od razu do dyspozycji spójne dane.

W takich przypadkach nie zachodzi potrzeba zakupu "specjalnych" wersji serwera baz danych - oprogramowanie replikacyjne (lub choćby jego uproszczona wersja) jest zazwyczaj oferowane w ramach licencji na serwer.

Gotowe rozwiązania ułatwiają zautomatyzowanie procesu replikacji. Replikacja sprowadza się w takiej sytuacji bądź to do "prostego" zapisywania danych na serwerze zapasowym, bądź wykonywania na drugiej maszynie tych samych operacji na podstawie nadesłanych logów transakcyjnych. Przy takiej architekturze serwer otrzymujący dane z serwera głównego może ponadto służyć jako platforma dla operacji analitycznych, dysponuje bowiem aktualnymi informacjami.

Niezależnie od mechanizmów replikacyjnych dostarczanych wraz z serwerami baz danych na rynku istnieje wiele niezależnych narzędzi ułatwiających replikację. Ich producenci kładą nacisk na możliwość wymiany danych w heterogenicznych środowiskach bazodanowych i systemowych albo na łatwość definiowania zasad replikacji bądź udogodnienia w obsłudze konfliktów i błędów. Istnieją także dość wygodne pakiety narzędziowe do samodzielnego tworzenia rozwiązań replikacyjnych.

Microsoft Server

Microsoft SQL Server 2000 może przekazywać plik log transakcji między serwerami. W ten sposób replikacja składa się z dwóch etapów - początkowego przeniesienia danych, a następnie okresowego "odtwarzania" logu na zapasowym serwerze (log shipping).

Tworząc mechanizmy replikacyjne, Microsoft wykorzystał metaforę "publikuj/subskrybuj". Administrator - publikujący - wybiera bazę, która ma być udostępniona subskrybentom - innym bazom danych. Za proces przenoszenia informacji odpowiada serwer-dystrybutor. W zależności od tego, który z serwerów wybierzemy, replikacja będzie się odbywać w trybie pull lub push. Publikacje mogą być typu snapshot - wtedy jest udostępniany obraz zestawu danych, transactional - w ramach transakcji zmiany są przenoszone na inny serwer oraz merge - w tym przypadku możliwe jest synchronizowanie zmian wprowadzonych u subskrybenta z bazą główną.

Subskrybentem (przy pewnych ograniczeniach) może być dowolna baza, do której mamy sterownik ODBC/OLEDB. Do tworzenia replikacji są używane specjalne kreatory. Posłużenie się nimi w większości przypadków wystarczy do poprawnego i pełnego zdefiniowania zasad replikacji. Mechanizm opiera się na specjalnie skonstruowanych wyzwalaczach (triggers), które przechwytują zmiany w bazie i zapisują do specjalnych tabel. Dzięki tym tabelom dystrybutor "wie", które elementy się zmieniły, i może udostępnić odpowiednie dane subskrybentom.

Taka konstrukcja replikacji w SQL Server 2000 powoduje jednak pewien problem. Jeżeli włączymy replikację, schematu bazy danych nie możemy zmieniać dowolnie, lecz jedynie poprzez specjalne procedury składowane.

Najprostszym rozwiązaniem jest zablokowanie replikacji przed dokonywaniem zmian w strukturze. Z zapowiedzi wynika, że w Yukonie najprawdopodobniej zostaną wprowadzone specjalne triggery wyzwalane w momencie wykonywania operacji DDL. Taki wyzwalacz będzie mógł zapisać dane o zmianie schematu do pliku log i w ten sposób zmienić zawartość publikacji.

Sybase Adaptive Server Enterprise

Sybase Replication Agent to zestaw produktów Sybase, które pozwalają na stworzenie systemu replikacyjnego w środowisku heterogenicznym. Sybase oferuje "agentów" nie tylko dla własnych serwerów, ale także dla Informixa, Oracle, SQL Server czy DB2. Podstawowym zadaniem takiego agenta jest przechwycenie transakcji w "obserwowanej" bazie danych i przesłanie jej do Replication Server, który zajmuje się dystrybucją danych do baz docelowych.

Agent składa się z czterech komponentów. Log Reader odpowiada za obsługę rodzimych logów transakcyjnych na danej platformie. Odczytuje transakcje, które mają być przesłane na serwer replikacji. Dane są zapisywane w specjalnym języku Log Transfer Language. Za ich zapis odpowiada komponent Log Transfer Interface. Wszystkim steruje komponent Log Transfer Manager koordynujący operacje i decydujący, które transakcje mają być obsługiwane przy użyciu Log Reader. Log Administrator jest pomocniczym komponentem służącym do konfigurowania agentów. Replication Agent nasłuchuje na konkretnym porcie TCP/IP i dzięki temu administrator może zdalnie zarządzać instalacją.

Samodzielna instancja produktu może być zarządzana przy użyciu dowolnego klienta obsługującego protokół TDS (Tabula Data Stream). Podobną architekturę obsługi baz heterogenicznych proponuje Oracle - jednak nie zawiera gotowych rozwiązań dla baz innych producentów. Jeżeli administrator chce replikować dane z innej bazy niż Oracle, musi wcześniej stworzyć mechanizm zapisujący transakcje w formacie LCR, i dopiero taki strumień danych może być odtworzony po stronie serwera Oracle.


TOP 200