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