Replikacja Leader Based [Replikacja 2/5]

Ta strategia replikacji zakłada, że tylko jedna z replik przyjmuje żądania zapisu danych. Nazywamy ją lider lub master. Pozostałe repliki zwane follower lub slave przyjmują dane od lidera (replication stream) i w ten sposób nadrabiają zaległości, czyli synchronizują się. Repliki typu follower serwują tylko żądania odczytu danych. 

Ten sposób replikacji jest wykorzystywany przez PostgreSQL, MySQL, MongoDB, RabbitMQ oraz Kafka. 

Jak już wspomniałem, asynchroniczna replikacja jest powszechną metodą replikacji pomiędzy węzłami. Oznacza to, że potwierdzamy klientowi zapis, kiedy tylko jedna kopia (master) poprawnie przyjęła dane, a następnie w strategii leader-follower osobny proces wysyła je do pozostałych replik.

Co zrobić w sytuacji, kiedy lider przestanie odpowiadać? Jeśli był to tymczasowy problem sieciowy, niedostępność będzie trwała tylko chwilę, natomiast crash węzła to już bardziej poważny problem. Również celowo możemy chcieć zabić maszynę lidera, aby na przykład zaktualizować oprogramowanie albo przenieść go na serwer z inną konfiguracją sprzętową. 

W takim wypadku trzeba wybrać nowego lidera.

Pierwszym zadaniem, które trzeba wykonać, jest zmiana routingu. Po pierwsze, klienty* muszą zacząć czytać z nowego lidera (problem service discovery), a repliki typu follower – kopiować z innego węzła. Po drugie, nowy lider musi się upewnić, że posiada pełną kopię poprzedniego lidera – przecież dzieje się to asynchronicznie, istnieje zatem zagrożenie, że poprzedni lider przed upadkiem nie zdążył wysłać wszystkich danych do swoich naśladowców.

To oczywiście główna wada tego podejścia (jednego lidera), że kiedy zginie na polu walki, to minie chwila, zanim ktoś go zastąpi. Zaletą jest natomiast prostota – replikacja odbywa się tylko w jedną stronę, w przeciwieństwie do replikacji leader-leader (tutaj link do następnego artykuły)

* klienty, a nie klienci – też byłem zdziwiony. Klienty to liczba mnoga rzeczowników nieożywionych. Na stole leżą piloci czy piloty? To zależy, czy właśnie zdarzyła się katastrofa lotnicza, czy skończyłeś oglądać Netflixa.

Źródła 

  1. Designing Data Intensive Applications – M. Kleppmann
  2. Replikacja danych – Wikipedia

Udostępnij ten wpis


Dobrnąłeś do końca. Jeśli ten artykuł był dla Ciebie wartościowy i chcesz otrzymywać informacje o kolejnych, to zapraszam Cię do zapisania się do listy mailingowej. Gwarantuję zero spamu.

Radek.

Inne artykuły

ML w AWS – Sagemaker Autopilot

Automatyczne tworzenie modeli uczenia maszynowego z pełną widocznością w usłudze AWS Sagemaker – korzyści z wygenerowanego Jupyter Notebooka.

ML w AWS – Sagemaker Studio – IDE w przeglądarce

Sagemaker Studio – interaktywne środowisko dla Data Scientist. Z Jupyter Notebooks na pokładzie, oferuje współpracę, śledzenie eksperymentów i integrację z systemem kontroli wersji. Przegląd quasi …

ML w AWS – wstęp do usługi Sagemaker

Sagemaker: Wytwarzanie usług ML w chmurze AWS na nowym poziomie Odkryj potężną usługę Sagemaker, która gromadzi wszystkie niezbędne funkcjonalności związane z wytwarzaniem usług uczenia maszynowego w …

Rozwijasz czy produkujesz oprogramowanie?

Opracowywanie przepisów to proces uczenia się metodą prób i błędów. Nie oczekujesz, że pierwsza próba nowego dania wykonana przez szefa kuchni będzie ostatnią. W rzeczywistości …

Lean software development – eliminacja strat

Dowiedz się, jak wyeliminować marnotrawstwo i przyjąć zasady szczupłego rozwoju oprogramowania, aby dostarczyć więcej wartości swoim klientom przy mniejszym nakładzie pracy.

2 thoughts on “Replikacja Leader Based [Replikacja 2/5]

Comments are closed.