pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 16
w
Replikacje baz danych w praktyce
1 Wstęp
da
.b
w
w
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.
pl
s.
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
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
K. Świder, T. Rak
R e p lik a 2
R e p lik a 1
R e p lik a 3
w
L o g ic z n a b a z a d a n y c h
w
Rys. 1. Baza danych z replikacją
da
.b
w
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
pl
s.
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
w
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ędnych2 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.
da
.b
w
w
pl
s.
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
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].
da
.b
w
w
a)
b)
Rys. 2. Graficzna reprezentacja klasyfikacji replikacji: a) Gray’a, b) Wiesmanna
pl
s.
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 bez156
w
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ć.
da
.b
w
w
pl
s.
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
Oracle
RO (Read Only), RW
(Read Write), Inne4
Lokalizacji nadrzędnych
Synchroniczna
Asynchroniczna
+
+
w
IBM DB2
RO
+
+
Sybase
RO
Inna5
Progress
RO, Inna6
+
7
+
Informix
w
PostgreSQL
MySQL
RO, Inna
8
RO, Inne
+
+
9
Inna
w
3.1 Bazy danych na klastrach
da
.b
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.
pl
s.
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
w
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.
da
.b
w
w
pl
s.
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
następujące opcje: log-bin10 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).
[mysqld]
w
w
Rys. 4. Start i sprawdzanie statusu serwera oraz blokowanie zapisu do tabel
w
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ń:
da
.b
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
nazwa pliku dziennika (jeżeli nie podano innej) składa się z nazwy serwera
i rozszerzenia -bin.13
--log-bin
pl
s.
Rys. 5. Określanie praw do bazy danych
10
Serwery, które będą pracować tylko jako slave nie wymagają wpisu log-bin.
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.
11
160
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;
w
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.
da
.b
w
w
Rys. 6. Pakowanie i odblokowywanie zapisu do tabel
mysql> load data from master;
pl
s.
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:
Rys. 7. Start oraz określanie informacji o serwerze nadrzędnym na konsoli serwera
podrzędnego
14
15
Skopiować należy jedynie nowe bazy użytkowników.
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;
w
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.
w
4 Podsumowanie
w
Literatura
1.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Bębel B., Wrembel R.: Replikacja danych w bazach danych, 8 Seminarium PLOUG, Warszawa,
2003.
Connolly T., Begg C.: A Practical Approach to Design, Implementation and Management, 2nd
Edition, Addison Wesley, 1998.
Dubois P.: MySQL – podręcznik administratora, Helion, 2005.
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.
Hwang S. Y., Lee K. S., Chin Y. H.: Data Replication in a Distributed System a Performance
Study, Proc. 7th Intel Conf. Database and Expert Systems Applications, pp. 708-717, 1996.
Lal K., Rak T.: Linux a technologie klastrowe, MIKOM, 2005.
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.
Wiesmann M.: Group Communications and Database Replication – Techniques, Issues and
Performance, PhD thesis, Polytechnique de Lausanne, Switzerland, 2002.
www.ibm.com
www.microsoft.com
www.mysql.com
www.oracle.com
www.postgresql.org
www.progress.com
www.sybase.com
pl
s.
2.
da
.b
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.
162

pobierz plik referatu

Transkrypt

Podobne dokumenty

Drukuj - Vavatech.pl

Rozproszone i obiektowe systemy baz danych Dr inż. Robert Wójcik

Replikacja danych w bazach danych Oracle9i