Replikacja – słowo klucz które utożsamiane jest z zaawansowaną technologię, skalowalnością, wysoką dostępnością danych. Wszystko zapowiada się znakomicie, projekt aplikacji wygląda pięknie na slajdach Keynote czy Powerpointa, przełożeni są oszołomieni możliwościami, jakie roztacza ta technologia. Pytanie tylko, czy replikacja faktycznie jest dla Ciebie?

O replikacji, w szczególności o mechanizmach jej działania pisałem już niejednokrotnie na tym blogu. Nie będę wrzucać tu wszystkich linków, zainteresowanych zapraszam do kliknięcia w tag ‘replikacja’ znajdujący się w chmurze tagów po prawej stronie. Tym razem zastanowimy się, dla kogo replikacja nie jest przeznaczona.

Aby to ustalić, konieczne jest odpowiedzenie sobie na kilka pytań.

Czy jesteś świadomy, przynajmniej co do głównych zasad, w jaki sposób działa replikacja?

Czy jesteś świadomy, że replikacja w żaden sposób nie może być stosowana jako sposób na uzyskanie kopii zapasowej bazy danych?

Czy wiesz, że replikacja, także replikacja typu master – master, nie stanowi sposobu na skalowanie zapisów?

Czy jesteś świadomy tego, że operacje zapisu na serwerze slave to no-no i skuteczny sposób aby doprowadzić do rozsynchronizowania się całości konfiguracji (teoretycznie slave można przestawić w tryb read-only, ale nawet wtedy superuser może modyfikować dane)?

Czy znasz ograniczenia replikacji w MySQL, w szczególności czy wiesz że wszelkie mechanizmy filtrowania i przepisywania replikowanych baz danych (replicate-do-db, replicate-ignore-db,  replicate-rewrite-db a także ich wariancje z wildcardami) działają tylko i wyłącznie na domyślnej bazie danych (tej, która została wybrana poleceniem USE baza;) i nie będą działać w przypadku odwołań typu:

INSERT INTO baza.tabela VALUES (...);

Czy wiesz jak Twoja aplikacja będzie korzystała z bazy danych – czy rozkładasz SELECTy na obie bazy (master i slave), czy wprowadzasz podział: modyfikacje – master, odczyty – slave, a może baza slave będzie służyć tylko i wyłącznie jako standby, na wypadek padu serwera master?

Czy Twoja aplikacja umie obsłużyć sytuację, w której serwer master przestaje odpowiadać? Założenie, że przepięcie następuje ręcznie także może być właściwą odpowiedzią na to pytanie.

Czy, jeśli Twoja aplikacja samodzielnie przepnie ruch na serwer slave, to będzie umiała obsłużyć sytuację, w której serwer master ponownie stanie się dostępny? Najlepszym rozwiązaniem byłoby nie robić wtedy nic i dać czas administratorowi na porównanie zawartości obu serwerów. Gdyby nastąpiło automatyczne przepięcie ruchu zapisów ponownie na serwer master to zasadniczo doszłoby do katastrofy i pozostałoby tylko ręczne synchronizowanie danych rekord po rekordzie.

Jeśli ktoś nawet na jedno z pytań odpowiedział “nie”, a osoba ta nie ma pod ręką kogoś innego (administratora baz danych, programisty, administratora systemu), kto byłby w stanie odpowiedzieć na to pytanie pozytywnie, to moim zdaniem lepiej będzie, jeśli wstrzyma się z wdrażaniem replikacji produkcyjnie. Pewne wiadomości po prostu trzeba posiadać, pewnych ograniczeń trzeba być świadomym aby poprawnie wdrożyć projekt opierający się na replikacji.

To, że w przypadku MySQL skonfigurowanie replikacji jest banalnie proste, nie znaczy że replikacja nie potrafi doprowadzić do poważnego (i trudnego w odkręceniu) zamieszania z danymi, a w najgorszym wypadku nawet do ich utraty. Trzeba być tego świadomym. Co prawda, można się uczyć na błędach, ale pytanie czy to się opłaca…