Zautomatyzowane przełączanie awaryjne jest w zasadzie koniecznością dla wielu aplikacji — czas pracy jest oczywisty. Ciężko jest zaakceptować, że aplikacja nie działa przez 20 lub 30 minut, ponieważ ktoś musi zostać przywołany, aby się zalogować i zbadać sytuację przed podjęciem działań.
W prawdziwym świecie konfiguracje replikacji z czasem rosną, stając się złożone, a czasem bałaganiarskie. I są ograniczenia. Na przykład nie każdy węzeł w konfiguracji jest dobrym kandydatem na mistrza. Może sprzęt jest inny i niektóre repliki mają słabszy sprzęt, ponieważ są przeznaczone do obsługi określonych rodzajów obciążenia? Może jesteś w trakcie migracji do nowej wersji MySQL i niektóre slave'y zostały już zaktualizowane? Wolisz nie mieć mastera w nowszej wersji replikującego się do starych replik, ponieważ może to przerwać replikację. Jeśli masz dwa centra danych, jedno aktywne, a drugie do odzyskiwania po awarii, możesz wybrać kandydatów na mastera tylko w aktywnym centrum danych, aby utrzymać mastera blisko hostów aplikacji. To tylko przykładowe sytuacje, w których możesz potrzebować ręcznej interwencji podczas procesu przełączania awaryjnego. Na szczęście wiele narzędzi do przełączania awaryjnego ma opcję przejęcia kontroli nad procesem za pomocą białych i czarnych list. W tym poście na blogu chcielibyśmy pokazać kilka przykładów, w jaki sposób możesz wpłynąć na algorytm ClusterControl do wybierania kandydatów na mistrzów.
Konfiguracja białej i czarnej listy
ClusterControl daje możliwość zdefiniowania zarówno białej, jak i czarnej listy replik. Biała lista to lista replik, które mają zostać kandydatami na mistrzów. Jeśli żaden z nich nie jest dostępny (albo dlatego, że nie działa, występują błędne transakcje lub istnieją inne przeszkody, które uniemożliwiają promocję któregokolwiek z nich), przełączanie awaryjne nie zostanie wykonane. W ten sposób możesz określić, które hosty są dostępne, aby zostać głównym kandydatem. Z drugiej strony czarne listy określają, które repliki nie nadają się na kandydata na mistrza.
Obie te listy można zdefiniować w pliku konfiguracyjnym cmon dla danego klastra. Na przykład, jeśli Twój klaster ma identyfikator „1”, chcesz edytować „/etc/cmon.d/cmon_1.cnf”. W przypadku białej listy użyjesz zmiennej „replication_failover_whitelist”, w przypadku czarnej listy będzie to „replication_failover_blacklist”. Oba akceptują listę oddzieloną przecinkami „host:port”.
Rozważmy następującą konfigurację replikacji. Mamy aktywny master (10.0.0.141), który ma dwie repliki (10.0.0.142 i 10.0.0.143), obie działają jako pośrednie mastery i mają po jednej replice (10.0.0.144 i 10.0.0.147). Mamy również zapasowego mastera w oddzielnym centrum danych (10.0.0.145), który ma replikę (10.0.0.146). Te hosty są przeznaczone do użycia w przypadku katastrofy. Repliki 10.0.0.146 i 10.0.0.147 działają jako hosty zapasowe. Zobacz poniższy zrzut ekranu.
Biorąc pod uwagę, że drugie centrum danych jest przeznaczone tylko do odzyskiwania po awarii, nie chcemy, aby którykolwiek z tych hostów był promowany jako główny. W najgorszym przypadku podejmiemy działania ręczne. Infrastruktura drugiego centrum danych nie jest skalowana do rozmiaru produkcyjnego centrum danych (w centrum danych DR są o trzy repliki mniej), więc zanim będziemy mogli promować hosta w centrum danych DR, i tak potrzebne są ręczne działania. Nie chcielibyśmy również, aby promowana była replika zapasowa (10.0.0.147). Nie chcemy też, aby trzecia replika w łańcuchu została wybrana jako główna (chociaż można to zrobić za pomocą GTID).
Konfiguracja białej listy
Możemy skonfigurować białą lub czarną listę, aby upewnić się, że przełączanie awaryjne będzie obsługiwane zgodnie z naszymi upodobaniami. W tej konkretnej konfiguracji użycie białej listy może być bardziej odpowiednie - określimy, które hosty mogą być używane do przełączania awaryjnego, a jeśli ktoś doda nowy host do konfiguracji, nie zostanie on wzięty pod uwagę jako główny kandydat, dopóki ktoś ręcznie nie zdecyduje, że jest ok, aby z niego skorzystać i dodać go do białej listy. Gdybyśmy korzystali z czarnej listy, dodanie nowej repliki gdzieś w łańcuchu mogłoby oznaczać, że taka replika mogłaby teoretycznie zostać automatycznie użyta do przełączania awaryjnego, chyba że ktoś wyraźnie stwierdzi, że nie można jej użyć. Pozostańmy po bezpiecznej stronie i zdefiniujmy białą listę w naszym pliku konfiguracyjnym klastra (w tym przypadku jest to /etc/cmon.d/cmon_1.cnf, ponieważ mamy tylko jeden klaster):
replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306Aby zastosować zmiany, musimy się upewnić, że proces cmon został ponownie uruchomiony:
service cmon restartZałóżmy, że nasz master uległ awarii i ClusterControl nie może się z nim skontaktować. Zostanie zainicjowane zadanie przełączania awaryjnego:
Topologia będzie wyglądać jak poniżej:
Jak widać, stary master jest wyłączony i ClusterControl nie będzie próbował go automatycznie odzyskać. Do użytkownika należy sprawdzenie, co się stało, skopiowanie wszelkich danych, które mogły nie zostać zreplikowane do kandydata na mistrza i odbudowanie starego wzorca:
Następnie jest to kwestia kilku zmian topologii i możemy przywrócić topologię do pierwotnego stanu, po prostu zastępując 10.0.0.141 10.0.0.142:
Konfiguracja czarnej listy
Teraz zobaczymy, jak działa czarna lista. Wspomnieliśmy, że w naszym przykładzie może to nie być najlepsza opcja, ale spróbujemy ją dla ilustracji. Umieścimy na czarnej liście każdy host z wyjątkiem 10.0.0.141, 10.0.0.142 i 10.0.0.143, ponieważ są to hosty, które chcemy widzieć jako głównych kandydatów.
replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306Zrestartujemy również proces cmon, aby zastosować zmiany w konfiguracji:
service cmon restartProces przełączania awaryjnego jest podobny. Ponownie, po wykryciu głównej awarii, ClusterControl rozpocznie pracę awaryjną.
Kiedy replika może nie być dobrym kandydatem na mistrza
W tej krótkiej sekcji chcielibyśmy bardziej szczegółowo omówić niektóre przypadki, w których możesz nie chcieć promować danej repliki na nowego mistrza. Mamy nadzieję, że da to kilka pomysłów na przypadki, w których trzeba rozważyć wprowadzenie większej ręcznej kontroli nad procesem przełączania awaryjnego.
Inna wersja MySQL
Po pierwsze, jeśli twoja replika używa innej wersji MySQL niż master, nie jest dobrym pomysłem jej promowanie. Ogólnie rzecz biorąc, nowsza wersja jest zawsze niedopuszczalna, ponieważ replikacja z nowej do starej wersji MySQL nie jest obsługiwana i może nie działać poprawnie. Dotyczy to głównie głównych wersji (na przykład replikacja 8.0 do 5.7), ale dobrą praktyką jest całkowite unikanie tej konfiguracji, nawet jeśli mówimy o małych różnicach wersji (5.7.x+1 -> 5.7.x). Obsługiwana jest replikacja z niższej do wyższej/nowszej wersji, ponieważ jest to konieczne w procesie aktualizacji, ale mimo to wolałbyś tego uniknąć (na przykład, jeśli twój master jest na 5.7.x+1, wolałbyś go nie zastępować z repliką w wersji 5.7.x).
Różne role
Możesz przypisać różne role do swoich replik. Możesz wybrać jeden z nich, aby był dostępny dla deweloperów do testowania swoich zapytań na produkcyjnym zestawie danych. Możesz użyć jednego z nich do obciążenia OLAP. Możesz użyć jednego z nich do tworzenia kopii zapasowych. Bez względu na to, co to jest, zazwyczaj nie chcesz promować takiej repliki do poziomu mistrzowskiego. Wszystkie te dodatkowe, niestandardowe obciążenia mogą powodować problemy z wydajnością ze względu na dodatkowe obciążenie. Dobrym wyborem na kandydata na mastera jest replika, która obsługuje „normalne” obciążenie, mniej więcej tego samego typu, co obecny master. Możesz wtedy mieć pewność, że poradzi sobie z głównym obciążeniem po przełączeniu awaryjnym, jeśli obsłuży je wcześniej.
Różne specyfikacje sprzętowe
Wspomnieliśmy o różnych rolach replik. Nierzadko spotyka się również różne specyfikacje sprzętu, zwłaszcza w połączeniu z różnymi rolami. Na przykład zapasowe urządzenie podrzędne najprawdopodobniej nie musi być tak wydajne, jak zwykła replika. Deweloperzy mogą również testować swoje zapytania na wolniejszej bazie danych niż produkcyjna (głównie dlatego, że nie można oczekiwać takiego samego poziomu współbieżności w bazach rozwojowych i produkcyjnych), a na przykład można zmniejszyć liczbę rdzeni procesora. Konfiguracje odzyskiwania po awarii mogą również zostać zmniejszone, jeśli ich główną rolą będzie nadążanie za replikacją i oczekuje się, że konfiguracja DR będzie musiała być skalowana (zarówno w pionie, poprzez zwiększenie rozmiaru instancji, jak i w poziomie, przez dodanie większej liczby replik) zanim ruch zostanie do niego przekierowany.
Repliki opóźnione
Niektóre repliki mogą być opóźnione — jest to bardzo dobry sposób na skrócenie czasu odzyskiwania w przypadku utraty danych, ale czyni je bardzo złymi kandydatami na mistrzów. Jeśli replika zostanie opóźniona o 30 minut, albo stracisz te 30 minut transakcji, albo będziesz musiał czekać (prawdopodobnie nie 30 minut, ponieważ najprawdopodobniej replika może szybciej nadrobić zaległości), aż replika zastosuje wszystkie opóźnione transakcje. ClusterControl pozwala wybrać, czy chcesz poczekać, czy chcesz natychmiast przełączyć się w tryb awaryjny, ale działałoby to dobrze z bardzo małym opóźnieniem - maksymalnie dziesiątki sekund. Jeśli przełączanie awaryjne ma zająć kilka minut, po prostu nie ma sensu używać takiej repliki i dlatego dobrym pomysłem jest umieszczenie jej na czarnej liście.
Inne centrum danych
Wspomnieliśmy o zmniejszonych konfiguracjach DR, ale nawet jeśli drugie centrum danych jest skalowane do wielkości produkcji, nadal dobrym pomysłem może być utrzymywanie przełączeń awaryjnych tylko w jednym DC. Na początek aktywne hosty aplikacji mogą znajdować się w głównym centrum danych, dlatego przeniesienie urządzenia głównego do rezerwowego kontrolera domeny znacznie zwiększyłoby opóźnienie w przypadku zapytań dotyczących zapisu. Również w przypadku podziału sieci możesz chcieć poradzić sobie z tą sytuacją ręcznie. MySQL nie ma wbudowanego mechanizmu kworum, dlatego trudno jest poprawnie obsłużyć (w sposób automatyczny) utratę sieci między dwoma centrami danych.
