Rozdział 16 Replikacje baz danych w praktyce Streszczenie. Powielanie informacji przechowywanych na serwerach jest istotnym elementem zapewniającym zwiększenie zarówno wydajności, jak i bezpieczeństwa systemu. W rozdziale zarysowano problematykę replikacji baz danych z uwzględnieniem stosowanych typów i metod. Przedstawiono możliwość zastosowania replikacji w bazach klastrowych oraz opisano konfigurację rzeczywistego systemu z replikacją w MySQL. Ponadto podjęto próbę uporządkowania polskojęzycznej terminologii w dziedzinie replikacji baz danych. 1 Wstęp W rozproszonych systemach baz danych, dane są przechowywane w skończonej liczbie lokalizacji (site), które często znajdują się w geograficznie rozproszonych miejscach. Dla wielu systemów, np. z zakresu bankowości czy telekomunikacji, rozproszone bazy danych stanowią bardziej naturalny model niż monolityczne systemy zcentralizowane. Niektóre komercyjne bazy danych zapewniają obsługę dystrybucji danych na poziomie tzw. motoru bazy (database engine), a nowe technologie komunikacyjne pozwalają na coraz większy stopień rozproszenia. Wraz z rozwojem systemów baz danych pojawiło się bardziej zaawansowane rozwiązanie umożliwiające rozpraszanie danych, tj. replikacja. Replikacja oznacza powielanie, a więc tworzenie kopii (replik) oraz utrzymywanie jednakowych danych w środowisku wielu baz rozmieszczonych często w różnych węzłach (rys. 1). Zmiany w jednej bazie są dokonywane lokalnie, a następnie przekazywane do każdej z odległych lokalizacji. Replikacja jest zatem mechanizmem, który tworzy i zarządza zespołem wielu kopii danych, na których pracują użytkownicy. W replikacji wykorzystywana jest technologia rozproszonych baz danych, choć nie należy utożsamiać bazy, będącej lokalizacją replikacji, z bazą rozproszoną, gdzie dane są dostępne w różnych lokalizacjach. Oznacza to w szczególności, że pojedyncza tabela bazy rozproszonej znajduje się w tylko jednej lokalizacji, natomiast w przypadku replikacji, kopie tej tabeli znajdują się w każdej lokalizacji. Utrzymanie replikowanych danych jest więc ściśle powiązane z komunikacją pomiędzy lokalizacjami, a zarządzanie procesem replikowania ma znaczący wpływ na wydajność całego systemu. Zarządzanie replikowaniem polega na decydowaniu, kiedy i gdzie należy umieścić kopie fizyczne odpowiadające logicznym fragmentom danych oraz kiedy i jak je uaktualniać celem uzyskania akceptowalnego stopnia jednorodności [2]. Krzysztof Świder, Tomasz Rak: Politechnika Rzeszowska, Katedra Informatyki i Automatyki, ul. W. Pola 2, 35-959 Rzeszów, Polska email:{kswider, trak}@prz-rzeszow.pl
K. Świder, T. Rak Replika 1 R eplika 2 Replika 3 Logiczna baza danych Rys. 1. Baza danych z replikacją System replikowanej bazy danych jest systemem rozproszonym, w którym każda lokalizacja kopiuje bazę danych albo jej część. Dostęp do danych odbywa się przez transakcje. Transakcja reprezentuje logiczną całość operacji czytania lub zapisywania. Jest to pojedyncze zadanie, czyli sekwencja operacji, która powinna spełniać kryteria ACID (Atomicity Consistency Isolation Durability) [8]. Niepodzielność (atomicity) oznacza, że transakcja zostanie doprowadzona do końca lub zostanie przerwana. Spójność (consistency) zapewnia, że skutkiem transakcji jest poprawny stan bazy danych. Izolacja (isolation) oznacza, że wykonywanie dwóch równoległych transakcji jest zupełnie odseparowane od siebie. Trwałość (durability) zapewnia nieodwracalność transakcji, nawet w przypadku zdarzenia błędnego. Komunikacja pomiędzy użytkownikami i replikami odbywa się poprzez wymianę komunikatów. Ogólnie replikacja jest wykorzystywana w wielu dziedzinach, a szczególnie w systemach rozproszonych (tolerowanie błędów) i w bazach danych (zwiększanie wydajności). 1 Podsumowując, system z replikacją to: jedna logiczna baza danych, wiele fizycznych kopii bazy danych, pełna synchronizacja wszystkich kopii, zachowanie własności ACID i jedno połączenie klienta z bazą danych. 2 Typy i metody replikacji 2.1 Typy replikacji Dla replikacji wyróżnia się kilka modeli, które pozwalają opisywać rzeczywiste implementacje. Należą do nich: zabezpieczenie poprawnej pracy (hot fail over), replikacja kopii głównej (primary copy, master-slave), replikacja lokalizacji nadrzędnych (multi-master, peer to peer, update everywhere), replikacja hybrydowa. Zabezpieczenie poprawnej pracy systemu można uznać za jeden z podstawowych sposobów tworzenia kopii danych. Polega na zamianie serwera w przypadku awarii, a zatem nie jest replikacją w sensie podanej tu definicji. Replika kopii głównej zawiera pełną lub częściową kopię obiektów węzła docelowego (target master) w danym momencie czasu. Pozostałe węzły są podrzędne w stosunku do 1 Stosowane techniki i mechanizmy są identyczne pod względem koncepcji, ale różnią się w sferze realizacji i działania. 154
Replikacje baz danych w praktyce węzła głównego w przypadku architektury jednowarstwowej, ale mogą być także nadrzędnymi w stosunku do innych węzłów w przypadku architektury wielowarstwowej. Wyróżnia się trzy rodzaje tego typu replikacji: (i) tylko do odczytu (read only materialized views), (ii) do uaktualniania (updatable materialized views) oraz (iii) do zapisu (writeable materialized views). Replikacja tylko do odczytu jest najpopularniejszym rodzajem replikacji. Zapewnia dostęp do odczytu danych z głównej lokalizacji i jest typem replikacji, w której dane są gromadzone centralnie w jednej lokalizacji, a następnie przekazywane do innych. Dane mogą być modyfikowane tylko w lokalizacji centralnej, a odczytywane przez klientów z pozostałych lokalizacji. Dzięki zastosowaniu replik tylko do odczytu można rozdzielić ruch sięciowy oraz wyeliminować pojawianie się konfliktów. Replikacja z wykorzystaniem kopii głównej do uaktualniania jest bardziej zaawansowaną konfiguracją. Pozwala ona na dopisywanie, uaktualnianie oraz kasowanie rekordów węzła docelowego za pośrednictwem danych znajdujących się w innej lokalizacji. Replikacja z wykorzystaniem kopii głównej do zapisu jest rzadko stosowana. Lokalizacja główna jest potencjalnym źródłem problemów wąskiego gardła (bottleneck) i pojedynczego punktu awarii (single point of failure). Kiedy dane w głównej lokalizacji są zmieniane, to pozostałe lokalizacje są aktualizowane poprzez mechanizm zdarzenia (snapshot) lub wyzwalania (trigger). Migawki umożliwiają asynchroniczne modyfikacje w relacjach zgodnie z określonym wcześniej harmonogramem. Mogą zawierać pełną kopię danych relacji lub jedynie wybrane dane. Alternatywą są wyzwalacze umożliwiające użytkownikom tworzenie ich własnych aplikacji do zarządzania replikami. Wyzwalacze zawierają instrukcje, które będą podejmowały odpowiednie działania w przypadku wystąpienia zdarzenia. Replikacja lokalizacji nadrzędnych 2 pozwala na równe uczestnictwo wszystkich lokalizacji w zarządzaniu grupami obiektów. Każda lokalizacja jest lokalizacją nadrzędną i każda komunikuje się z pozostałymi lokalizacjami nadrzędnymi. Aplikacje korzystające z obiektów znajdujących się w lokalizacjach nadrzędnych mogą dokonywać uaktualniania dowolnych danych. Uaktualnienie może zostać wykonane w zakresie transakcji (transaction boundaries) albo po zatwierdzeniu transakcji (transaction commit). W pierwszym przypadku, jest to replikacja synchroniczna tzw. gorliwa (eager), w przeciwnym jest to replikacja asynchroniczna tzw. leniwa (lazy, store and forward). Replikacja hybrydowa jest kombinacją poprzednich rodzajów, czyli replikacji kopii głównej oraz replikacji lokalizacji nadrzędnych. Dzięki niej można tworzyć dowolnie skomplikowane środowisko replikacji, wykorzystując zalety zarówno replikacji kopii głównej, jak też replikacji lokalizacji nadrzędnych. 2.2 Metody replikacji Ze względu na sposób przekazywania danych pomiędzy replikami, replikacje dzieli się na: synchroniczne (synchronous replication), asynchroniczne (asynchronous replication) i proceduralne (procedural replication). Dla replikacji synchronicznej zmiany wprowadzone w jednej lokalizacji są natychmiast przekazywane na pozostałe. W przypadku, gdy jedna z lokalizacji nadrzędnych nie może zaakceptować wprowadzonych zmian, wtedy transakcja jest wycofywana ze wszystkich lokalizacji. Zaletą jej jest unikanie ewentualnych konfliktów. Główne ograniczenia to kosztowna realizacja i środowisko, które powinno być stabilne. Replikacja asynchroniczna polega na przechowywaniu wszystkich operacji dokonanych na obiektach replikacji w tak zwanej kolejce odroczonych transakcji. Odroczone transakcje są następnie rozprowadzane na pozostałe lokalizacje replikacji w regularnych odstępach 2 Inaczej replikacja: równorzędna, wszędzie, n-dróg lub jeden-do-jeden. 155
K. Świder, T. Rak W praktyce wiele rozproszonych baz danych nie stosuje żadnej replikacji, tzn. każdy z logicznych elementów danych ma tylko jedną fizyczną kopię. Najczęściej jednak wykorzystywane są systemy, w których zastosowano częściową lub pełną replikację [7]. Możliwe sposoby to: replikacja wszystkich obiektów do wszystkich lokalizacji (pełna), replikacja wszystkich obiektów do części lokalizacji, replikacja części obiektów do wszystkich lokalizacji, replikacja części obiektów do części lokalizacji oraz replikacja określonych obiektów. Istniejące sposoby replikacji zostały sklasyfikowane. Do najbardziej popularnych należy klasyfikacja Gray a, a z późniejszych warto wspomnieć klasyfikację Wiesmanna. Gray [4] sklasyfikował replikacje w bazach danych w oparciu o dwa parametry: kto inicjuje transakcję oraz sposób jej wykonania (rys. 2a). Pierwszy wymiar określa posiadacza danych (object ownership); czy jest nim jeden węzeł główny czy wszystkie węzły, co oznacza uaktualnianie we wszystkich węzłach. W zależności od tego, kto może przeprowadzać aktualizacje, nadrzędna lokalizacja wymaga, aby wszystkie aktualizacje najpierw były wykonane na jednej replice (głównej) i dopiero wtedy na innych. Efektem tego jest wprowadzenie pojedynczego punktu awarii, który może stać się potencjalnym wąskim gardłem. Aktualizacja we wszystkich lokalizacjach pozwala każdej replice na aktualizacje, co powoduje przyspieszenie dostępu kosztem bardziej złożonego procesu koordynacji. Drugi wymiar określa, w którym momencie odbywa się aktualizacja danych (transaction execution context). Gorliwa replikacja przed wykonaniem wysyła informacje wszystkim innym zaangażowanym systemom i weryfikuje wykonanie lub przerywa transakcję. Kopie są uaktual.- niane w tej samej transakcji, co pozwala na wykrywanie konfliktów zanim transakcja zostanie zatwierdzona i w ten sposób zachowani spójności danych. Uzyskuje się poprawność transakcji przy jednoczesnym zwiększeniu czasu reakcji, gdyż repliki są uaktualniane bez czasu. Wadą tej metody jest jednak możliwość pojawiania się konfliktów. Replikacja proceduralna zwiększa wydajność wykonywania dużych wsadowych operacji na replikowanych danych. Stosowana jest tam, gdzie występuje duża ilość danych w każdej transakcji i polega na replikacji jedynie wywołań proceduralnych (procedural calls), które uruchamiają procedury uaktualniające tabele. Aby używać tej replikacji, należy najpierw utworzyć repliki pakietów w każdej z lokalizacji, które służą do modyfikowania danych w systemie. W przypadku tej replikacji, procedury są odpowiedzialne za zapewnienie integralności danych na odpowiednim poziomie. Oznacza to, że muszą być one odpowiednio zaprojektowane tak, aby unikać, bądź wykrywać i rozwiązywać, pojawiające się konflikty [1], [12]. a) b) Rys. 2. Graficzna reprezentacja klasyfikacji replikacji: a) Gray a, b) Wiesmanna 156
Replikacje baz danych w praktyce pośrednio po modyfikacji danych oryginalnych. W leniwej replikacji po wykonaniu transakcji wysyłane są informacje do wszystkich innych zaangażowanych systemów. Transakcja jest wykonywana, a repliki są uaktualniane w oddzielnych transakcjach. W ten sposób uzyskuje się skrócenie czasu reakcji, lecz pojawia się ryzyko niespójności danych. W modelu gorliwej replikacji użytkownik nie otrzymuje powiadomienia o wykonaniu (aktualizacji), zanim odpowiednie repliki w systemie nie zostaną zaktualizowane. Model leniwej replikacji aktualizuje lokalne repliki dopiero po powiadomieniu użytkownika. Gorliwe replikacje propagują uaktualnienia do odległych lokalizacji i zarządzają nimi do momentu wykonania transakcji. Wiąże się z to ze spójnością danych, izolowaniem transakcji i tolerancją błędów. Ze względu na swoją złożoność, niewiele spośród nich zostało kiedykolwiek użytych w produktach komercyjnych. 3 Aktualnie używane produkty używają leniwych replikacji. Skutkiem są błędy, gdyż repliki mogą stać się nieaktualne, a nawet niespójne. Porównując sposoby replikacji, można zauważyć uzupełniające się cechy. Gorliwe replikacje uwypuklają spójność i tolerancję błędów, ale posiadają małą wydajność. Leniwe replikacje zwracają więcej uwagi na efektywność, ale nie zapewniają odpowiedniej spójności danych. Użycie leniwych replikacji jest konieczne, gdy repliki są trudne do synchronizacji. Typowym przykładem są terminale mobilne stosowane tam, gdzie koszty komunikacji są zbyt wysokie. Gorliwe replikacje znacznie łatwiej implementują złożoną funkcjonalność, jak rozkładanie obciążenia (load balancing) czy wysoka dostępność (high availability). Z tego względu są one o wiele bardziej pożądane dla systemów rozproszonych (klastrowych) [6]. Obok klasyfikacji Gray a istnieją inne klasyfikacje bazujące na niej, jak np. klasyfikacja Wiesmanna. Uzależniona jest ona od [8]: architektury systemu, komunikacji między serwerami/węzłami oraz sposobu zakończenia transakcji (rys. 2b). Architektury mogą występować jako: replikacja kopii głównej lub replikacja lokalizacji nadrzędnych. Komunikacja pomiędzy serwerami/węzłami określa ilość ruchu generowanego przez algorytm replikacji pomiędzy replikami oraz ilość wiadomości koniecznych do przeprowadzenia transakcji. Wyróżnia się dwa przypadki współdziałania: stałe, oznaczające jednakową ilość wiadomości użytą do synchronizacji serwerów w czasie transakcji niezależnie od ilości operacji oraz liniowe, które oznacza proporcjonalną ilość operacji sieciowych w stosunku do ilości operacji transakcji. Sposób zakończenia transakcji określa, jak można przerwać transakcję. Przerwanie uzgodnione (voting) wymaga dodatkowego cyklu dla koordynacji replik a przerwanie nieuzgodnione (non-voting) oznacza, że repliki same mogą zdecydować czy zakończyć transakcję, czy ją przerwać. 3 Replikacja w systemach rzeczywistych Istniejące systemy baz danych wykorzystują różne modele replikacji danych, dodatkowo uzupełniając je o własne lub zapożyczone rozwiązania (tab. 1). Systemy rzeczywiste implementują większość z metod przedstawionych w tym opracowaniu, jednak wiele z nich jest jeszcze w fazie testów laboratoryjnych. 3 Istnieje powszechne przekonanie wśród projektantów baz danych, że większość istniejących rozwiązań nie jest możliwych do implementacji z powodu ich złożoności, małej wydajności i braku skalowalności. 157
K. Świder, T. Rak Tabela 1. Replikacje w systemach baz danych [9], [10], [11], [12], [13], [14], [15] Replikacja Baza danych Kopii głównej Synchroniczna Lokalizacji nadrzędnych Oracle RO (Read Only), RW (Read Write), Inne 4 + + Informix + IBM DB2 RO + Sybase RO Inna 5 Progress RO, Inna 6 + + PostgreSQL RO, Inna 7 + + MySQL RO, Inne 8 Inna 9 Asynchroniczna 3.1 Bazy danych na klastrach W klastrach obciążenie rozkłada się na węzły połączone szybką siecią celem poprawienia skalowalności i tolerancji błędów. Wzrost obciążenia pociąga za sobą powiększanie ilości węzłów dodawanych do systemu. Tolerancja błędów oznacza, że defekt jednego węzła nie przeszkadza w wykonaniu operacji na innych. W wielu przypadkach dostępne węzły przetwarzają zadania tych węzłów, które uległy awarii [6]. Jeśli klastry są używane w rozproszonych bazach danych, to konieczny jest podział danych pomiędzy węzłami, jednak dzielenie takie ma surowe ograniczenia. Po pierwsze, trudno jest podzielić dane tak, aby obciążenie węzłów było jednakowe. Po drugie, dla transakcji rozproszonej, próbującej uzyskać dostęp do różnych węzłów, ustalenie, gdzie powinny znajdować się dane, jest trudne [5]. Ograniczenia te eliminuje replikowanie danych, które wyrównuje obciążenia i może dostosować się do zmiennych warunków obciążenia zapytaniami. Ponadto unika się rozproszonego zarządzania transakcjami, jeśli wszystkie dane są kopiowane do wszystkich lokalizacji (replikacja lokalizacji nadrzędnych) oraz przeciwdziała występującym błędom (replikacja gorliwa). Dodatkowo replikowanie wprowadza spójność danych (replikacja gorliwa), a w przypadku jej braku (replikacja leniwa), problem jest natychmiast rozwiązywany. Wynika stąd, że jeżeli chodzi o funkcjonalność, to gorliwa replikacja lokalizacji nadrzędnych jest pożądaną formą replikacji dla klastrów. Zapewnia ona optymalny rozkład obciążenia, dostęp do danych oraz gwarantuje spójność i tolerancję błędów. 4 Dostępne są również: zawiłe materializowane widoki (materialized views), zapisywalne materializowane widoki, oraz mieszana replikacja kopii głównej i materializowanych widoków. Ponadto jest możliwie kaskadowe łączenie niektórych replikacji. 5 Replikacja ta uaktualnia wspólną konfigurację, która jest później przesyłana do wszystkich lokalizacji. 6 Dostępna jest również replikacja konsolidacyjna. 7 Stosowane są specjalne moduły do replikacji. 8 Replikacja asynchroniczna. 9 Dostępna w przypadku skonfigurowania MySQL 5.0 do pracy jako klaster. 158
3.2 Przykład replikacji w MySQL Replikacje baz danych w praktyce Replikacja została wprowadzona po raz pierwszy do serwerów MySQL w wersji 3.25.15. MySQL w wersji 5.0 zawiera jednostronną, asynchroniczną replikację, w której jeden serwer pracuje jako master, podczas gdy jeden lub więcej z pozostałych serwerów pracują jako slave. Replikacja synchroniczna jest cechą charakterystyczną klastra MySQL. Serwer master zapisuje wszystkie zmiany do binarnego pliku zdarzeń. Te zdarzenia służą jako aktualizacje do zmian na serwerach slave. Kiedy serwer slave połączy się z serwerem master, to master zostaje poinformowany o ostatniej pozycji, jaką przeczytał slave w pliku zdarzeń. Wtedy serwer slave otrzymuje wszystkie aktualizacje, jakie miały miejsce od tego czasu, dokonuje ich na swojej bazie i czeka na powiadomienie od serwera master o nowych uaktualnieniach. Serwer typu slave może równocześnie pełnić rolę serwera typu master; otrzymuje się wtedy łańcuchową replikację serwerów i tworzy się drzewo replik [3]. W trakcie replikacji wszystkie uaktualnienia do tabel replikowanych powinny być wykonywane na serwerze master. Wykorzystywana replikacja jednostronna przynosi następujące korzyści: Zwiększona odporność na błędy dla replikacji master/slave. W przypadku problemów z masterem, można przełączyć się na serwer slave jako kopię zapasową. Krótszy czas odpowiedzi dla klientów jest możliwy przez podział zapytań generowanych przez klienta pomiędzy serwery master i slave. Zapytania typu SELECT mogą być wysyłane do serwera slave w celu minimalizacji zapytań przetwarzanych przez serwer master. Instrukcje modyfikujące dane powinny być wysłane do serwera master, gdyż wtedy serwer master i wszystkie serwery slave będą zaktualizowane. Możliwość wykonywania kopii zapasowej z serwera slave bez zakłócania pracy serwera master. W dalszej części pokazano, jak należy skonfigurować serwery master i slave do realizacji replikacji. Przedstawiony przykład obejmuje replikację na dwóch węzłach (master 62.93.34.158 i slave 62.93.34.155) wykorzystując do tego celu bazę danych MySQL w wersji 5.0.15 dla systemu Linux. Główne kroki konfiguracji to: uruchomienie dziennika przetwarzania binarnego, utworzenie użytkownika replikacji, przeniesienie baz, określenie położenia bazy typu master oraz aktywacja serwerów. Rys. 3. Edycja pliku konfiguracyjnego dla serwera nadrzędnego Przed przystąpieniem do ustawiania serwera master, należy utworzyć na nim dziennik binarny (binary log). Dziennik binarny zawiera wszystkie informacje potrzebne do aktualizacji danych (m. in. o czasie wykonania każdej instrukcji modyfikującej dane w bazie danych). Dziennik ten jest wykorzystywany przez nadrzędne serwery replikacji do zapisywania informacji aktualizacyjnych, które będą w przyszłości używane przez serwery slave do modyfikacji swoich baz i utrzymywania spójności danych. Można tego dokonać na dwa sposoby: poprzez dodanie parametru do komendy uruchamiającej serwer w pliku startowym demona lub dodanie jej w linii poleceń. W pierwszym przypadku przed wystartowaniem demona MySQL na komputerze master należy w pliku /etc/my.cnf wpisać w sekcji 159
K. Świder, T. Rak [mysqld] następujące opcje: log-bin 10 oraz server-id (rys. 3). Wartość server-id na każdym z serwerów powinna być unikalną dodatnią liczbą całkowitą. 11 Postępując drugim sposobem należy uruchomić serwer z opcją --log-bin (rys. 4). Rys. 4. Start i sprawdzanie statusu serwera oraz blokowanie zapisu do tabel Następnie dodaje się użytkownika o dowolnej nazwie z prawami globalnymi RELOAD i SUPER oraz prawem replication slave wykorzystując np. phpmyadmin (rys. 5) 12 lub z linii poleceń: mysql> grant replication slave on *.* -> TO 'replikator'@'%' identified by 'hasloreplikator'; Chcąc sprawdzić status serwera master, używa się polecenia: mysql> show master status; po uprzednim zalogowaniu (rys. 4). Jeżeli w czasie startu serwera dodana została opcja --log-bin nazwa pliku dziennika (jeżeli nie podano innej) składa się z nazwy serwera i rozszerzenia -bin. 13 Rys. 5. Określanie praw do bazy danych 10 Serwery, które będą pracować tylko jako slave nie wymagają wpisu log-bin. 11 W przypadku, gdy sekcja [mysqld] nie ma tych wpisów należy je wstawić i restartować serwer. 12 Chcąc uzyskać dostęp do wszystkich baz danych należy nadać mu dodatkowo prawo SELECT. 13 Serwer mysqld dodaje liczbowe rozszerzenie do nazwy dziennika binarnego w postaci numeru zwiększanego przy każdorazowym uruchamianiu. 160
Replikacje baz danych w praktyce Konieczne jest jeszcze skopiowanie wszystkich tabel na serwer slave. W tym celu na serwerze master blokuje się zapis do nich poleceniem: mysql> flush tables with read lock; widocznym na rys. 4. Kopię baz danych, które mają być replikowane, można utworzyć np. poleceniem tar (rys. 6). 14 Na serwerze slave dokonuje się operacji odwrotnej, gdzie katalogiem bieżącym jest katalog z danymi bazy, a plik przeniesiony z komputera master został zapisany w katalogu /tmp poleceniem: shell> tar xvf /tmp/mysql-bazy.tar. Rys. 6. Pakowanie i odblokowywanie zapisu do tabel Na komputerze master odczytuje się plik logu binarnego i jego położenie, a na komputerze typu slave ustawia położenie bazy typu master. Konieczne jest, podobnie jak w przypadku serwera master, nadanie serwerowi podrzędnego unikatowego identyfikatora. Podaje się dodatkowo informacje o serwerze master: nazwę lub adres IP komputera, na którym jest uruchomiony serwer master, nazwę i hasło utworzonego na tym serwerze użytkownika z prawami do replikacji oraz nazwę i pozycję dziennika binarnego. Kolumna Position (rys. 4) wskazuje pozycję w pliku log, reprezentującą punkt replikacji, z którego serwery podrzędne muszą rozpocząć aktualizację swoich danych. Można postąpić dwojako. Poleceniem change master to (rys. 7.) podać informacje o serwerze master lub, w przypadku, gdy tabele są typu MyISAM, zmodyfikować plik konfiguracyjny. Podaje się wtedy informacje widoczne na rys. 7., a następnie wykonuje na komputerze slave: 15 polecenie: mysql> load data from master; Rys. 7. Start oraz określanie informacji o serwerze nadrzędnym na konsoli serwera podrzędnego 14 Skopiować należy jedynie nowe bazy użytkowników. 15 Użytkownik replikacji musi posiadać prawa: SUPER, RELOAD i SELECT. 161
K. Świder, T. Rak Aktywowanie serwera master odbywa się poleceniem: mysql> unlock tables; widocznym na rys. 6. Aktywowanie serwera slave następuje poprzez uruchomienie wątków poleceniem: mysql> start slave; pokazanym na rys. 7. Po uruchomieniu tej funkcji serwer slave powinien połączyć się z serwerem master oraz pobrać wszelkie nowe rekordy z bazy. W celu sprawdzenia działania mechanizmu replikacji, można dodać wpis w tabeli (należącej do bazy danych, która jest replikowana) na serwerze master a następnie sprawdzić czy zmiany odniosły skutek także na serwerze slave. W razie problemów warto sprawdzić dziennik binarny serwera master i dzienniki błędów obu serwerów. 4 Podsumowanie W rozdziale przedstawiono w zarysie problematykę replikacji baz danych. Zestawiono istniejące sposoby replikacji dla różnych systemów, z których wynika, że replikacja, jakkolwiek pożądana, jest ciągle w fazie rozwojowej. Dla bliższego zrozumienia działania replikacji zaprezentowany został praktyczny przykład replikacji dla bazy MySQL. Pomimo, że sama instalacja jest stosunkowo prosta, to konfiguracja złożonego środowiska replikacji może okazać się znacznie bardziej wymagająca. Poprawę wydajności systemu można uzyskać poprzez zastosowanie mechanizmu replikacji na klastrach, który poprawia rozkład obciążeń, zapewnia równomierny dostęp do danych oraz gwarantuje spójność i tolerowanie błędów. Literatura 1. Bębel B., Wrembel R.: Replikacja danych w bazach danych, 8 Seminarium PLOUG, Warszawa, 2003. 2. Connolly T., Begg C.: A Practical Approach to Design, Implementation and Management, 2 nd Edition, Addison Wesley, 1998. 3. Dubois P.: MySQL podręcznik administratora, Helion, 2005. 4. Gray J. N., Eswaran K. P., Lorie R. A., Traiger I. L.: The Notions of Consistency and Predicate Locks in a Database System, Communications of the ACM, pp. 624 633, 1976. 5. Hwang S. Y., Lee K. S., Chin Y. H.: Data Replication in a Distributed System a Performance Study, Proc. 7 th Intel Conf. Database and Expert Systems Applications, pp. 708-717, 1996. 6. Lal K., Rak T.: Linux a technologie klastrowe, MIKOM, 2005. 7. Nicola M., Jarke M.: Performance Modeling of Distributed and Replicated Databases, Revised Survey, IEEE Transactions on Knowledge and Data Engineering, Vol. 12, No. 4, pp. 645-672, 2000. 8. Wiesmann M.: Group Communications and Database Replication Techniques, Issues and Performance, PhD thesis, Polytechnique de Lausanne, Switzerland, 2002. 9. www.ibm.com 10. www.microsoft.com 11. www.mysql.com 12. www.oracle.com 13. www.postgresql.org 14. www.progress.com 15. www.sybase.com 162