W naszych poprzednich blogach omawialiśmy MHA jako narzędzie do przełączania awaryjnego używane w konfiguracjach typu master-slave MySQL. W zeszłym miesiącu pisaliśmy również na blogu o tym, jak radzić sobie z MHA w przypadku awarii. Dzisiaj przyjrzymy się najczęstszym problemom, które administratorzy baz danych zwykle napotykają w przypadku MHA, oraz sposobom ich naprawy.
Krótkie wprowadzenie do MHA (Master High Availability)
Skrót MHA od (Master High Availability) jest nadal aktualny i szeroko stosowany, zwłaszcza w konfiguracjach master-slave opartych na replikacji innej niż GTID. MHA dobrze radzi sobie z przełączaniem awaryjnym lub przełącznikiem głównym, ale wiąże się z pewnymi pułapkami i ograniczeniami. Gdy MHA wykona przełączanie awaryjne nadrzędne i podrzędne, może automatycznie zakończyć operację przełączania awaryjnego bazy danych w ciągu ~30 sekund, co jest dopuszczalne w środowisku produkcyjnym. MHA może zapewnić spójność danych. Wszystko to przy zerowej degradacji wydajności i nie wymaga dodatkowych dostosowań ani zmian w istniejących wdrożeniach lub konfiguracji. Poza tym MHA jest oparte na Perlu i jest rozwiązaniem HA o otwartym kodzie źródłowym - więc stosunkowo łatwo jest tworzyć pomocniki lub rozszerzać narzędzie zgodnie z pożądaną konfiguracją. Sprawdź tę prezentację, aby uzyskać więcej informacji.
Oprogramowanie MHA składa się z dwóch komponentów, należy zainstalować jeden z następujących pakietów zgodnie z jego rolą topologii:
Węzeł menedżera MHA =Menedżer MHA (menedżer)/Węzeł MHA (węzeł danych)
Węzły Master/Slave =Węzeł MHA (węzeł danych)
MHA Manager to oprogramowanie, które zarządza przełączaniem awaryjnym (automatycznym lub ręcznym), podejmuje decyzje o tym, kiedy i gdzie przełączać awaryjnie, a także zarządza odzyskiwaniem urządzeń podrzędnych podczas promocji kandydującego mastera w celu zastosowania dzienników przekaźników różnicowych. W przypadku śmierci głównej bazy danych, Menedżer MHA będzie koordynował współpracę z agentem MHA Node, ponieważ stosuje dzienniki przekaźników różnicowych do urządzeń podrzędnych, które nie mają najnowszych zdarzeń dziennika binarnego z urządzenia głównego. Oprogramowanie MHA Node to lokalny agent, który będzie monitorować twoją instancję MySQL i umożliwia menedżerowi MHA kopiowanie dzienników przekaźników z urządzeń podrzędnych. Typowy scenariusz jest taki, że gdy główny kandydujący do przełączania awaryjnego jest aktualnie opóźniony i MHA wykryje, że nie ma najnowszych dzienników przekazywania. W związku z tym będzie czekał na swój mandat od MHA Managera, szukając najnowszego urządzenia podrzędnego, które zawiera zdarzenia binlogu, kopiuje brakujące zdarzenia z urządzenia podrzędnego za pomocą scp i stosuje je do siebie.
Należy jednak pamiętać, że MHA nie jest obecnie aktywnie utrzymywany, ale sama aktualna wersja jest stabilna i może być „wystarczająco dobra” do produkcji. Nadal możesz echo swojego głosu przez github, aby rozwiązać niektóre problemy lub dostarczyć poprawki do oprogramowania.
Najczęstsze problemy
Przyjrzyjmy się teraz najczęstszym problemom, które administrator DBA napotka podczas korzystania z MHA.
Slave jest opóźniony, nieinteraktywne/automatyczne przełączanie awaryjne nie powiodło się!
Jest to typowy problem powodujący przerwanie lub niepowodzenie automatycznego przełączania awaryjnego. To może wydawać się proste, ale nie wskazuje tylko na jeden konkretny problem. Slave lag może mieć różne przyczyny:
- Problemy z dyskiem na kandydującym masterze powodujące, że jest on powiązany z we/wy dysku w celu przetwarzania odczytu i zapisu. Może również prowadzić do uszkodzenia danych, jeśli nie zostanie złagodzone.
- Replikowane są złe zapytania, zwłaszcza tabele, które nie mają kluczy podstawowych ani indeksów klastrowych.
- duże obciążenie serwera.
- Zimny serwer i serwer jeszcze się nie rozgrzał
- Za mało zasobów serwera. Możliwe, że twój slave może mieć zbyt mało pamięci lub zasobów serwera podczas replikowania intensywnych zapisów lub odczytów.
Można je złagodzić z wyprzedzeniem, jeśli masz odpowiedni monitoring swojej bazy danych. Jednym z przykładów w odniesieniu do opóźnień podrzędnych w MHA jest mała ilość pamięci podczas zrzucania dużego binarnego pliku dziennika. Jako przykład poniżej, master został oznaczony jako martwy i musi wykonać nieinteraktywne/automatyczne przełączanie awaryjne. Jednak ponieważ kandydat na master był opóźniony i musi zastosować logi, które nie zostały jeszcze wykonane przez wątki replikacji, MHA zlokalizuje najbardziej aktualne lub najnowsze urządzenie podrzędne, próbując odzyskać podrzędny względem najstarszego te. Dlatego, jak widać poniżej, podczas odzyskiwania urządzenia podrzędnego pamięć spadła za mało:
[email protected]:~$ masterha_manager --conf=/etc/app1.cnf --remove_dead_master_conf --ignore_last_failover
Mon May 6 08:43:46 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon May 6 08:43:46 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Mon May 6 08:43:46 2019 - [info] Reading server configuration from /etc/app1.cnf..
…
Mon May 6 08:43:57 2019 - [info] Checking master reachability via MySQL(double check)...
Mon May 6 08:43:57 2019 - [info] ok.
Mon May 6 08:43:57 2019 - [info] Alive Servers:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306)
Mon May 6 08:43:57 2019 - [info] Alive Slaves:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Not candidate for the new Master (no_master is set)
Mon May 6 08:43:57 2019 - [info] Starting Non-GTID based failover.
….
Mon May 6 08:43:59 2019 - [info] * Phase 3.4: New Master Diff Log Generation Phase..
Mon May 6 08:43:59 2019 - [info]
Mon May 6 08:43:59 2019 - [info] Server 192.168.10.50 received relay logs up to: binlog.000004:106167341
Mon May 6 08:43:59 2019 - [info] Need to get diffs from the latest slave(192.168.10.70) up to: binlog.000005:240412 (using the latest slave's relay logs)
Mon May 6 08:43:59 2019 - [info] Connecting to the latest slave host 192.168.10.70, generating diff relay log files..
Mon May 6 08:43:59 2019 - [info] Executing command: apply_diff_relay_logs --command=generate_and_send --scp_user=vagrant --scp_host=192.168.10.50 --latest_mlf=binlog.000005 --latest_rmlp=240412 --target_mlf=binlog.000004 --target_rmlp=106167341 --server_id=3 --diff_file_readtolatest=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog --workdir=/tmp --timestamp=20190506084355 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --relay_dir=/var/lib/mysql --current_relay_log=relay-bin.000007
Mon May 6 08:44:00 2019 - [info]
Relay log found at /var/lib/mysql, up to relay-bin.000007
Fast relay log position search failed. Reading relay logs to find..
Reading relay-bin.000007
Binlog Checksum enabled
Master Version is 5.7.23-23-log
Binlog Checksum enabled
…
…...
Target relay log file/position found. start_file:relay-bin.000004, start_pos:106167468.
Concat binary/relay logs from relay-bin.000004 pos 106167468 to relay-bin.000007 EOF into /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog ..
Binlog Checksum enabled
Binlog Checksum enabled
Dumping binlog format description event, from position 0 to 361.. ok.
Dumping effective binlog data from /var/lib/mysql/relay-bin.000004 position 106167468 to tail(1074342689)..Out of memory!
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1090] Generating diff files failed with return code 1:0.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 08:44:00 2019 - [info]
----- Failover Report -----
app1: MySQL Master failover 192.168.10.60(192.168.10.60:3306)
Master 192.168.10.60(192.168.10.60:3306) is down!
Check MHA Manager logs at testnode20 for details.
Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.10.60(192.168.10.60:3306)
The latest slave 192.168.10.70(192.168.10.70:3306) has all relay logs for recovery.
Selected 192.168.10.50(192.168.10.50:3306) as a new master.
Recovering master server failed.
Got Error so couldn't continue failover from here.W ten sposób przełączanie awaryjne nie powiodło się. Powyższy przykład pokazuje, że węzeł 192.168.10.70 zawiera najbardziej zaktualizowane dzienniki przekaźnika. Jednak w tym przykładowym scenariuszu węzeł 192.168.10.70 jest ustawiony jako no_master, ponieważ ma mało pamięci. Próba odzyskania urządzenia podrzędnego 192.168.10.50 kończy się niepowodzeniem!
Poprawki/Rozdzielczość:
Ten scenariusz ilustruje coś bardzo ważnego. Konieczne jest skonfigurowanie zaawansowanego środowiska monitorowania! Na przykład można uruchomić skrypt działający w tle lub demon, który monitoruje kondycję replikacji. Możesz dodać jako wpis poprzez zadanie cron. Na przykład dodaj wpis za pomocą wbudowanego skryptu masterha_check_repl :
/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnflub utwórz skrypt w tle, który wywołuje ten skrypt i uruchamia go w odstępach czasu. Możesz użyć opcji report_script, aby ustawić powiadomienie o alercie w przypadku, gdy nie jest ono zgodne z twoimi wymaganiami, np. urządzenie podrzędne jest opóźnione przez około 100 sekund podczas wysokiego obciążenia szczytowego. Możesz także użyć platform monitorujących, takich jak ClusterControl, skonfigurować je tak, aby wysyłać Ci powiadomienia na podstawie metryk, które chcesz monitorować.
Oprócz tego należy pamiętać, że w przykładowym scenariuszu przełączenie awaryjne nie powiodło się z powodu błędu braku pamięci. Możesz rozważyć upewnienie się, że wszystkie węzły mają wystarczającą ilość pamięci i odpowiedni rozmiar dzienników binarnych, ponieważ będą musieli zrzucić dziennik binarny w fazie odzyskiwania urządzenia podrzędnego.
Niespójne urządzenie podrzędne, zastosowanie różnic nie powiodło się!
W odniesieniu do opóźnienia podrzędnego, ponieważ MHA spróbuje zsynchronizować dzienniki przekaźnika z kandydatem na mastera, upewnij się, że Twoje dane są zsynchronizowane. Podaj przykład poniżej:
...
Concat succeeded.
Generating diff relay log succeeded. Saved at /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog .
scp testnode7:/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog to [email protected](22) succeeded.
Mon May 6 05:43:53 2019 - [info] Generating diff files succeeded.
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] * Phase 3.5: Master Log Apply Phase..
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.
Mon May 6 05:43:53 2019 - [info] Starting recovery on 192.168.10.50(192.168.10.50:3306)..
Mon May 6 05:43:53 2019 - [info] Generating diffs succeeded.
Mon May 6 05:43:53 2019 - [info] Waiting until all relay logs are applied.
Mon May 6 05:43:53 2019 - [info] done.
Mon May 6 05:43:53 2019 - [info] Getting slave status..
Mon May 6 05:43:53 2019 - [info] This slave(192.168.10.50)'s Exec_Master_Log_Pos equals to Read_Master_Log_Pos(binlog.000010:161813650). No need to recover from Exec_Master_Log_Pos.
Mon May 6 05:43:53 2019 - [info] Connecting to the target slave host 192.168.10.50, running recover script..
Mon May 6 05:43:53 2019 - [info] Executing command: apply_diff_relay_logs --command=apply --slave_user='cmon' --slave_host=192.168.10.50 --slave_ip=192.168.10.50 --slave_port=3306 --apply_files=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog --workdir=/tmp --target_version=5.7.23-23-log --timestamp=20190506054328 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --slave_pass=xxx
Mon May 6 05:43:53 2019 - [info]
MySQL client version is 5.7.23. Using --binary-mode.
Applying differential binary/relay log files /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog on 192.168.10.50:3306. This may take long time...
mysqlbinlog: Error writing file 'UNOPENED' (Errcode: 32 - Broken pipe)
FATAL: applying log files failed with rc 1:0!
Error logs from testnode5:/tmp/relay_log_apply_for_192.168.10.50_3306_20190506054328_err.log (the last 200 lines)..
ICwgMmM5MmEwZjkzY2M5MTU3YzAxM2NkZTk4ZGQ1ODM0NDEgLCAyYzkyYTBmOTNjYzkxNTdjMDEz
….
…..
M2QxMzc5OWE1NTExOTggLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDc3NDIzNCAsIDJjOTJh
MGY5M2NmYjVhN2EwMTNkMTY3OGI0N2Q0MjMERROR 1062 (23000) at line 72: Duplicate entry '12583545' for key 'PRIMARY'
5ICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNjc4YjQ4
OTQyM2QgLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDkxNDI1MSAsIDJjOTJhMGY5M2NmYjVh
N2EwMTNkMTczN2MzOWM3MDEzICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNzM3YzNhMzcwMTUgLCAy
…
--------------
Bye
at /usr/local/bin/apply_diff_relay_logs line 554.
eval {...} called at /usr/local/bin/apply_diff_relay_logs line 514
main::main() called at /usr/local/bin/apply_diff_relay_logs line 121
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1399] Applying diffs failed with return code 22:0.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 05:43:53 2019 - [info]Niespójny klaster jest naprawdę zły, zwłaszcza gdy włączone jest automatyczne przełączanie awaryjne. W takim przypadku przełączanie awaryjne nie może być kontynuowane, ponieważ wykrywa zduplikowany wpis dla klucza podstawowego „12583545 '.
Poprawki/Rozdzielczość:
Jest wiele rzeczy, które możesz tutaj zrobić, aby uniknąć niespójnego stanu klastra.
- Włącz bezstratną replikację półsynchroniczną. Sprawdź ten zewnętrzny blog, który jest dobrym sposobem, aby dowiedzieć się, dlaczego warto rozważyć użycie półsynchronizacji w standardowej konfiguracji replikacji MySQL.
- Stale generuj sumę kontrolną w klastrze master-slave. Możesz użyć sumy kontrolnej pt-table-check i uruchamiać ją raz w tygodniu lub miesiącu, w zależności od tego, jak często aktualizowana jest Twoja tabela. Zwróć uwagę, że suma pt-table-checksum może zwiększyć obciążenie Twojej bazy danych.
- Użyj replikacji opartej na GTID. Chociaż nie wpłynie to na sam problem. Jednak replikacja oparta na GTID pomaga w określeniu błędnych transakcji, zwłaszcza transakcji, które zostały uruchomione bezpośrednio na urządzeniu podrzędnym. Kolejną zaletą tego rozwiązania jest łatwiejsze zarządzanie replikacją opartą na GTID, gdy trzeba przełączyć hosta głównego podczas replikacji.
Awaria sprzętowa urządzenia głównego, ale niewolnicy jeszcze go nie dogonili
Jednym z wielu powodów, dla których warto zainwestować w automatyczne przełączanie awaryjne, jest awaria sprzętu w urządzeniu głównym. W przypadku niektórych konfiguracji bardziej idealne może być automatyczne przełączanie awaryjne tylko wtedy, gdy urządzenie główne napotka awarię sprzętu. Typowym podejściem jest powiadomienie przez wysłanie alarmu – co może oznaczać, że obudzenie w środku nocy osoby dyżurującej na wezwanie pozwala jej zdecydować, co robić. Tego typu podejście odbywa się na Github, a nawet na Facebooku. Awaria sprzętu, zwłaszcza jeśli ma to wpływ na wolumin, na którym znajdują się logi binarne i katalog danych, może zakłócić przełączanie awaryjne, zwłaszcza jeśli dzienniki binarne są przechowywane na uszkodzonym dysku. Zgodnie z projektem, MHA spróbuje zapisać logi binarne z uszkodzonego mastera, ale nie będzie to możliwe w przypadku awarii dysku. Jednym z możliwych scenariuszy jest to, że serwer nie jest osiągalny przez SSH. MHA nie może zapisywać dzienników binarnych i musi wykonać przełączanie awaryjne bez stosowania zdarzeń dziennika binarnego, które istnieją tylko w uszkodzonym systemie głównym. Spowoduje to utratę najnowszych danych, zwłaszcza jeśli żaden slave nie dogonił mastera.
Poprawki/Rozdzielczość
Jako jeden z przypadków użycia przez MHA, zaleca się użycie replikacji półsynchronicznej, ponieważ znacznie zmniejsza to ryzyko takiej utraty danych. Ważne jest, aby pamiętać, że wszelkie zapisy przesyłane do urządzenia nadrzędnego muszą zapewniać, że urządzenia podrzędne otrzymały najnowsze zdarzenia dziennika binarnego przed synchronizacją z dyskiem. MHA może zastosować zdarzenia do wszystkich innych niewolników, aby mogli być ze sobą spójni.
Ponadto lepiej jest również uruchomić strumień kopii zapasowej dzienników binarnych w celu odzyskania po awarii w przypadku awarii głównego woluminu dysku. Jeśli serwer jest nadal dostępny przez SSH, wskazanie ścieżki dziennika binarnego na ścieżkę kopii zapasowej dziennika binarnego może nadal działać, więc przełączanie awaryjne i odzyskiwanie urządzeń podrzędnych może nadal iść do przodu. W ten sposób możesz uniknąć utraty danych.
Przełączanie awaryjne VIP (wirtualne IP) powodujące rozszczepienie mózgu
MHA domyślnie nie obsługuje żadnego zarządzania VIP. Jednak łatwo jest włączyć to do konfiguracji MHA i przypisać haki zgodnie z tym, co MHA ma zrobić podczas przełączania awaryjnego. Możesz skonfigurować własny skrypt i podłączyć go do parametrów master_ip_failover_script lub master_ip_online_change_script. Istnieją również przykładowe skrypty, które znajdują się w katalogu
Podczas automatycznego przełączania awaryjnego, po wywołaniu i wykonaniu skryptu z zarządzaniem VIP, MHA wykona następujące czynności:sprawdzi status, usunie (lub zatrzyma) stary VIP, a następnie ponownie przypisze nowy VIP do nowego mastera. Typowym przykładem rozszczepienia mózgu jest zidentyfikowanie urządzenia nadrzędnego jako martwego z powodu problemu z siecią, ale w rzeczywistości węzły podrzędne nadal są w stanie połączyć się z urządzeniem nadrzędnym. Jest to fałszywy alarm i często prowadzi do niespójności danych w bazach danych w konfiguracji. Przychodzące połączenia klientów korzystające z VIP będą wysyłane do nowego mastera. Z drugiej strony mogą istnieć połączenia lokalne działające na starym masterze, który powinien być martwy. Połączenia lokalne mogą wykorzystywać gniazdo unix lub localhost do zmniejszania przeskoków w sieci. Może to spowodować, że dane będą dryfować w stosunku do nowego urządzenia nadrzędnego i pozostałych jego urządzeń podrzędnych, ponieważ dane ze starego urządzenia nadrzędnego nie zostaną zreplikowane do urządzeń podrzędnych.
Poprawki/Rozdzielczość:
Jak wspomniano wcześniej, niektórzy mogą preferować unikanie automatycznego przełączania awaryjnego, chyba że testy wykazały, że urządzenie główne jest całkowicie wyłączone (jak awaria sprzętu), tj. nawet węzły podrzędne nie są w stanie się do niego dostać. Pomysł polega na tym, że fałszywy alarm może być spowodowany usterką sieciową między kontrolerem węzła MHA a urządzeniem głównym, więc w tym przypadku człowiek może być lepiej przystosowany do podjęcia decyzji o przełączeniu awaryjnym.
W przypadku fałszywych alarmów MHA posiada parametr o nazwie second_check_script. Umieszczoną tutaj wartością mogą być Twoje niestandardowe skrypty lub możesz użyć wbudowanego skryptu /usr/local/bin/masterha_secondary_check który jest dostarczany wraz z pakietem MHA Manager. Dodaje to dodatkowe kontrole, które w rzeczywistości jest zalecanym podejściem do unikania fałszywych alarmów. W poniższym przykładzie z mojej własnej konfiguracji używam wbudowanego skryptu masterha_secondary_check :
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.10.50 --user=root --master_host=testnode6 --master_ip=192.168.10.60 --master_port=3306W powyższym przykładzie MHA Manager wykona pętlę opartą na liście węzłów podrzędnych (określonych przez argument -s), która sprawdzi połączenie z hostem MySQL master (192.168.10.60). Zwróć uwagę, że te węzły podrzędne w przykładzie mogą być zewnętrznymi węzłami zdalnymi, które mogą nawiązać połączenie z węzłami bazy danych w klastrze. Jest to zalecane podejście, szczególnie w przypadku tych konfiguracji, w których Menedżer MHA działa w innym centrum danych lub innej sieci niż węzły bazy danych. Poniższa sekwencja ilustruje przebieg kontroli:
- Z hosta MHA -> sprawdź połączenie TCP z pierwszym węzłem podrzędnym (IP:192.168.10.50). Nazwijmy to jako Połączenie A. Następnie z węzła podrzędnego sprawdza połączenie TCP z węzłem głównym (192.168.10.60). Nazwijmy to połączenie B.
Jeśli „Połączenie A” powiodło się, ale „Połączenie B” nie powiodło się na obu trasach, masterha_secondary_check skrypt kończy działanie z kodem powrotu 0, a Menedżer MHA decyduje, że główny MySQL jest naprawdę martwy i rozpocznie przełączanie awaryjne. Jeśli „Połączenie A” nie powiodło się, masterha_secondary_check kończy działanie z kodem powrotu 2, a Menedżer MHA domyśla się, że wystąpił problem z siecią i nie uruchamia przełączania awaryjnego. Jeśli „Połączenie B” powiodło się, masterha_secondary_check kończy działanie z kodem powrotu 3, a Menedżer MHA rozumie, że serwer główny MySQL działa i nie rozpoczyna przełączania awaryjnego.
Przykład reakcji podczas przełączania awaryjnego na podstawie dziennika,
Tue May 7 05:31:57 2019 - [info] OK.
Tue May 7 05:31:57 2019 - [warning] shutdown_script is not defined.
Tue May 7 05:31:57 2019 - [info] Set master ping interval 1 seconds.
Tue May 7 05:31:57 2019 - [info] Set secondary check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306
Tue May 7 05:31:57 2019 - [info] Starting ping health check on 192.168.10.60(192.168.10.60:3306)..
Tue May 7 05:31:58 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:58 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:31:58 2019 - [info] Executing SSH check script: exit 0
Tue May 7 05:31:58 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Master is reachable from 192.168.10.50!
Tue May 7 05:31:58 2019 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.
Tue May 7 05:31:59 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:59 2019 - [warning] Connection failed 2 time(s)..
Tue May 7 05:32:00 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:00 2019 - [warning] Connection failed 3 time(s)..
Tue May 7 05:32:01 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:01 2019 - [warning] Connection failed 4 time(s)..
Tue May 7 05:32:03 2019 - [warning] HealthCheck: Got timeout on checking SSH connection to 192.168.10.60! at /usr/local/share/perl/5.26.1/MHA/HealthCheck.pm line 343.
Tue May 7 05:32:03 2019 - [warning] Secondary network check script returned errors. Failover should not start so checking server status again. Check network settings for details.
Tue May 7 05:32:04 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:04 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:32:04 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Tue May 7 05:32:04 2019 - [info] Executing SSH check script: exit 0Kolejną rzeczą do dodania jest przypisanie wartości do parametru shutdown_script. Ten skrypt jest szczególnie przydatny, jeśli musisz zaimplementować odpowiednie ogrodzenie STONITH lub węzły, aby nie powstało z martwych. Pozwala to uniknąć niespójności danych.
Na koniec upewnij się, że Menedżer MHA znajduje się w tej samej sieci lokalnej, co węzły klastra, ponieważ zmniejsza to możliwość awarii sieci, zwłaszcza połączenia między Menedżerem MHA a węzłami bazy danych.
Unikanie SPOF w MHA
MHA może ulec awarii z różnych powodów i niestety nie ma wbudowanej funkcji, która by to naprawić, tj. Wysoka dostępność dla MHA. Jednak, jak omówiliśmy w naszym poprzednim blogu „Master High Availability Manager (MHA) uległ awarii! Co mam teraz zrobić?”, istnieje sposób na uniknięcie SPOF dla MHA.
Poprawki/Rozdzielczość:
Pacemaker można wykorzystać do tworzenia węzłów aktywnych/w trybie gotowości obsługiwanych przez menedżera zasobów klastra (crm). Alternatywnie można utworzyć skrypt sprawdzający kondycję węzła menedżera MHA. Na przykład możesz udostępnić węzeł gotowości, który aktywnie sprawdza węzeł menedżera MHA, wysyłając ssh, aby uruchomić wbudowany skrypt masterha_check_status tak jak poniżej:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).następnie wykonaj ogrodzenie węzła, jeśli ten kontroler jest zepsuty. Możesz także rozszerzyć narzędzie MHA o skrypt pomocniczy, który działa za pośrednictwem zadania cron i monitorować proces systemowy skryptu masterha_manager i ponownie go odradzać, jeśli proces jest martwy.
Utrata danych podczas przełączania awaryjnego
MHA opiera się na tradycyjnej replikacji asynchronicznej. Chociaż obsługuje półsynchronizację, nadal półsynchronizacja opiera się na replikacji asynchronicznej. W tego typu środowisku utrata danych może nastąpić po przełączeniu awaryjnym. Jeśli Twoja baza danych nie jest prawidłowo skonfigurowana i wykorzystuje staromodne podejście do replikacji, może to być uciążliwe, szczególnie w przypadku spójności danych i utraconych transakcji.
Inną ważną rzeczą, na którą należy zwrócić uwagę w przypadku utraty danych za pomocą MHA, jest sytuacja, w której GTID jest używany bez włączonej półsynchronizacji. MHA z GTID nie połączy się przez ssh z masterem, ale najpierw spróbuje zsynchronizować logi binarne w celu odzyskania węzła z urządzeniami podrzędnymi. Może to potencjalnie prowadzić do większej utraty danych niż w przypadku MHA bez GTID z niewłączoną półsynchronizacją.
Poprawki/Rozdzielczość
Wykonując automatyczne przełączanie awaryjne, zbuduj listę scenariuszy, gdy oczekujesz, że MHA przejdzie w tryb awaryjny. Ponieważ MHA zajmuje się replikacją typu master-slave, nasze porady dotyczące unikania utraty danych są następujące:
- Włącz bezstratną półsynchronizowaną replikację (istnieje w wersji MySQL 5.7)
- Użyj replikacji opartej na GTID. Oczywiście możesz użyć tradycyjnej replikacji, używając współrzędnych x i y z binloga. Jednak sprawia to, że rzeczy są trudniejsze i bardziej czasochłonne, gdy trzeba zlokalizować określony wpis w dzienniku binarnym, który nie został zastosowany na urządzeniu podrzędnym. Dlatego dzięki GTID w MySQL łatwiej jest wykryć błędne transakcje.
- Aby zapewnić zgodność replikacji MySQL master-slave z ACID, włącz następujące zmienne:sync_binlog =1, innodb_flush_log_at_trx_commit =1. Jest to kosztowne, ponieważ wymaga większej mocy obliczeniowej, gdy MySQL wywołuje funkcję fsync() podczas zatwierdzania, oraz wydajności może być związany z dyskiem w przypadku dużej liczby zapisów. Jednak korzystanie z macierzy RAID z podtrzymaniem bateryjnym pamięci podręcznej pozwala zaoszczędzić dyskowe operacje we/wy. Dodatkowo sam MySQL został ulepszony dzięki zatwierdzaniu grup logów binarnych, ale nadal korzystanie z pamięci podręcznej kopii zapasowej może zaoszczędzić niektóre synchronizacje dysków.
- Wykorzystaj replikację równoległą lub wielowątkową replikację podrzędną. Może to pomóc twoim niewolnikom stać się bardziej wydajnymi i uniknąć lagów niewolników w stosunku do pana. Nie chcesz, aby automatyczne przełączanie awaryjne nastąpiło, gdy master nie jest w ogóle osiągalny przez połączenie ssh lub tcp, lub jeśli napotka awarię dysku, a twoje slave'y pozostają w tyle. Może to prowadzić do utraty danych.
- Przeprowadzając przełączanie awaryjne w trybie online lub ręcznie, najlepiej wykonywać je poza okresami szczytu, aby uniknąć nieoczekiwanych wpadek, które mogą prowadzić do utraty danych. Lub aby uniknąć czasochłonnego wyszukiwania przeszukiwania dzienników binarnych podczas dużej aktywności.
MHA mówi, że aplikacja nie działa lub nie działa przełączanie awaryjne. Co powinienem zrobić?
Uruchamianie sprawdzeń za pomocą wbudowanego skryptu masterha_check_status sprawdzi, czy skrypt mastreha_manager jest uruchomiony. W przeciwnym razie pojawi się błąd taki jak poniżej:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf app1 is stopped(2:NOT_RUNNING).Jednak są pewne przypadki, w których możesz NIE URUCHAMIAĆ, nawet gdy masterha_manager biegnie. Może to być spowodowane uprawnieniem ustawionego użytkownika ssh_user, uruchomieniem masterha_manager z innym użytkownikiem systemu lub odmową uprawnień użytkownika ssh.
Poprawki/Rozdzielczość:
MHA użyje ssh_user zdefiniowane w konfiguracji, jeśli określono. W przeciwnym razie użyje bieżącego użytkownika systemu, którego używasz do wywoływania poleceń MHA. Podczas uruchamiania skryptu masterha_check_status na przykład musisz upewnić się, że masterha_manager działa z tym samym użytkownikiem, który jest określony w ssh_user w pliku konfiguracyjnym lub użytkownika, który będzie się komunikował z innymi węzłami bazy danych w klastrze. Musisz upewnić się, że ma on klucze SSH bez hasła i hasła, aby MHA nie miał żadnych problemów podczas nawiązywania połączenia z węzłami monitorowanymi przez MHA.
Pamiętaj, że potrzebujesz ssh_user aby mieć dostęp do:
- Może odczytywać logi binarne i przekaźnikowe węzłów MySQL monitorowanych przez MHA
- Musi mieć dostęp do dzienników monitorowania MHA. Sprawdź te parametry w MHA:master_binlog_dir, manager_workdir i manager_log
- Musi mieć dostęp do pliku konfiguracyjnego MHA. To też jest bardzo ważne. Podczas przełączania awaryjnego, po zakończeniu przełączania awaryjnego, spróbuje zaktualizować plik konfiguracyjny i usunąć wpis martwego wzorca. Jeśli plik konfiguracyjny nie zezwala na ssh_user lub użytkownika systemu operacyjnego, którego aktualnie używasz, nie zaktualizuje pliku konfiguracyjnego, co prowadzi do eskalacji problemu, jeśli awaria wystąpi ponownie.
Lagi kandydata na mistrza, jak wymusić i uniknąć nieudanego przełączenia awaryjnego
W odniesieniu do wiki MHA, domyślnie, jeśli slave za masterem ma więcej niż 100 MB dzienników przekaźnika (=musi zastosować więcej niż 100 MB dzienników przekaźnika), MHA nie wybiera slave'a jako nowego mastera, ponieważ odzyskiwanie zajmuje zbyt dużo czasu .
Poprawki/Rozdzielczość
W MHA można to obejść, ustawiając parametr check_repl_delay=0. Podczas przełączania awaryjnego MHA ignoruje opóźnienie replikacji podczas wybierania nowego wzorca i wykonuje brakujące transakcje. Ta opcja jest przydatna, gdy ustawisz Candida_master=1 na określonym hoście i chcesz się upewnić, że host może być nowym masterem.
Możesz także zintegrować się z pt-heartbeat, aby osiągnąć dokładność opóźnienia niewolnika (zobacz ten post i ten). Ale można to również złagodzić za pomocą replikacji równoległej lub urządzeń podrzędnych replikacji wielowątkowej, obecnych od MySQL 5.6 lub, w przypadku MariaDB 10 - twierdzącej, że ma dziesięciokrotną poprawę w replikacji równoległej i podrzędnych wielowątkowych. Może to pomóc twoim niewolnikom szybciej się replikować.
Hasła MHA są ujawniane
Zabezpieczanie lub szyfrowanie haseł nie jest czymś, co zajmuje się MHA. The parameters password or repl_password will be exposed via the configuration file. So your system administrator or security architect must evaluate the grants or privileges of this file as you don’t want to expose valuable database/SSH credentials.
Fixes/Resolution:
MHA has an optional parameter init_conf_load_script. This parameter can be used to have a custom script load your MHA config that will interface to e.g. a database, and retrieve the user/password credentials of your replication setup.
Of course, you can also limit the file attribute of the configuration and the user you are using, and limit the access to the specific Ops/DBA's/Engineers that will handle MHA.
MHA is Not My Choice, What Are the Alternatives for replication failover?
MHA is not a one-size-fits-all solution, it has its limitations and may not fit your desired setup. However, here's a list of variants that you can try.
- PRM
- Maxscale with Mariadb Monitor or MariaDB Replication Manager (MRM)
- Orchestrator
- ClusterControl
