Przełączanie awaryjne replikacji MySQL (i innych) — czy powinno być zautomatyzowane?

Automatyczne przełączanie awaryjne dla replikacji MySQL było przedmiotem dyskusji od wielu lat.

Czy to dobrze, czy źle?

Osoby z długą pamięcią w świecie MySQL mogą pamiętać awarię GitHuba w 2012 roku, która była spowodowana głównie przez oprogramowanie podejmujące błędne decyzje.

GitHub właśnie przeszedł na kombinację MySQL Replication, Corosync, Pacemaker i Percona Replication Manager. PRM zdecydował się na przełączenie awaryjne po niepowodzeniu kontroli kondycji na master, który został przeciążony podczas migracji schematu. Wybrano nowego mistrza, ale wypadł on słabo z powodu zimnych pamięci podręcznych. Wysokie obciążenie zapytaniami z ruchliwej witryny spowodowało ponowne niepowodzenie pulsów PRM na zimnym masterze, a następnie PRM wyzwolił kolejne przełączanie awaryjne do oryginalnego mastera. A problemy po prostu trwały, jak podsumowano poniżej.

Szybko do przodu o kilka lat, a GitHub powraca z dość wyrafinowanym frameworkiem do zarządzania replikacją MySQL i automatycznym przełączaniem awaryjnym! Jak mówi Shlomi Noach:

„W tym celu stosujemy automatyczne przełączanie awaryjne. Czas potrzebny człowiekowi na przebudzenie i naprawę uszkodzonego urządzenia głównego przekracza nasze oczekiwania co do dostępności, a obsługa takiego przełączenia awaryjnego jest czasami nietrywialna. Spodziewamy się, że awarie urządzeń głównych zostaną automatycznie wykryte i przywrócone w ciągu 30 sekund lub mniej, a przełączenie awaryjne spowoduje minimalną utratę dostępnych hostów”.

Większość firm nie jest GitHub, ale można argumentować, że żadna firma nie lubi przestojów. Przestoje są uciążliwe dla każdej firmy, a także kosztują. Domyślam się, że większość firm prawdopodobnie chciałaby mieć jakiś rodzaj zautomatyzowanego przełączania awaryjnego, a powody, dla których go nie wdrażają, to prawdopodobnie złożoność istniejących rozwiązań, brak kompetencji we wdrażaniu takich rozwiązań lub brak zaufania do oprogramowania do podjęcia. tak ważna decyzja.

Istnieje wiele zautomatyzowanych rozwiązań do przełączania awaryjnego, w tym (ale nie tylko) MHA, MMM, MRM, mysqlfailover, Orchestrator i ClusterControl. Niektóre z nich są obecne na rynku od kilku lat, inne są nowsze. To dobry znak, wiele rozwiązań oznacza, że ​​istnieje rynek i ludzie próbują rozwiązać problem.

Kiedy projektowaliśmy automatyczne przełączanie awaryjne w ClusterControl, zastosowaliśmy kilka zasad przewodnich:

• Przed przełączeniem awaryjnym upewnij się, że mistrz naprawdę nie żyje

  W przypadku partycji sieciowej, gdzie oprogramowanie awaryjne traci kontakt z masterem, przestanie go widzieć. Ale master może działać dobrze i może być widoczny dla reszty topologii replikacji.

  ClusterControl zbiera informacje ze wszystkich węzłów bazy danych, a także z wszelkich używanych serwerów proxy/systemów równoważenia obciążenia, a następnie buduje reprezentację topologii. Nie podejmie próby przełączenia awaryjnego, jeśli urządzenia podrzędne widzą urządzenie nadrzędne, ani jeśli ClusterControl nie jest w 100% pewien stanu urządzenia nadrzędnego.

  ClusterControl ułatwia również wizualizację topologii konfiguracji, a także stanu różnych węzłów (jest to zrozumienie stanu systemu przez ClusterControl na podstawie zebranych informacji).

  

• Przełączanie awaryjne tylko raz

  Wiele napisano o trzepotaniu. Jeśli narzędzie dostępności zdecyduje się na wielokrotne przełączanie awaryjne, może się to stać bardzo nieporządne. To niebezpieczna sytuacja. Każdy wybrany master, niezależnie od tego, jak krótki okres pełnił rolę mastera, może mieć własne zestawy zmian, które nigdy nie zostały zreplikowane na żaden serwer. Więc możesz skończyć z niespójnością wśród wszystkich wybranych mistrzów.

• Nie przełączaj awaryjnie na niespójnego niewolnika

  Wybierając niewolnika do awansu na mistrza, upewniamy się, że niewolnik nie ma niespójności, m.in. błędnych transakcji, ponieważ może to bardzo dobrze przerwać replikację.

• Tylko pisz do mistrza

  Replikacja przechodzi od urządzenia nadrzędnego do urządzenia podrzędnego. Pisanie bezpośrednio do niewolnika stworzyłoby rozbieżny zbiór danych, a to może być potencjalnym źródłem problemów. Ustawiamy slave'y na read_only i super_read_only w nowszych wersjach MySQL lub MariaDB. Zalecamy również użycie load balancera, np. ProxySQL lub MaxScale, aby chronić warstwę aplikacji przed podstawową topologią bazy danych i wszelkimi jej zmianami. System równoważenia obciążenia wymusza również zapisy na bieżącym urządzeniu głównym.

• Nie przywracaj automatycznie uszkodzonego wzorca

  Jeśli master uległ awarii i został wybrany nowy master, ClusterControl nie będzie próbował odzyskać uszkodzonego mastera. Czemu? Ten serwer może zawierać dane, które nie zostały jeszcze zreplikowane, a administrator musiałby przeprowadzić pewne badanie awarii. Ok, nadal możesz skonfigurować ClusterControl, aby wymazał dane z uszkodzonego mastera i dołączył go jako slave do nowego mastera - jeśli nie masz nic przeciwko utracie niektórych danych. Ale domyślnie ClusterControl pozwoli, aby uszkodzony master był, dopóki ktoś nie spojrzy na niego i nie zdecyduje się ponownie wprowadzić go do topologii.

Czy zatem należy zautomatyzować przełączanie awaryjne? To zależy od tego, jak skonfigurowałeś replikację. Okrągłe konfiguracje replikacji z wieloma zapisywalnymi masterami lub złożone topologie prawdopodobnie nie są dobrymi kandydatami do automatycznego przełączania awaryjnego. Podczas projektowania rozwiązania do replikacji będziemy trzymać się powyższych zasad.

W PostgreSQL

Jeśli chodzi o replikację strumieniową PostgreSQL, ClusterControl wykorzystuje podobne zasady do automatyzacji przełączania awaryjnego. W przypadku PostgreSQL ClusterControl obsługuje zarówno asynchroniczne, jak i synchroniczne modele replikacji między masterem a slave'ami. W obu przypadkach i w przypadku awarii, jako nowego mastera wybierany jest slave z najbardziej aktualnymi danymi. Uszkodzone mastery nie są automatycznie odzyskiwane/naprawiane, aby ponownie dołączyć do konfiguracji replikacji.

Podejmowanych jest kilka środków ochronnych, aby upewnić się, że uszkodzony master jest wyłączony i pozostaje w dół, m.in. jest usuwany z równoważenia obciążenia ustawionego w proxy i jest zabijany, jeśli m.in. użytkownik zrestartowałby go ręcznie. Nieco większym wyzwaniem jest tam wykrycie podziałów sieci między ClusterControl a urządzeniem nadrzędnym, ponieważ urządzenia podrzędne nie dostarczają żadnych informacji o stanie urządzenia nadrzędnego, z którego są replikowane. Dlatego proxy przed konfiguracją bazy danych jest ważne, ponieważ może zapewnić inną ścieżkę do mastera.

W MongoDB

Replikacja MongoDB w zestawie replik za pośrednictwem protokołu oplog jest bardzo podobna do replikacji dziennika binlog, więc dlaczego MongoDB automatycznie odzyskuje uszkodzony master? Problem nadal istnieje, a MongoDB rozwiązuje go, wycofując wszelkie zmiany, które nie zostały zreplikowane do urządzeń podrzędnych w momencie awarii. Dane te są usuwane i umieszczane w folderze „wycofania”, więc przywrócenie ich zależy od administratora.

Aby dowiedzieć się więcej, sprawdź ClusterControl; i zachęcamy do komentowania lub zadawania pytań poniżej.