Replikacja to jedno ze słów-kluczy, które pojawiają się na spotkaniach programistów, kierownictwa czy też
działu zarządzania firm zajmujących się tworzeniem i utrzymaniem działania
serwisu internetowego. Zazwyczaj słowo to ma pozytywne konotacje – kojarzy się
z nowoczesnymi rozwiązaniami, wysoką dostępnością, bezpieczeństwem, możliwością
rozwoju serwisu. Prowadzi to często do sytuacji – analogicznie zresztą, jak w
przypadku innych „głośnych” technologii, jak sharding, NoSQL, cloud computing – w
której podjęta zostaje decyzja o zastosowaniu danego rozwiązania bez
świadomości, że chwytliwa nazwa to jedno, a faktyczne możliwości i ograniczenia
to drugie. Często ograniczenia te pojawiają się dopiero w późniejszym etapie, w
momencie gdy projekt jest na tyle zaawansowany, że trudno już wrócić do deski
kreślarskiej i fazy projektowania.
Na czym polega replikacja?
Jeśli
decydujemy się na wdrażanie projektu opartego na jakiejś technologii,
podstawową sprawą jest to, żeby choć jedna osoba wiedziała, na czym ta cała
technologia polega. To tyczy się także replikacji. Nie mówimy tu o szczegółach
wewnętrznych rozwiązań stosowanych przez MySQL, ale o naprawdę podstawowych
podstawach.
- Jaka jest stosowana architektura? Architektura master – slave.
- W
jaki sposób przenoszone są zmiany z serwera master na serwer slave? Przy pomocy
binlogów kopiowanych z serwera na serwer. - Czy replikacja jest odporna na
awarie? Niestety, w dużej mierze nie –
zazwyczaj potrzebna jest ręczna interwencja administratora. - Czy wydajność
serwera slave jest taka sama, jak wydajność serwera master? W obecnej stabilnej
wersji MySQL serwer slave zawsze będzie w stanie przetworzyć mniej modyfikacji
niż master (oczywiście przy założeniu, że obie maszyny są identyczne co do
wydajności). - Czy replikację możemy traktować jako kopię bezpieczeństwa? W
żadnym przypadku, polecenie usunięcia danych na serwerze master zreplikuje się
także na serwer slave i dane zostaną usunięte. Jedyną sensowną opcją backupu
jest wykonywanie tradycyjnej kopii danych w postaci binarnej lub zrzutu danych
do formatu sql. - Czy replikacja jest w stanie zwiększyć ilość zapisów do bazy,
która może zostać obsłużona? Nie. W szczególności rozwiązaniem tego problemu
nie jest replikacja typu master – master. Jedynym sposobem na skalowanie
zapisów jest sharding bądź zainwestowanie w szybszy podsystem dyskowy (dyski
SSD, SSD na PCIe itp.).
Tego typu informacje są niezbędne, aby podejmować pewne
decyzje na etapie projektu.
Zrozumienie potrzeb serwisu
Dalszy
etap to dokładne zrozumienie potrzeb własnego serwisu. Co konkretnie chcemy
osiągnąć? Większą wydajność, możliwość obsłużenia większej ilości jednoczesnych
wizyt na stronie? Bezpieczeństwo serwisu, zapewnienie możliwości funkcjonowania
serwisu w razie awarii jednego z serwerów MySQL? Jeśli koncentrujemy się na wydajności,
to w czym jest problem? Zapytania typu SELECT czy też zapytania modyfikujące
dane? Czy serwis jest w stanie zaakceptować to, że część danych będzie
nieaktualna, opóźniona o kilka-kilkadziesiąt sekund?
Odpowiedzi
na te pytania są niezbędne, aby ustalić, jak ma działać serwis, jaki sprzęt
trzeba kupić, ile tego sprzętu potrzeba. Przykładowo, załóżmy, że chcemy
zapewnić dostępność serwisu w sieci na wypadek awarii jednej z maszyn. W tej
sytuacji trzeba pamiętać o zakupie takiej ilości serwerów, żeby ich wystarczyło,
nawet gdy jeden z nich nie będzie działał. Obciążenie rozłoży się na pozostałe
maszyny, ale to już głowa projektanta w tym, aby miały one wystarczające zasoby,
aby to obciążenie przejąć. Inny przykład – jeśli serwis często modyfikuje bazę
danych, trzeba się upewnić, że serwer slave, który z definicji jest mniej
wydajny w tego typu operacjach (na serwerze master dane mogą być modyfikowane
równolegle w wielu wątkach, na serwerze slave modyfikacje są wprowadzane tylko
przez jeden wątek), będzie w stanie nadążyć za serwerem master. Trzeba także
wziąć pod uwagę, że w związku z chwilowymi opóźnieniami w wprowadzaniu
modyfikacji serwer slave będzie zawierał nieaktualną wersję danych. Serwis
musi zostać napisany tak, aby był w stanie obsłużyć tego typu sytuację. Jeśli
taka sytuacja jest niedopuszczalna, to trzeba kupić mocniejszy serwer slave,
tak aby był w stanie nadążyć za zmianami danych i problem ten nie występował.
Wdrażanie replikacji rodzi kolejne pytania
Etap
projektowania mamy za sobą. W trakcie tworzenia serwisu opartego o replikowaną
bazę danych trzeba jednak pamiętać o kolejnych elementach. Podstawowa sprawa –
w jaki sposób ma zostać obsłużona awaria jednego z serwerów? Czy stosujemy
jakiegoś rodzaju wirtualny adres IP, który będzie przenoszony pomiędzy
serwerami na wypadek awarii jednego z nich, czy też może obsługa realizowana
będzie po stronie aplikacji, która sama wykryje brak połączenia do danego
serwera i odpowiednio rozłoży ruch pomiędzy pozostałymi serwerami bazodanowymi?
W
jaki sposób serwis zachowa się, jeśli awarii ulegnie serwer master? Kolejne,
nawet ważniejsze pytanie – czy serwis będzie umiał obsłużyć sytuację, gdy
serwer master ulegnie awarii, a potem ponownie zacznie funkcjonować? Jeśli na
czas awarii ruch został przepięty na inny serwer, to stary serwer master nie zawiera
aktualnych danych – nie wolno ponownie przenosić na niego ruchu, bo zrobi się
poważne zamieszanie.
Powyższe to tylko wierzchołek góry lodowej, jeśli chodzi o projektowanie
serwisu opartego na replikacji. Bez osoby zaznajomionej z tematem trudno jest przygotować
serwis, który faktycznie będzie się dobrze skalował i nie będą się pojawiały
problemy z jego wdrożeniem i funkcjonowaniem. Dobrze jest przed rozpoczęciem
tworzenia serwisu skontaktować się z administratorami, którzy będą czuwać nad
serwerami, szczególnie jeśli wśród nich jest także administrator baz danych.
Każda firma hostingowa, każdy administrator ma pewną specyfikę działania, pewne
przetestowane i wdrożone rozwiązania. Administratorzy mają doświadczenie w
różnego rodzaju wdrożeniach i są na bieżąco z tzw. „dobrymi praktykami”.
Opisane
w tym artykule przykłady dają pojęcie, dlaczego takie wsparcie jest ważne –
pewne decyzje trzeba podejmować już na bardzo wczesnym etapie. Dobrze jest mieć
wtedy możliwość skonsultowania się ze specjalistą.
Autor: Krzysztof
Książek, Administrator Sieci w Kei.pl
