Replikacja danych w bazach

Zachowanie integralności danych w bazie wymaga największej uwagi projektanta systemu i aplikacji. Zadanie jest łatwiejsze, jeśli dane znajdują się na lokalnym serwerze. Sytuacja komplikuje się w przypadku aplikacji klient/serwer, gdy dane mogą znajdować się na różnych serwerach, a nawet być znacznie odległe geograficznie.

Zachowanie integralności danych w bazie wymaga największej uwagi projektanta systemu i aplikacji. Zadanie jest łatwiejsze, jeśli dane znajdują się na lokalnym serwerze. Sytuacja komplikuje się w przypadku aplikacji klient/serwer, gdy dane mogą znajdować się na różnych serwerach, a nawet być znacznie odległe geograficznie.

Wyzwaniem dla projektantów systemów zarządzania bazami danych w środowisku klient/serwer jest dostarczanie danych do właściwego miejsca, we właściwym czasie. Wiele współczesnych systemów operujących zgodnie z modelem klient/serwer korzysta z danych zgromadzonych na różnych platformach sprzętowych, pod różnymi systemami operacyjnymi i często w odległych miejscach.

Rozwiązanie problemu dostępu do takich danych nie jest łatwą sprawą, ale większość twórców relacyjnych systemów zarządzania bazami danych spostrzegła ten problem i wraz z motorami baz dostarcza narzędzi do przetwarzania rozproszonego. Prawie równocześnie, producenci oprogramowania typu middleware pośredniczącego między różnymi systemami sieciowymi oraz skrywającego przed programistą i użytkownikiem skomplikowane problemy przekształcania protokołów komunikacyjnych, dostarczają coraz bardziej wyrafinowanych narzędzi do przesyłania danych między serwerami.

Rozwiązanie kompromisowe

W dawniejszych systemach zarządzania stosowano mechanizm dwufazowego blokowania bazy (two-phase commit), polegający na kontroli zakończenia wykonania określonej operacji (transakcji). W tym celu blokuje się odpowiedni zakres bazy danych (rekord, blok, tablicę, zależnie od właściwości funkcjonalnych bazy) i przeprowadza niezbędne operacje. Jeżeli z jakichś względów operacji nie udaje się dokończyć, to jest ona w całości wycofywana. Takie rozwiązanie jest absolutnie niezbędne w przypadku transakcji bankowych czy rezerwacji biletów. Jednakże narzuty czasowe (dane nie są dostępne przez cały czas wykonywania transakcji) jakie dwufazowe blokowanie powoduje, nie zachęcają do stosowania go w aplikacjach o mniejszych wymaganiach. Poważną wadą stosowania tej metody w przedsiębiorstwach, mających bazy rozmieszczone w różnych miejscach, jest ryzyko przerwania normalnej działalności z powodu awarii sieci komunikacyjnej. Jeżeli w celu dokończenia transakcji, istnieje potrzeba uaktualnienia zawartości odległej bazy, to awaria połączenia telekomunikacyjnego spowoduje odrzucenie wszystkich transakcji, aż do czasu odzyskania połączenia.

Do niedawna jedyną alternatywą takiego rozwiązania było okresowe przekazywanie kopii całej bazy lub jej części do podległego serwera danych. Operację tę wykonywano okresowo, zwykle raz na dzień. Dane na serwerze podległym nie mogą być modyfikowane, gdyż istnieje ryzyko utraty integralności bazy danych. Nie są one także zbyt aktualne. Można z nich korzystać tylko do odczytu.

Replikacja baz danych jest próbą pogodzenia tych dwóch rozwiązań ekstremalnych. Na przykład niektóre replikatory bazy pozwalają na przesyłanie części bazy do innych lokalizacji co pewien wybrany okres (np. co godzinę) lub w wyniku pojawienia się w bazie zmian, warunkujących wykonanie tej operacji. Dzięki temu dane we wszystkich lokalizacjach są stale aktualne.

Inne programy replikacji bazy pracują w sposób ciągły, stosując metodę "zapamiętaj i prześlij". Jeżeli komunikacja z kopią bazy jest możliwa, to natychmiast przesyła się do niej wszystkie transakcje. Jeżeli połączenie jest przerwane lub serwer podległej bazy jest zajęty, to następuje zapamiętanie transakcji do czasu odzyskania dostępu.

Replikacja całej bazy danych na innym serwerze lokalnym umożliwia wykorzystanie kopii bazy danych do wykonywania intensywnych obliczeniowo operacji (badań statystycznych, analizy opłacalności operacji handlowych czy finansowych, podejmowania strategicznych działań w przedsiębiorstwie), bez przerywania normalnego przetwarzania transakcyjnego.

Replikacja pozwala także na prowadzenie normalnej działalności na kopii bazy w przypadku awarii głównego serwera bazy. Po usunięciu awarii, replikator jest w stanie zsynchronizować zawartość kopii i oryginału bazy.

Replikatory

Do niedawna twórcy systemów zarządzania bazami danych nie byli w stanie dostarczyć niezawodnych replikatorów bazy (Replication Servers). Główni dostawcy systemów zarządzania bazami danych - Oracle, Informix i Sybase - mają już w ofercie systemy replikacji. W przypadku Sybase program Replication Server stanowi opcję architektury klient/serwer Sybase System 10.

Sybase proponuje dwa modele replikacji. Pierwszy jest oparty na ścisłej spójności bazy, drugi na luźnej. Ścisła spójność bazy i jej kopii wymaga, aby przez cały czas były one kompletnie zgodne. Odpowiada to wymaganiom systemów przetwarzania z dwufazowym blokowaniem transakcji: musi być możliwy dostęp do wszystkich kopii nim rozpocznie się proces synchronicznej replikacji bazy (lub jej części).

W modelu luźnej spójności, istnieją lokalizacje, w których kopie bazy są na pewno aktualne; w pozostałych lokalizacjach kopie są uaktualniane co pewien czas, zgodnie z procedurami opracowanymi przez użytkowników kopii. Na przykład oddział zajmujący się transportem będzie otrzymywał kopie nowych danych na temat transportu natychmiast, natomiast dane na temat zamówień będą w jego bazie aktualizowane znacznie rzadziej. I odwrotnie, dział handlowy otrzyma informacje o transporcie rzadziej, zaś dane handlowe będą kopiowane natychmiast.


TOP 200