Replikacje baz danych w praktyce

Transkrypt

1 Rozdział I 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, Rzeszów, Polska {kswider, trak}@prz-rzeszow.pl

2 K. Świder, T. Rak 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. 2

3 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 sieciowy 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 2 Inaczej replikacja: równorzędna, wszędzie, n-dróg lub jeden-do-jeden. 3

4 K. Świder, T. Rak kolejce odroczonych transakcji. Odroczone transakcje są następnie rozprowadzane na pozostałe lokalizacje replikacji w regularnych odstępach 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 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ą uaktualniane w tej samej transakcji, co pozwala na wykrywanie konfliktów zanim transakcja zostanie zatwierdzona i w ten sposób zachowani spójności 4

5 Replikacje baz danych w praktyce danych. Uzyskuje się poprawność transakcji przy jednoczesnym zwiększeniu czasu reakcji, gdyŝ repliki są uaktualniane bezpoś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. 5

6 K. Świder, T. Rak Tabela 1. Replikacje w systemach baz danych [9] [10] [11] [12] [13] [14] [15] Replikacja Baza danych Oracle Kopii głównej RO (Read Only), RW (Read Write), Inne 4 Synchroniczna Lokalizacji nadrzędnych + + Informix + IBM DB2 RO + Sybase RO Inna 5 Progress RO, Inna PostgreSQL RO, Inna 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. 6

7 Replikacje baz danych w praktyce 3.2 Przykład replikacji w MySQL Replikacja została wprowadzona po raz pierwszy do serwerów MySQL w wersji 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 i slave ) wykorzystując do tego celu bazę danych MySQL w wersji 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 7

8 K. Świder, T. Rak wpisać w sekcji [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. 8

9 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. 9

10 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, Connolly T., Begg C.: A Practical Approach to Design, Implementation and Management, 2 nd Edition, Addison Wesley, Dubois P.: MySQL podręcznik administratora, Helion, 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 , 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 , Lal K., Rak T.: Linux a technologie klastrowe, MIKOM, 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 , Wiesmann M.: Group Communications and Database Replication Techniques, Issues and Performance, PhD thesis, Polytechnique de Lausanne, Switzerland,

11 Replikacje baz danych w praktyce Paper title: Database Replication in Practice Abstract. Duplicating information stored on servers is a crucial issue, which ensures both the increase in system efficiency and the safety of data storage. The problem of database replications with focus on applied methods, models and types is outlined in this chapter. Possibilities of using replications in cluster bases and also the configuration of real system with replication in MySQL database are described. Moreover, the attempt to arrange Polish terminology concerning discussed issue was taken. Słowa kluczowe: replikacja, klasyfikacje replikacji, rozproszone bazy danych, mysql. 11