Każdy duży projekt zaczynał się od kilku serwerów. Na początku był jeden serwer DB, później dodano do niego urządzenia podrzędne w celu skalowania odczytu. A potem – przestań! Jest jeden pan, ale jest wielu niewolników; jeśli jeden z niewolników odejdzie, wszystko będzie dobrze, ale jeśli mistrz odejdzie, będzie źle: przestój, administratorzy próbują podnieść serwer. Co robić? Zarezerwuj mistrza. Mój kolega Paweł już o tym pisał , nie będę tego powtarzał. Zamiast tego powiem Ci, dlaczego zdecydowanie potrzebujesz Orchestratora dla MySQL!
Zacznijmy od głównego pytania: „Jak przeniesiemy kod na nową maszynę, gdy mistrz odejdzie?”
- Najbardziej podoba mi się schemat z VIP (Virtual IP), o czym porozmawiamy poniżej. To najprostsza i najbardziej oczywista metoda, choć ma oczywiste ograniczenie: master, który będziemy rezerwować, musi przy nowej maszynie znajdować się w segmencie L2, czyli o drugim DC możemy zapomnieć. A tak na marginesie, jeśli trzymać się zasady, że duży L2 jest zły, bo L2 jest tylko na szafę, a L3 jest między szafami, a taki schemat ma jeszcze więcej ograniczeń.
- Możesz wpisać nazwę DNS w kodzie i rozwiązać ją za pomocą /etc/hosts. Tak naprawdę nie będzie żadnego rozstrzygnięcia. Zaleta schematu: nie ma ograniczeń charakterystycznych dla pierwszej metody, to znaczy możliwe jest zorganizowanie cross-DC. Ale wtedy pojawia się oczywiste pytanie: jak szybko możemy dostarczyć zmianę do /etc/hosts za pośrednictwem Puppet-Ansible?
- Możesz nieco zmienić drugą metodę: zainstaluj na wszystkich serwerach WWW buforujący DNS, przez który kod trafi do głównej bazy danych. Możesz ustawić TTL 60 dla tego wpisu w DNS. Wydaje się, że metoda, jeśli zostanie poprawnie wdrożona, jest dobra.
- Schemat z odkrywaniem usług, sugerujący użycie Consul i itp.
- Ciekawa opcja z . Musisz przekierować cały ruch do MySQL przez ProxySQL; sam ProxySQL może określić, kto jest mistrzem. Swoją drogą o jednej z możliwości wykorzystania tego produktu przeczytacie w moim .
Autor Orchestratora pracujący w Githubie najpierw zaimplementował pierwszy schemat z VIP-em, a następnie przekonwertował go na schemat z consulem.
Typowy układ infrastruktury:
Od razu opiszę oczywiste sytuacje, które należy wziąć pod uwagę:
- Adres VIP nie powinien być zarejestrowany w konfiguracji na żadnym z serwerów. Wyobraźmy sobie sytuację: urządzenie główne uruchomiło się ponownie i podczas ładowania Orchestrator przeszedł w tryb pracy awaryjnej i uczynił jednego z urządzeń podrzędnych urządzeniem głównym; potem wstał stary mistrz, a teraz VIP jest w dwóch samochodach. To jest złe.
- Dla orkiestratora będziesz musiał napisać skrypt wywołujący starego i nowego mistrza. Na starym masterze musisz uruchomić ifdown, a na nowym masterze – ifup vip. Byłoby miło uwzględnić w tym skrypcie również informację, że w przypadku przełączenia awaryjnego port na starym przełączniku głównym jest po prostu wyłączany, aby uniknąć rozszczepienia mózgu.
- Po tym, jak Orchestrator wywoła Twój skrypt, aby najpierw usunąć VIP i/lub wygasić port na przełączniku, a następnie wywoła skrypt podnoszący VIP na nowym urządzeniu głównym, nie zapomnij użyć polecenia arping, aby poinformować wszystkich, że nowy VIP jest teraz Tutaj.
- Wszyscy slave powinni mieć read_only=1, a gdy tylko awansujesz niewolnika na mastera, powinien on mieć read_only=0.
- Nie zapominajmy, że panem może zostać każdy niewolnik, którego do tego wybraliśmy (Orkiestrator ma cały mechanizm preferencji, którego niewolnika uznać za kandydata na nowego pana w pierwszej kolejności, a który w drugiej kolejności, a który niewolnik powinien w żadnym wypadku nie zostać wybrany na mistrza). Jeśli niewolnik stanie się mistrzem, wówczas obciążenie niewolnika pozostanie na nim, a obciążenie mistrza zostanie dodane, należy to wziąć pod uwagę.
Po co Ci Orchestrator, jeśli go nie masz?
- Orchestrator ma bardzo przyjazny dla użytkownika interfejs graficzny, który wyświetla całą topologię (patrz zrzut ekranu poniżej).
- Orchestrator może śledzić, które urządzenia podrzędne są opóźnione i gdzie ogólnie replikacja uległa awarii (do programu Orchestrator dołączone są skrypty służące do wysyłania wiadomości SMS).
- Orchestrator powie Ci, którzy urządzenia slave mają błędny GTID.
Interfejs Orchestratora:
Co to jest błędny GTID?
Aby Orchestrator mógł działać, muszą spełniać dwa główne wymagania:
- Konieczne jest włączenie pseudo GTID na wszystkich komputerach w klastrze MySQL; mamy włączone GTID.
- Konieczne jest, aby wszędzie był jeden typ binlogów, możesz użyć instrukcji. Mieliśmy konfigurację, w której master i większość niewolników miała Row, a dwaj historycznie pozostawali w trybie mieszanym. W rezultacie Orchestrator po prostu nie chciał podłączyć tych urządzeń podrzędnych do nowego urządzenia nadrzędnego.
Pamiętaj, że w produkcyjnym niewolniku najważniejsza jest jego spójność z mistrzem! Jeśli masz włączony globalny identyfikator transakcji (GTID) zarówno na komputerze głównym, jak i podrzędnym, możesz użyć funkcji gtid_subset, aby dowiedzieć się, czy na tych komputerach faktycznie wykonano te same żądania zmiany danych. Możesz przeczytać więcej na ten temat .
W ten sposób Orchestrator pokazuje poprzez błędny GTID, że na urządzeniu podrzędnym znajdują się transakcje, których nie ma na urządzeniu głównym. Dlaczego to się dzieje?
- Read_only=1 nie jest włączone na urządzeniu podrzędnym, ktoś się połączył i wykonał żądanie zmiany danych.
- Super_read_only=1 nie jest włączone na urządzeniu podrzędnym, wówczas administrator, myląc serwer, wszedł i wykonał tam żądanie.
- Jeśli wziąłeś pod uwagę oba poprzednie punkty, to jest jeszcze jeden trik: w MySQL żądanie opróżnienia binlogów również trafia do binloga, więc przy pierwszym spłukaniu na masterze i wszystkich slavech pojawi się błędny GTID. Jak tego uniknąć? W Perona-5.7.25-28 wprowadzono ustawienie binlog_skip_flush_commands=1, które zabrania zapisywania danych w binlogach. Istnieje już ustalony na stronie mysql.com .
Podsumuję wszystkie powyższe. Jeśli nie chcesz jeszcze używać programu Orchestrator w trybie przełączania awaryjnego, przełącz go w tryb obserwacji. Wtedy zawsze będziesz miał przed oczami mapę interakcji maszyn MySQL i wizualną informację o tym, jaki typ replikacji jest na każdej maszynie, czy slave'y są opóźnione i, co najważniejsze, jak spójne są z masterem!
Oczywistym pytaniem jest: „Jak powinien działać Orchestrator?” Musi wybrać nowego mastera z obecnych slaveów, a następnie ponownie podłączyć do niego wszystkich slaveów (do tego potrzebny jest GTID; jeśli używasz starego mechanizmu z binlog_name i binlog_pos, to przełączamy slave'a z bieżącego mastera na nowy jest po prostu niemożliwe!). Zanim mieliśmy Orchestratora, kiedyś musiałem to wszystko robić ręcznie. Stary mistrz wisiał z powodu wadliwego kontrolera Adaptec; miał około 10 niewolników. Musiałem przenieść VIP-a z głównego na jednego z niewolników i ponownie podłączyć do niego wszystkich pozostałych niewolników. Ile konsol musiałem otworzyć, ile jednoczesnych poleceń wprowadziłem... Musiałem poczekać do 3 w nocy, zdjąć obciążenie ze wszystkich slaveów oprócz dwóch, zrobić pierwszą maszynę z dwóch masterów, natychmiast podłączyć drugą maszynę do niego, więc podłącz wszystkie pozostałe urządzenia podrzędne do nowego urządzenia nadrzędnego i zwróć ładunek. Ogólnie strasznie...
Jak działa Orchestrator, gdy przechodzi w tryb pracy awaryjnej? Najłatwiej to zilustrować na przykładzie sytuacji, w której chcemy uczynić z mistrza maszynę potężniejszą, nowocześniejszą niż obecnie.
Rysunek przedstawia środek procesu. Co zostało już zrobione do tego momentu? Powiedzieliśmy, że chcemy uczynić jakiegoś niewolnika nowym panem, Orchestrator zaczął po prostu ponownie podłączać do niego wszystkich pozostałych niewolników, przy czym nowy mistrz działał jako maszyna tranzytowa. Przy tym schemacie nie występują żadne błędy, wszystkie urządzenia podrzędne działają, Orchestrator usuwa VIP ze starego mastera, przenosi go do nowego, ustawia read_only=0 i zapomina o starym masterze. Wszystko! Przestojem naszego serwisu jest czas transferu VIP, który wynosi 2-3 sekundy.
To wszystko na dziś, dziękuję wszystkim. Wkrótce pojawi się drugi artykuł o Orchestratorze. W słynnym sowieckim filmie „Garaż” jeden z bohaterów powiedział: „Nie poszedłbym z nim na rekonesans!” Zatem, Orkiestrze, wybrałbym się z tobą na rekonesans!
Źródło: www.habr.com