V našich předchozích blozích jsme diskutovali o MHA jako o nástroji pro překonání selhání používaného v nastaveních MySQL master-slave. Minulý měsíc jsme také blogovali o tom, jak zacházet s MHA, když havaroval. Dnes uvidíme hlavní problémy, se kterými se správci databází obvykle setkávají s MHA, a jak je můžete opravit.
Stručný úvod k MHA (Master High Availability)
Zkratka MHA (Master High Availability) je dnes stále relevantní a široce používaná, zejména v nastaveních master-slave založených na replikaci bez GTID. MHA funguje dobře při přepnutí při selhání nebo master-switch, ale přichází s určitými úskalími a omezeními. Jakmile MHA provede master failover a slave promotion, může automaticky dokončit svou databázovou failover operaci během ~30 sekund, což může být přijatelné v produkčním prostředí. MHA může zajistit konzistenci dat. To vše s nulovým snížením výkonu a nevyžaduje žádné další úpravy nebo změny vašich stávajících nasazení nebo nastavení. Kromě toho je MHA postaven na Perlu a jde o open-source HA řešení - je tedy relativně snadné vytvářet pomocníky nebo rozšiřovat nástroj podle požadovaného nastavení. Další informace naleznete v této prezentaci.
Software MHA se skládá ze dvou komponent, je třeba nainstalovat jeden z následujících balíčků v souladu s jeho topologickou rolí:
Uzel správce MHA =Manažer MHA (správce)/Uzel MHA (datový uzel)
Master/Slave uzly =MHA Node (datový uzel)
MHA Manager je software, který spravuje převzetí služeb při selhání (automatické nebo manuální), přijímá rozhodnutí o tom, kdy a kde se má provést převzetí služeb při selhání, a spravuje obnovu podřízeného zařízení během povýšení kandidáta master za použití protokolů rozdílového relé. Pokud hlavní databáze zemře, MHA Manager se zkoordinuje s agentem MHA Node, protože použije protokoly rozdílového přenosu na podřízené jednotky, které nemají nejnovější události binárního protokolu z hlavní. Software MHA Node je místní agent, který bude monitorovat vaši instanci MySQL a umožní správci MHA kopírovat protokoly přenosu z podřízených jednotek. Typickým scénářem je, že když se kandidát master na převzetí služeb při selhání aktuálně zpožďuje a MHA zjistí, že nemá nejnovější protokoly přenosu. Bude tedy čekat na svůj mandát od MHA Managera, zatímco bude hledat nejnovější slave zařízení, které obsahuje události binlog a kopíruje chybějící události z slave pomocí scp a aplikuje je na sebe.
Všimněte si však, že MHA není v současné době aktivně udržována, ale samotná aktuální verze je stabilní a může být „dost dobrá“ pro výrobu. Stále můžete ozvěnou svůj hlas prostřednictvím githubu vyřešit některé problémy nebo poskytnout opravy softwaru.
Nejčastější běžné problémy
Nyní se podívejme na nejčastější problémy, se kterými se DBA setká při používání MHA.
Slave se zpožďuje, neinteraktivní/automatické převzetí služeb při selhání se nezdařilo!
Toto je typický problém způsobující přerušení nebo selhání automatického převzetí služeb při selhání. Může to znít jednoduše, ale neukazuje to pouze na jeden konkrétní problém. Slave lag může mít různé důvody:
- Problémy s diskem na kandidátském hlavním serveru způsobující, že je diskový I/O vázán na zpracování čtení a zápisu. Pokud není zmírněno, může také vést k poškození dat.
- Špatné dotazy se replikují, zejména tabulky, které nemají žádné primární klíče nebo seskupené indexy.
- vysoké zatížení serveru.
- Studený server a server se ještě nezahřál
- Nedostatek prostředků serveru. Je možné, že váš slave může mít příliš málo paměti nebo prostředků serveru při replikaci vysoce intenzivních zápisů nebo čtení.
Ty mohou být předem zmírněny, pokud máte řádné monitorování databáze. Jedním příkladem s ohledem na zpoždění slave v MHA je nedostatek paměti při ukládání velkého binárního souboru protokolu. Jako příklad níže byl master označen jako mrtvý a musí provést neinteraktivní/automatické převzetí služeb při selhání. Protože se však kandidát master zpožďoval a musí použít protokoly, které ještě nebyly spuštěny replikačními vlákny, MHA vyhledá nejaktuálnější nebo nejnovější slave, protože se pokusí obnovit slave proti nejstaršímu jedničky. Proto, jak vidíte níže, při provádění obnovy slave došlo příliš málo paměti:
[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.Přepnutí při selhání se tedy nezdařilo. Tento příklad výše ukazuje, že uzel 192.168.10.70 obsahuje nejaktuálnější protokoly přenosu. V tomto příkladu scénáře je však uzel 192.168.10.70 nastaven jako no_master, protože má málo paměti. Když se pokusí obnovit slave 192.168.10.50, selže!
Opravy/Rozlišení:
Tento scénář ukazuje něco velmi důležitého. Musí být nastaveno pokročilé monitorovací prostředí! Můžete například spustit skript démona nebo pozadí, který monitoruje stav replikace. Můžete přidat jako záznam prostřednictvím úlohy cron. Například přidejte záznam pomocí vestavěného skriptu masterha_check_repl :
/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnfnebo vytvořte skript na pozadí, který tento skript vyvolá a spustí jej v intervalu. Pomocí volby report_script můžete nastavit upozornění na upozornění v případě, že nevyhovuje vašim požadavkům, např. slave se zpožďuje asi 100 sekund během vysokého špičkového zatížení. Můžete také použít monitorovací platformy, jako je ClusterControl, nastavit jej tak, aby vám zasílal upozornění na základě metrik, které chcete sledovat.
Kromě toho si uvědomte, že v příkladovém scénáři se převzetí služeb při selhání nezdařilo kvůli chybě nedostatku paměti. Můžete zvážit zajištění toho, aby všechny vaše uzly měly dostatek paměti a správnou velikost binárních protokolů, protože by potřebovaly výpis binlogu pro fázi obnovy slave.
Nekonzistentní Slave, použití rozdílů se nezdařilo!
Pokud jde o zpoždění slave, protože MHA se pokusí synchronizovat přenosové protokoly s kandidátským masterem, ujistěte se, že jsou vaše data synchronizovaná. Řekněte příklad níže:
...
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]Nekonzistentní cluster je opravdu špatný, zvláště když je povoleno automatické převzetí služeb při selhání. V tomto případě nemůže převzetí služeb při selhání pokračovat, protože detekuje duplicitní záznam pro primární klíč '12583545 '.
Opravy/Rozlišení:
Existuje několik věcí, které můžete udělat, abyste se vyhnuli nekonzistentnímu stavu vašeho clusteru.
- Povolte bezztrátovou semisynchronní replikaci. Podívejte se na tento externí blog, který je dobrým způsobem, jak zjistit, proč byste měli zvážit použití semi-synchronizace ve standardním nastavení replikace MySQL.
- Neustále spouštějte kontrolní součet proti clusteru master-slave. Můžete použít pt-table-checksum a spouštět jej jednou za týden nebo měsíc v závislosti na tom, jak neustále je vaše tabulka aktualizována. Vezměte na vědomí, že pt-table-checksum může zvýšit režii vašeho databázového provozu.
- Používejte replikaci založenou na GTID. I když to nebude mít vliv na problém jako takový. Replikace založená na GTID vám však pomáhá určit chybné transakce, zejména ty transakce, které byly spuštěny přímo na podřízeném zařízení. Další výhodou tohoto je snadnější správa replikace založené na GTID, když potřebujete v replikaci přepnout hlavního hostitele.
Selhání hardwaru na hlavním zařízení, ale otroci to ještě nedohnali
Jedním z mnoha důvodů, proč byste investovali do automatického převzetí služeb při selhání, je selhání hardwaru na hlavním serveru. U některých nastavení může být ideálnější provést automatické převzetí služeb při selhání pouze v případě, že master narazí na selhání hardwaru. Typickým přístupem je upozornit odesláním poplachu – což může znamenat probuzení zavolaného operátora uprostřed noci a nechat na něm, aby se rozhodl, co má dělat. Tento typ přístupu se provádí na Github nebo dokonce na Facebooku. Selhání hardwaru, zejména pokud je ovlivněn svazek, ve kterém jsou uloženy vaše binární protokoly a datový adresář, může narušit vaše převzetí služeb při selhání, zejména pokud jsou binární protokoly uloženy na tomto neúspěšném disku. Podle návrhu se MHA pokusí uložit binární protokoly z havarovaného hlavního serveru, ale to nemůže být možné, pokud disk selhal. Jedním z možných scénářů je, že server nebude dostupný přes SSH. MHA nemůže uložit binární protokoly a musí provést převzetí služeb při selhání bez použití událostí binárního protokolu, které existují pouze na zhrouceném hlavním serveru. To povede ke ztrátě nejnovějších dat, zvláště pokud žádný slave nedohoní master.
Opravy/Rozlišení
Jako jeden z případů použití MHA se doporučuje používat semisynchronní replikaci, protože výrazně snižuje riziko takové ztráty dat. Je důležité poznamenat, že všechny zápisy směřující do hlavního serveru musí zajistit, aby podřízené jednotky před synchronizací na disk obdržely nejnovější události binárního protokolu. MHA může aplikovat události na všechny ostatní otroky, takže mohou být vzájemně konzistentní.
Kromě toho je také lepší spustit záložní proud vašich binárních protokolů pro obnovu po havárii v případě, že hlavní diskový svazek selže. Pokud je server stále přístupný přes SSH, pak nasměrování cesty binárního protokolu na cestu k zálohování vašeho binárního protokolu může stále fungovat, takže převzetí služeb při selhání a obnova podřízeného zařízení mohou stále pokračovat. Tímto způsobem se můžete vyhnout ztrátě dat.
VIP (Virtual IP) Failover způsobující rozdělení mozku
MHA ve výchozím nastavení nezvládá žádnou VIP správu. Je však snadné to začlenit do konfigurace MHA a přiřadit háky podle toho, co chcete, aby MHA během převzetí služeb při selhání udělal. Můžete si nastavit svůj vlastní skript a připojit jej k parametrům master_ip_failover_script nebo master_ip_online_change_script. Existují také vzorové skripty, které jsou umístěny v adresáři
Během automatického převzetí služeb při selhání, jakmile je vyvolán a spuštěn váš skript se správou VIP, MHA provede následující:zkontroluje stav, odstraní (nebo zastaví) starý VIP a poté znovu přiřadí nový VIP novému masteru. Typickým příkladem rozděleného mozku je, když je master identifikován jako mrtvý kvůli problému se sítí, ale ve skutečnosti jsou podřízené uzly stále schopné se připojit k master. To je falešně pozitivní a často vede k nekonzistenci dat napříč databázemi v nastavení. Příchozí připojení klientů pomocí VIP budou odeslána novému masteru. Zatímco na druhé straně mohou existovat místní připojení běžící na starém masteru, který má být mrtvý. Místní připojení by mohla používat unixový soket nebo localhost ke snížení síťových skoků. To může způsobit posun dat proti novému masteru a zbytku jeho slave, protože data ze starého masteru nebudou replikována do slave.
Opravy/Rozlišení:
Jak bylo uvedeno dříve, někteří mohou preferovat vyhnout se automatickému převzetí služeb při selhání, pokud kontroly nezjistí, že hlavní zařízení je zcela mimo provoz (například selhání hardwaru), tj. ani podřízené uzly ho nejsou schopny dosáhnout. Myšlenka je taková, že falešně pozitivní může být způsobeno síťovou závadou mezi řadičem uzlu MHA a masterem, takže člověk může být v tomto případě vhodnější k tomu, aby se rozhodl, zda přepnout nebo ne.
Při řešení falešných poplachů má MHA parametr nazvaný sekundární_kontrolní_script. Hodnotou zde mohou být vaše vlastní skripty nebo můžete použít vestavěný skript /usr/local/bin/masterha_secondary_check který je dodáván spolu s balíčkem MHA Manager. To přidává další kontroly, což je ve skutečnosti doporučený přístup, aby se zabránilo falešným poplachům. V níže uvedeném příkladu z mého vlastního nastavení používám vestavěný skript 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=3306Ve výše uvedeném příkladu MHA Manager provede smyčku na základě seznamu podřízených uzlů (určených argumentem -s), která zkontroluje připojení k hostiteli MySQL master (192.168.10.60). Vezměte na vědomí, že tyto podřízené uzly v příkladu mohou být některé externí vzdálené uzly, které mohou navázat připojení k databázovým uzlům v klastru. Toto je doporučený přístup zejména pro ta nastavení, kde MHA Manager běží v jiném datovém centru nebo jiné síti než databázové uzly. Následující sekvence níže ukazuje, jak postupuje s kontrolami:
- Z hostitele MHA -> zkontrolujte připojení TCP k 1. podřízenému uzlu (IP:192.168.10.50). Nazvěme to jako připojení A. Poté z podřízeného uzlu zkontroluje TCP spojení s nadřízeným uzlem (192.168.10.60). Nazvěme toto spojení B.
Pokud bylo „Připojení A“ úspěšné, ale „Připojení B“ bylo neúspěšné v obou trasách, masterha_secondary_check skript se ukončí s návratovým kódem 0 a MHA Manager rozhodne, že hlavní server MySQL je skutečně mrtvý, a spustí převzetí služeb při selhání. Pokud bylo „Připojení A“ neúspěšné, masterha_secondary_check ukončí se s návratovým kódem 2 a MHA Manager odhadne, že došlo k problému se sítí a nespustí převzetí služeb při selhání. Pokud bylo „Připojení B“ úspěšné, masterha_secondary_check ukončí se s návratovým kódem 3 a MHA Manager pochopí, že hlavní server MySQL je skutečně aktivní a nespustí převzetí služeb při selhání.
Příklad toho, jak reaguje během převzetí služeb při selhání na základě protokolu,
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 0Další věc, kterou je třeba přidat, je přiřazení hodnoty parametru shutdown_script. Tento skript je zvláště užitečný, pokud musíte implementovat správný STONITH nebo uzlové oplocení, aby nevstal z mrtvých. To může zabránit nekonzistenci dat.
Nakonec se ujistěte, že MHA Manager sídlí ve stejné místní síti spolu s uzly clusteru, protože to snižuje možnost výpadků sítě, zejména připojení z MHA Manager k uzlům databáze.
Vyhnutí se SPOF v MHA
MHA může selhat z různých důvodů a bohužel neexistuje žádná vestavěná funkce, která by to napravila, tj. Vysoká dostupnost pro MHA. Nicméně, jak jsme diskutovali v našem předchozím blogu "Master High Availability Manager (MHA) havaroval! Co mám dělat teď?", existuje způsob, jak se vyhnout SPOF pro MHA.
Opravy/Rozlišení:
Pacemaker můžete využít k vytvoření aktivních/pohotovostních uzlů spravovaných správcem prostředků clusteru (crm). Případně můžete vytvořit skript pro kontrolu stavu uzlu správce MHA. Můžete například zřídit záložní uzel, který aktivně kontroluje uzel správce MHA tak, že ssh'ing spustí vestavěný skript masterha_check_status stejně jako níže:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).pak udělejte nějaké oplocení uzlů, pokud je tento ovladač borked. Můžete také rozšířit nástroj MHA o pomocný skript, který běží přes úlohu cron a monitoruje systémový proces skriptu masterha_manager a znovu jej spustí, pokud je proces mrtvý.
Ztráta dat během převzetí služeb při selhání
MHA spoléhá na tradiční asynchronní replikaci. Přestože podporuje semisynchronizaci, stále se semi-synchronizace spoléhá na asynchronní replikaci. V tomto typu prostředí může po převzetí služeb při selhání dojít ke ztrátě dat. Když vaše databáze není správně nastavena a nepoužívá staromódní přístup replikace, pak to může být nepříjemné, zejména při řešení konzistence dat a ztracených transakcí.
Další důležitou věcí, kterou je třeba poznamenat u ztráty dat s MHA, je použití GTID bez aktivované polosynchronizace. MHA s GTID se nepřipojí přes ssh k hlavnímu serveru, ale nejprve se pokusí synchronizovat binární protokoly pro obnovu uzlů s podřízenými zařízeními. To může potenciálně vést k větším ztrátám dat než ve srovnání s MHA bez GTID s nepovolenou semi-synchronizací.
Opravy/Rozlišení
Při provádění automatického převzetí služeb při selhání vytvořte seznam scénářů, kdy očekáváte převzetí služeb při selhání MHA. Vzhledem k tomu, že MHA se zabývá replikací master-slave, naše rady, jak se vyhnout ztrátě dat, jsou následující:
- Povolit bezztrátovou semi-synchronní replikaci (existuje ve verzi MySQL 5.7)
- Používejte replikaci založenou na GTID. Samozřejmě můžete použít tradiční replikaci pomocí binlogových souřadnic x &y. To však dělá věci složitějšími a časově náročnějšími, když potřebujete najít konkrétní binární záznam protokolu, který nebyl použit na podřízeném zařízení. S GTID v MySQL je tedy snazší odhalit chybné transakce.
- Aby vaše replikace MySQL master-slave vyhovovala ACID, povolte tyto specifické proměnné:sync_binlog =1, innodb_flush_log_at_trx_commit =1. To je drahé, protože vyžaduje větší výpočetní výkon, když MySQL volá funkci fsync() při potvrzení, a výkon V případě velkého počtu zápisů může být disk vázán. Použití pole RAID s mezipamětí pro zálohování baterie však šetří I/O vašeho disku. Kromě toho se samotná MySQL zlepšila pomocí binárního zápisu skupiny, ale stále použití záložní mezipaměti může ušetřit některé synchronizace disku.
- Využijte paralelní replikaci nebo vícevláknovou slave replikaci. To může pomoci vašim otrokům stát se výkonnějšími a vyhnout se slave lagům proti pánovi. Nechcete, aby k vašemu automatickému převzetí služeb při selhání docházelo, když master není vůbec dosažitelný prostřednictvím připojení ssh nebo tcp, nebo pokud došlo k selhání disku a vaše podřízené jednotky zaostávají. To by mohlo vést ke ztrátě dat.
- Při provádění online nebo ručního převzetí služeb při selhání je nejlepší, abyste je prováděli během období mimo špičku, abyste předešli neočekávaným nehodám, které by mohly vést ke ztrátě dat. Nebo abyste se vyhnuli časově náročnému prohledávání vašich binárních protokolů, zatímco probíhá spousta aktivity.
MHA říká, že APP neběží nebo nefunguje převzetí služeb při selhání. Co mám dělat?
Spuštění kontrol pomocí vestavěného skriptu masterha_check_status zkontroluje, zda je spuštěn skript mastreha_manager. V opačném případě se zobrazí chyba jako níže:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf app1 is stopped(2:NOT_RUNNING).Existují však určité případy, kdy můžete získat NOT_RUNNING, i když masterha_manager běží. Může to být způsobeno oprávněním ssh_user, které jste nastavili, nebo jste spustili masterha_manager s jiným systémovým uživatelem nebo uživatel ssh narazil na odepřené oprávnění.
Opravy/Rozlišení:
MHA použije ssh_user definované v konfiguraci, pokud je specifikováno. V opačném případě použije aktuálního uživatele systému, kterého používáte k vyvolání příkazů MHA. Při spuštění skriptu masterha_check_status například musíte zajistit, aby masterha_manager běžel se stejným uživatelem, který je uveden v ssh_user ve vašem konfiguračním souboru nebo uživatele, který bude rozhraním s ostatními databázovými uzly v klastru. Musíte se ujistit, že má SSH klíče bez hesla a přístupové fráze, takže MHA nebude mít žádné problémy při navazování připojení k uzlům, které MHA monitoruje.
Vezměte na vědomí, že potřebujete ssh_user abyste měli přístup k následujícímu:
- Umí číst binární a přenosové protokoly uzlů MySQL, které MHA monitoruje
- Musí mít přístup k protokolům monitorování MHA. Podívejte se na tyto parametry v MHA:master_binlog_dir, manager_workdir a manager_log
- Musí mít přístup ke konfiguračnímu souboru MHA. To je také velmi důležité. Během převzetí služeb při selhání, jakmile dokončí převzetí služeb při selhání, pokusí se aktualizovat konfigurační soubor a odstranit záznam mrtvého hlavního serveru. Pokud konfigurační soubor nepovoluje ssh_user nebo uživatele operačního systému, kterého aktuálně používáte, neaktualizuje konfigurační soubor, což povede k eskalaci problému, pokud dojde ke katastrofě znovu.
Kandidát Master zaostává, jak vynutit a vyhnout se neúspěšnému selhání
Pokud jde o wiki MHA, ve výchozím nastavení platí, že pokud slave za masterem má více než 100 MB protokolů přenosu (=potřebuje použít více než 100 MB protokolů přenosu), MHA nevybere slave jako nového mastera, protože obnovení trvá příliš dlouho. .
Opravy/Rozlišení
V MHA to lze přepsat nastavením parametru check_repl_delay=0. Během převzetí služeb při selhání MHA ignoruje zpoždění replikace při výběru nového hlavního serveru a provede chybějící transakce. Tato možnost je užitečná, když na konkrétním hostiteli nastavíte kandidát_master=1 a chcete se ujistit, že hostitel může být novým hostitelem.
Můžete také integrovat s pt-heartbeat, abyste dosáhli přesnosti slave lag (viz tento příspěvek a tento). Ale to lze také zmírnit pomocí paralelní replikace nebo vícevláknových replikačních slave, které jsou k dispozici od MySQL 5.6, nebo MariaDB 10, která tvrdí, že má podporu s 10x zlepšením paralelní replikace a vícevláknovými slave zařízeními. To může pomoci vašim otrokům replikovat se rychleji.
Hesla MHA jsou odhalena
Securing or encrypting the passwords isn't something that is handled by 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