Replikacja czy dwufazowe blokowanie?

Każda baza danych jest tym łatwiej dostępna im znajduje się bliżej jej końcowego użytkownika. Baza lokalna zapewnia natychmiastowy dostęp (ograniczony jedynie wydajnością serwera). Jednakże z punktu widzenia użytkownika zdalnego, ryzyko utraty danych umieszczonych w jednym miejscu jest za duże. Awaria sieci komputerowej skutecznie odcina go od żywotnych danych, a tłumaczenie, że "padł" komputer nikogo nie zadowala klientów.

Każda baza danych jest tym łatwiej dostępna im znajduje się bliżej jej końcowego użytkownika. Baza lokalna zapewnia natychmiastowy dostęp (ograniczony jedynie wydajnością serwera). Jednakże z punktu widzenia użytkownika zdalnego, ryzyko utraty danych umieszczonych w jednym miejscu jest za duże. Awaria sieci komputerowej skutecznie odcina go od żywotnych danych, a tłumaczenie, że "padł" komputer nikogo nie zadowala klientów.

Dwufazowe blokowanie

W celu zapewnienia integralności danych w środowisku przetwarzania rozproszonego, producenci systemów zarządzania bazami danych oferują na ogół protokół dwufazowego blokowania transakcji (two-phase commit). W skrócie polega on na tym, że po wysłaniu polecenia uaktualnienia danych należy upewnić się, czy aktualizacja została ostatecznie dokonana (odczekać na potwierdzenie jej wykonania) i dopiero wtedy można uznać transakcję za wykonaną. Wyobraźmy sobie jednak, że dane na odległym serwerze nie są dostępne z powodu awarii sieci telekomunikacyjnej. Nie otrzymuje się więc potwierdzenia wykonania transakcji i zostaje ona w całości wycofana. Wszystkie transakcje związane z danymi z tego serwera nie będą udane. Tak więc, aby dwufazowe blokowanie mogło działać skutecznie, musi korzystać z niezawodnego środka komunikacji. Założenie to może okazać się nierealne do spełnienia, zwłaszcza jeśli korzysta się z publicznej sieci komutowanej.

Metoda dwufazowego blokowania transakcji spełnia swoje zadanie dostatecznie dobrze w warunkach bazy rozproszonej lokalnie, z siecią o dobrej niezawodności. Sybase oferuje w swych systemach zarządzania bazami danych potwierdzanie transakcji przez dwufazowe blokowanie. Jednakże dla baz rozproszonych na większym obszarze zaleca stosowanie replikacji.

Replikacja danych

Istnieją różne formy replikacji danych. Najczęściej polega to na okresowym wykonywaniu kopii (snapshot) całości lub części danych (na ogół całej tabeli) z głównej lokalizacji do serwerów podległych i okresowym ich uaktualnianiu, synchronicznym (w ustalonym odstępie czasu np. raz dziennie) lub asynchronicznie (po dokonaniu zmian w tabeli). Rodzi to niebezpieczeństwo korzystania z danych nieaktualnych zawartych na serwerze zdalnym oraz oznacza konieczność przesyłania w sieci kopii całych tabel.

Czasem replikacja dotyczyć może tylko części tabeli: określonej liczby wierszy lub kolumn. Takie rozwiązanie jest jednak nieefektywne i dlatego jest rzadko stosowane.

Sybase Replication Server

Sybase oferuje system do wykonania kompleksowej replikacji kompletnych tabel baz danych do odległych serwerów, oparty na wykorzystaniu kilku mechanizmów systemowych (dwufazowe blokowanie, zdalne wywoływanie procedur i aktualizacja bazy głównej przez zdalny serwer). Replication Server dobrze nadaje się do obsługi rozproszonych baz danych w przypadku korzystania z sieci telekomunikacyjnej.

Obsługuje on główną lokalizację danych i lokalizacje zdalne, na których umieszcza się kopie zasadniczych danych. Jest on sterowany zdarzeniami, jest więc w stanie zapewnić replikację danych prawie w czasie rzeczywistym.

Program Log Transfer Manager śledzi transakcje w lokalizacji głównej i przesyła wszelkie zmiany do Replication Servera. Ten zaś odpowiada za przesłanie właściwych informacji do Replication Servera w zdalnych serwerach. Replication Server w zdalnym serwerze wykonuje na kopii danych wszystkie transakcje we właściwej kolejności, zapewniając integralność danych. Jeżeli z jakiegoś powodu zdalny Replication Server jest niedostępny, jego lokalny odpowiednik zapamiętuje na miejscu wszystkie wysyłane komunikaty i przesyła je do wykonania, gdy już zdalny serwer będzie dostępny (asynchroniczna replikacja). Chroni to więc integralność danych, nawet w przypadku awarii sieci.

Jeżeli główny, lokalny serwer danych nie działa, to administrator sieci może zadecydować o użyciu zdalnego serwera danych do wykonywania transakcji. Po uruchomieniu głównego serwera, zdalny Replication Server prześle wszystkie wykonane zmiany do lokalizacji głównej.

Osoby korzystające z danych na serwerze zdalnym mają komfort pracy taki, jaki zapewnia korzystanie z lokalnych danych (bo tak istotnie jest - korzystają z własnej kopii danych), a jednocześnie mają pewność, że dane w głównym serwerze zostaną zaktualizowane przez Replication Server. Jest to możliwe dzięki temu, że Replication Server wykonuje zapamiętane procedury. Zdalny Replication Server zamiast przesyłać do głównej lokalizacji uaktualnione kopie tabeli danych, przesyła żądanie wykonania zdalnej procedury aktualizacji tabeli głównej.

Zalety Replication Servera:

* Zwiększona szybkość dostępu do danych. Nie ma potrzeby przesyłania całej tabeli danych do zdalnych lokalizacji; przesyła się jedynie informacje o zmianach.

* Natychmiastowy dostęp do danych. Dane w zdalnych serwerach są stale aktualne; nie ma potrzeby wykonywania kopii całych tabel lub bazy. Rozwiązanie to nadaje się do stosowania w środowisku niejednorodnych serwerów baz danych.

* Elastyczność. Każdy REplication Server "wie" o istnieniu innych takich samych serwerów w sieci i danych, które one kontrolują. Pozwala to na ich efektywną współpracę.

* Programowalność. Replication Server jest programowalny i może być przystosowany do indywidualnych wymagań użytkownika.

* Autonomia. Każda lokalizacja ma w pełni autonomiczną kontrolę własnych danych. Replication Server powoduje uaktualnianie danych w głównej lokalizacji i ich replikację na inne podległe lokalizacje.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200