Replikacja MySQL to bardzo popularny sposób budowania wysokodostępnych warstw baz danych. Jest bardzo dobrze znany, przetestowany i wytrzymały. Nie jest to jednak bez ograniczeń. Jednym z nich na pewno jest to, że wykorzystuje tylko jeden „punkt wejścia” - masz serwer dedykowany w topologii, master i jest to jedyny węzeł w klastrze, do którego możesz wydawać zapisy. Prowadzi to do poważnych konsekwencji - master jest pojedynczym punktem awarii, aw przypadku awarii, żaden zapis nie może zostać wykonany przez aplikację. Nie jest niespodzianką, że wiele pracy włożono w opracowanie narzędzi, które ograniczyłyby wpływ utraty mistrza. Jasne, są dyskusje, jak podejść do tematu, czy automatyczne przełączanie awaryjne jest lepsze niż ręczne, czy nie. Ostatecznie jest to decyzja biznesowa, ale jeśli zdecydujesz się podążać ścieżką automatyzacji, będziesz szukać narzędzi, które pomogą Ci to osiągnąć. Jednym z narzędzi, które wciąż jest bardzo popularne, jest MHA (Master High Availability). Chociaż być może nie jest już aktywnie utrzymywany, nadal jest w stabilnej formie, a jego ogromna popularność nadal sprawia, że jest podstawą wysoce dostępnych konfiguracji replikacji MySQL. Co by się jednak stało, gdyby samo MHA stało się niedostępne? Czy może stać się pojedynczym punktem awarii? Czy istnieje sposób, aby temu zapobiec? W tym poście na blogu przyjrzymy się niektórym scenariuszom.
Po pierwsze, jeśli planujesz używać MHA, upewnij się, że korzystasz z najnowszej wersji z repozytorium. Nie używaj wydań binarnych, ponieważ nie zawierają wszystkich poprawek. Instalacja jest dość prosta. MHA składa się z dwóch części, menedżera i węzła. Węzeł ma zostać wdrożony na serwerach bazy danych. Manager zostanie wdrożony na osobnym hoście wraz z węzłem. Tak więc serwery baz danych:węzeł, host zarządzania:menedżer i węzeł.
Kompilacja MHA jest dość łatwa. Przejdź do GitHub i sklonuj repozytoria.
https://github.com/yoshinorim/mha4mysql-menedżer
https://github.com/yoshinorim/mha4mysql-węzeł
W takim razie chodzi o:
perl Makefile.PL
make
make installByć może będziesz musiał zainstalować niektóre zależności perla, jeśli nie masz już zainstalowanych wszystkich wymaganych pakietów. W naszym przypadku na Ubuntu 16.04 musieliśmy zainstalować:
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"Po zainstalowaniu MHA musisz go skonfigurować. Nie będziemy tutaj wchodzić w żadne szczegóły, w Internecie jest wiele zasobów, które obejmują tę część. Przykładowa konfiguracja (zdecydowanie nieprodukcyjna) może wyglądać tak:
[email protected]:~# cat /etc/app1.cnf
[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1Następnym krokiem będzie sprawdzenie, czy wszystko działa i jak MHA widzi replikację:
[email protected]:~# masterha_check_repl --conf=/etc/app1.cnf
Tue Apr 9 08:17:04 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 08:17:04 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. Redundant argument in sprintf at /usr/local/share/perl/5.22.1/MHA/NodeUtil.pm line 195.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
Tue Apr 9 08:17:05 2019 - [info] Got exit code 1 (Not master dead).Cóż, rozbił się. Dzieje się tak, ponieważ MHA próbuje przeanalizować wersję MySQL i nie oczekuje w niej myślników. Na szczęście poprawkę można łatwo znaleźć:https://github.com/yoshinorim/mha4mysql-manager/issues/116.
Teraz mamy MHA gotowe do pracy.
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:00:00 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:00:00 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:00:01 2019 - [info] GTID failover mode = 1
Tue Apr 9 13:00:01 2019 - [info] Dead Servers:
Tue Apr 9 13:00:01 2019 - [info] Alive Servers:
Tue Apr 9 13:00:01 2019 - [info] node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306)
Tue Apr 9 13:00:01 2019 - [info] Alive Slaves:
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Not candidate for the new Master (no_master is set)
Tue Apr 9 13:00:01 2019 - [info] Current Alive Master: node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Checking slave configurations..
Tue Apr 9 13:00:01 2019 - [info] Checking replication filtering settings..
Tue Apr 9 13:00:01 2019 - [info] binlog_do_db= , binlog_ignore_db=
Tue Apr 9 13:00:01 2019 - [info] Replication filtering check ok.
Tue Apr 9 13:00:01 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Tue Apr 9 13:00:01 2019 - [info] Checking SSH publickey authentication settings on the current master..
Tue Apr 9 13:00:02 2019 - [info] HealthCheck: SSH to node1 is reachable.
Tue Apr 9 13:00:02 2019 - [info]
node1(10.0.0.141:3306) (current master)
+--node2(10.0.0.142:3306)
+--node3(10.0.0.143:3306)
Tue Apr 9 13:00:02 2019 - [warning] master_ip_failover_script is not defined.
Tue Apr 9 13:00:02 2019 - [warning] shutdown_script is not defined.
Tue Apr 9 13:00:02 2019 - [info] Set master ping interval 3 seconds.
Tue Apr 9 13:00:02 2019 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Tue Apr 9 13:00:02 2019 - [info] Starting ping health check on node1(10.0.0.141:3306)..
Tue Apr 9 13:00:02 2019 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..Jak widać, MHA monitoruje naszą topologię replikacji, sprawdzając, czy węzeł główny jest dostępny, czy nie. Rozważmy kilka scenariuszy.
Scenariusz 1 — awaria MHA
Załóżmy, że MHA nie jest dostępny. Jak to wpływa na środowisko? Oczywiście, ponieważ MHA jest odpowiedzialny za monitorowanie stanu mastera i wyzwalanie przełączania awaryjnego, nie nastąpi to, gdy MHA nie działa. Awaria Master nie zostanie wykryta, nie nastąpi przełączenie awaryjne. Problem polega na tym, że tak naprawdę nie można jednocześnie uruchomić wielu instancji MHA. Technicznie można to zrobić, chociaż MHA będzie narzekać na plik blokady:
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:05:38 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:05:38 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:05:38 2019 - [warning] /var/log/masterha/app1/app1.master_status.health already exists. You might have killed manager with SIGKILL(-9), may run two or more monitoring process for the same application, or use the same working directory. Check for details, and consider setting --workdir separately.Rozpocznie się jednak i spróbuje monitorować środowisko. Problem polega na tym, że obaj zaczynają wykonywać akcje na klastrze. Gorzej byłoby, gdyby zdecydowali się na użycie różnych urządzeń podrzędnych jako głównego kandydata, a przełączanie awaryjne zostanie wykonane w tym samym czasie (MHA używa pliku blokady, który zapobiega kolejnym przełączeniom awaryjnym, ale jeśli wszystko dzieje się w tym samym czasie, a stało się to w naszym testów, ten środek bezpieczeństwa nie jest wystarczający).
Niestety nie ma wbudowanego sposobu uruchamiania MHA w wysoce dostępny sposób. Najprostszym rozwiązaniem będzie napisanie skryptu, który sprawdzi, czy MHA działa, a jeśli nie, uruchom go. Taki skrypt musiałby zostać wykonany z crona lub napisany w formie demona, jeśli 1-minutowa ziarnistość crona nie wystarczy.
Scenariusz 2 – Utrata połączenia sieciowego węzła menedżera MHA z urządzeniem głównym
Bądźmy szczerzy, to naprawdę zła sytuacja. Gdy tylko MHA nie może połączyć się z masterem, podejmie próbę przełączenia awaryjnego. Jedynym wyjątkiem jest zdefiniowanie second_check_script i zweryfikowanie, że master żyje. To od użytkownika zależy, jakie dokładnie czynności powinien wykonać MHA, aby zweryfikować status mastera - wszystko zależy od środowiska i dokładnej konfiguracji. Innym bardzo ważnym skryptem do zdefiniowania jest master_ip_failover_script - jest on wykonywany po przełączeniu awaryjnym i powinien być używany m.in. w celu upewnienia się, że stary master się nie pojawi. Jeśli zdarzy ci się mieć dostęp do dodatkowych sposobów dotarcia i zatrzymania starego mistrza, to naprawdę świetnie. Mogą to być narzędzia do zdalnego zarządzania, takie jak Integrated Lights-out, może to być dostęp do zarządzalnych gniazdek (gdzie można po prostu wyłączyć serwer), może to być dostęp do CLI dostawcy chmury, co umożliwi zatrzymanie wirtualnej instancji . Niezwykle ważne jest zatrzymanie starego mistrza - w przeciwnym razie może się zdarzyć, że po zniknięciu problemu z siecią, w systemie pojawią się dwa możliwe do zapisu węzły, co jest idealnym rozwiązaniem dla rozszczepionego mózgu, czyli stanu, w którym dane rozbieżne między dwiema częściami tego samego klastra.
Jak widać, MHA całkiem dobrze radzi sobie z przełączaniem awaryjnym MySQL. To zdecydowanie wymaga starannej konfiguracji i będziesz musiał napisać zewnętrzne skrypty, które zostaną wykorzystane do zabicia starego mistrza i zapewnienia, że nie dojdzie do rozszczepienia mózgu. Powiedziawszy to, nadal zalecamy korzystanie z bardziej zaawansowanych narzędzi do zarządzania przełączaniem awaryjnym, takich jak Orchestrator lub ClusterControl, które mogą przeprowadzać bardziej zaawansowaną analizę stanu topologii replikacji (na przykład poprzez wykorzystanie urządzeń podrzędnych lub serwerów proxy do oceny dostępności urządzenia głównego) i które są i zostaną utrzymane w przyszłości. Jeśli chcesz dowiedzieć się, jak ClusterControl wykonuje przełączanie awaryjne, zapraszamy do przeczytania tego wpisu na blogu na temat procesu przełączania awaryjnego w ClusterControl. Możesz również dowiedzieć się, jak ClusterControl współdziała z ProxySQL, zapewniając płynne, przejrzyste przełączanie awaryjne Twojej aplikacji. Zawsze możesz przetestować ClusterControl, pobierając go za darmo.
