Każdy duży projekt zaczynał się od kilku serwerów. Na początku był jeden serwer DB, potem do niego dołączyły służby, aby skalować odczyt. I tutaj — stop! Mamy jednego mastera, a wiele slave'ów; jeśli jeden ze slave'ów odejdzie, wszystko będzie w porządku, a jeśli odejdzie master — będzie źle: przestój, admini w panice podnoszą serwer. Co robić? Zarezerwować mastera. Mój kolega Paweł już o tym pisał, , nie będę tego powtarzać. Zamiast tego opowiem, dlaczego Orkiestrator dla MySQL jest absolutnie niezbędny!
Zacznijmy od głównego pytania: „Jak przełączymy kod na nową maszynę, gdy odejdzie master?”.
- Schemat z VIP (Virtual IP) najbardziej mi się podoba, o nim porozmawiamy poniżej. Jest najprostszy i najbardziej oczywisty, chociaż ma wyraźne ograniczenie: master, którego będziemy rezerwować, musi znajdować się w segmencie L2 z nową maszyną, więc o drugim DC można zapomnieć. I, szczerze mówiąc, jeśli kierować się zasadą, że duże L2 to zło, ponieważ L2 tylko na regał, a między regałami L3, a taki schemat ma jeszcze więcej ograniczeń.
- Można wpisać nazwę DNS w kodzie i rozwiązać ją przez /etc/hosts. Tak naprawdę rozwiązanie nie nastąpi. Zaleta schematu: brak ograniczeń typowych dla pierwszej metody, czyli można zorganizować nawet cross-DC. Ale wtedy pojawia się oczywiste pytanie, jak szybko za pomocą Puppet-Ansible wprowadzimy zmianę w /etc/hosts.
- Można nieco zmodyfikować drugi sposób: na wszystkich serwerach webowych zainstalować pamięć podręczną DNS, przez którą kod będzie łączył się z master bazą. Można ustawić TTL 60 dla tego wpisu w DNS. Wydaje się, że przy poprawnej implementacji sposób jest dobry.
- Schemat z odkrywaniem usług, zakładający zastosowanie Consul i etcd.
- Ciekawa opcja z . Trzeba cały ruch do MySQL skierować przez ProxySQL, który sam potrafi określić, kto obecnie jest masterem. Swoją drogą, o jednym z zastosowań tego produktu można przeczytać w moim .
Autor Orkiestratora, pracując w Githubie, najpierw wdrożył pierwszy schemat z VIP, a potem przerobił go na schemat z konsolą.
Typowy schemat infrastruktury:
Od razu opiszę oczywiste sytuacje, które należy uwzględnić:
- VIP-adres nie powinien być wpisany w konfiguracji na żadnym z serwerów. Wyobraźmy sobie sytuację: master się zrestartował, a podczas jego uruchamiania Orchestrator przeszedł w tryb failover i uczynił jednym z masterów jeden z slave'ów; następnie uruchomił się stary master, a teraz VIP jest na dwóch maszynach. To jest źle.
- Dla Orchestratora będzie trzeba napisać skrypt do komunikacji ze starym masterem i nowym masterem. Na starym należy wykonać ifdown, a na nowym masterze — ifup vip. Dobrze byłoby również w tym skrypcie uwzględnić, że w przypadku failover port na switchu starego mastera po prostu zostaje wyłączony, aby uniknąć wszelkiego split-brain.
- Po tym, jak Orchestrator wywołał twój skrypt, aby najpierw wyłączyć VIP i/lub wyłączyć port na switchu, a następnie na nowym masterze wywołał skrypt włączający VIP, nie zapomnij poleceniem arping powiadomić wszystkich, że nowy VIP jest teraz tutaj.
- Na wszystkich slave'ach powinno być read_only=1, a gdy tylko wypromujesz slave'a do roli mastera, ma on mieć read_only=0.
- Nie zapominaj, że masterem może stać się każdy slave, którego wybraliśmy do tego (Orchestrator ma cały mechanizm preferencji, który slave powinien być rozważany jako kandydat na nowego mastera w pierwszej kolejności, który w drugiej, a który slave w ogóle nie powinien być wybrany na mastera). Jeśli slave stanie się masterem, to pozostanie na nim obciążenie slave'a, a dodatkowo przybędzie obciążenie mastera — to trzeba uwzględnić.
Dlaczego więc koniecznie potrzebujesz Orchestratora, jeśli go nie masz?
- Orchestrator ma bardzo wygodny interfejs graficzny, który pokazuje całą topologię (zobacz zrzut ekranu poniżej).
- Orchestrator może śledzić, które slave'y się spóźniają, a gdzie replikacja w ogóle się załamała (mamy do Orchestratora podłączone skrypty do wysyłania SMS-ów).
- Orchestrator informuje, na których slave'ach występuje błąd GTID errant.
Interfejs Orchestratora:
Czym jest GTID errant?
Są dwa podstawowe wymagania do działania Orchestratora:
- Należy, aby na wszystkich maszynach w klastrze MySQL był włączony pseudo GTID, mamy włączony GTID.
- Należy, aby wszędzie był jeden typ binlogów, może to być statement. Mieliśmy taką konfigurację, w której na masterze i na większości slave'ów był Row, a na dwóch historycznie pozostał tryb Mixed. W rezultacie te slave'y Orchestrator po prostu nie chciał podłączyć do nowego mastera.
Pamiętaj, że najważniejsza w produkcyjnym slave to jego zgodność z masterem! Jeśli zarówno na masterze, jak i na slavu włączony jest Global Transaction ID (GTID), możesz użyć funkcji gtid_subset, aby sprawdzić, czy na tych maszynach wykonano te same zapytania dotyczące zmian w danych. Więcej informacji na ten temat można przeczytać. .
W ten sposób Orchestrator informuje cię o błędzie GTID errant, że na slave znajdują się transakcje, których nie ma na masterze. Dlaczego tak się dzieje?
- Na slave nie jest włączony read_only=1, ktoś się połączył i wykonał zapytanie dotyczące zmiany danych.
- Na slave nie jest włączony super_read_only=1, więc administrator, myląc serwer, wszedł i wykonał tam zapytanie.
- Jeśli uwzględniłeś oba poprzednie punkty, istnieje jeszcze jeden trik: w MySQL zapytanie o flush dzienników binarnych również trafia do dziennika binarnego, dlatego przy pierwszym flush na masterze i na wszystkich slave'ach pojawi się GTID errant. Jak tego uniknąć? W wersji perona-5.7.25-28 pojawiła się opcja binlog_skip_flush_commands=1, zabraniająca zapisywania flush w dziennikach. Na stronie mysql.com jest założony. .
Podsumowując to, co powiedziałem wcześniej. Jeśli na razie nie chcesz używać Orchestratora w trybie failover, ustaw go w trybie monitorowania. Wtedy zawsze będziesz mieć przed oczami mapę interakcji maszyn MySQL oraz wyraźne informacje o tym, jaki typ replikacji jest na każdej maszynie, czy slave'y są opóźnione i, co najważniejsze, w jakim stopniu są zgodne z masterem!
Oczywiste pytanie: „Jak powinien działać Orchestrator?”. Powinien wybrać nowego mastera spośród obecnych slave'ów, a następnie przełączyć do niego wszystkie slave'y (dla tego potrzebny jest GTID; jeśli używa się starego mechanizmu z binlog_name i binlog_pos, to przełączenie slave'a z obecnego mastera na nowy jest po prostu niemożliwe!). Zanim pojawił się Orchestrator, musiałem kiedyś robić to wszystko ręcznie. Stary master zawiesił się z powodu wadliwego kontrolera Adaptec, miał około 10 slave'ów. Musiałem przenieść VIP z mastera na jeden z slave'ów i przełączyć wszystkie pozostałe slave'y na niego. Ile konsol musiałem otworzyć, ile jednoczesnych poleceń wprowadzić… Musiałem czekać do 3 nad ranem, zdjąć obciążenie ze wszystkich slave'ów, z wyjątkiem dwóch, uczynić pierwszą maszynę mistrzem z dwóch, natychmiast połączyć ją z drugą maszyną, a następnie połączyć wszystkie pozostałe slave'y z nowym masterem i przywrócić obciążenie. W skrócie, koszmar…
Jak działa Orchestrator, kiedy przechodzi w tryb failover? Najłatwiej to pokazać na przykładzie sytuacji, gdy chcemy, aby mocniejsza i bardziej nowoczesna maszyna stała się masterem w porównaniu do aktualnej.
Na rysunku przedstawiona jest środkowa część procesu. Co zostało już zrobione do tego momentu? Powiedzieliśmy, że chcemy, aby jakiś slave był nowym masterem, Orchestrator zaczął po prostu przełączać do niego wszystkie inne slaves, przy czym nowy master pełni rolę maszyny tranzytowej. W tej schemacie błędy nie występują, wszystkie slaves działają, Orchestrator zdejmuje VIP z starego mastera, przenosi go na nowy, ustawia read_only=0 i zapomina o starym masterze. Wszystko! Czas przestoju naszego serwisu to czas przeniesienia VIP, to 2-3 sekundy.
Na dzisiaj to wszystko, dziękuję wszystkim. Wkrótce pojawi się drugi artykuł o Orchestratorze. W znanym radzieckim filmie „Garaż” jeden z bohaterów powiedział „Nie poszedłbym z nim na zwiad!” Cóż, Orchestrator, z tobą poszedłbym na zwiad!
Źródło: habr.com
