Replikace MySQL je velmi oblíbený způsob vytváření vysoce dostupných databázových vrstev. Je velmi dobře známý, testovaný a robustní. Není to však bez omezení. Jedním z nich je rozhodně fakt, že využívá pouze jeden „vstupní bod“ – v topologii máte dedikovaný server, tedy master, a je to jediný uzel v clusteru, do kterého můžete zapisovat. To vede k vážným následkům – master je jediným bodem selhání a pokud selže, aplikace nemůže provést žádný zápis. Není překvapením, že bylo vynaloženo mnoho práce na vývoj nástrojů, které by snížily dopad ztráty masteru. Jistě, existují diskuse, jak k tématu přistupovat, zda je automatické převzetí služeb při selhání lepší než ruční nebo ne. Nakonec je to obchodní rozhodnutí, ale pokud se rozhodnete jít cestou automatizace, budete hledat nástroje, které vám pomohou toho dosáhnout. Jedním z nástrojů, který je stále velmi oblíbený, je MHA (Master High Availability). I když možná již není aktivně udržován, je stále ve stabilním stavu a jeho obrovská popularita z něj stále dělá páteř vysoce dostupných replikačních nastavení MySQL. Co by se však stalo, kdyby samotný MHA přestal být dostupný? Může se to stát jediným bodem selhání? Existuje způsob, jak tomu zabránit? V tomto příspěvku na blogu se podíváme na některé scénáře.
Za prvé, pokud plánujete používat MHA, ujistěte se, že používáte nejnovější verzi z repozitáře. Nepoužívejte binární vydání, protože neobsahují všechny opravy. Instalace je poměrně jednoduchá. MHA se skládá ze dvou částí, manažera a uzlu. Uzel má být nasazen na vaše databázové servery. Manager bude nasazen na samostatném hostiteli spolu s uzlem. Takže databázové servery:uzel, hostitel správy:manažer a uzel.
Kompilace MHA je docela snadná. Přejděte na GitHub a klonujte repozitáře.
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node
Pak je to všechno o:
perl Makefile.PL
make
make installPokud ještě nemáte nainstalované všechny požadované balíčky, možná budete muset nainstalovat některé závislosti na perlu. V našem případě na Ubuntu 16.04 jsme museli nainstalovat následující:
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"Jakmile máte MHA nainstalovaný, musíte jej nakonfigurovat. Nebudeme zde zacházet do žádných podrobností, na internetu je mnoho zdrojů, které pokrývají tuto část. Ukázková konfigurace (určitě neprodukční) může vypadat takto:
[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=1Dalším krokem bude zjistit, zda vše funguje a jak MHA vidí replikaci:
[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).No, havarovalo to. Je to proto, že MHA se pokouší analyzovat verzi MySQL a neočekává v ní pomlčky. Naštěstí lze opravu snadno najít:https://github.com/yoshinorim/mha4mysql-manager/issues/116.
Nyní máme MHA připravenou k práci.
[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 můžete vidět, MHA monitoruje naši replikační topologii a kontroluje, zda je hlavní uzel dostupný nebo ne. Podívejme se na několik scénářů.
Scénář 1 – selhání MHA
Předpokládejme, že MHA není k dispozici. Jak to ovlivní životní prostředí? Vzhledem k tomu, že MHA je samozřejmě zodpovědná za sledování zdraví velitele a spouštění převzetí služeb při selhání, k tomu nedojde, když je MHA mimo provoz. Hlavní pád nebude detekován, nedojde k převzetí služeb při selhání. Problém je v tom, že ve skutečnosti nemůžete spustit více instancí MHA současně. Technicky to můžete udělat, ačkoli MHA si bude stěžovat na soubor zámku:
[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.Spustí se však a pokusí se monitorovat prostředí. Problém je, když oba začnou provádět akce na clusteru. Horší případ by byl, kdyby se rozhodli použít různé slave jako hlavního kandidáta a převzetí služeb při selhání bude provedeno ve stejnou dobu (MHA používá soubor zámku, který zabraňuje následným selháním, aby se stalo, ale pokud se vše stane ve stejnou dobu, a to se stalo v našem testy, toto bezpečnostní opatření nestačí).
Bohužel neexistuje žádný vestavěný způsob spouštění MHA vysoce dostupným způsobem. Nejjednodušším řešením bude napsat skript, který by otestoval, zda MHA běží, a pokud ne, spustí jej. Takový skript by musel být spuštěn z cronu nebo napsán ve formě démona, pokud 1 minuta granularity cronu nestačí.
Scénář 2 – Uzel správce MHA ztratil síťové připojení k hlavnímu serveru
Buďme upřímní, je to opravdu špatná situace. Jakmile se MHA nemůže připojit k masteru, pokusí se provést převzetí služeb při selhání. Jedinou výjimkou je, pokud je definován sekundární_check_script a ověřuje, že hlavní server je naživu. Je na uživateli, aby přesně definoval, jaké akce má MHA provést pro ověření stavu mastera – vše závisí na prostředí a přesném nastavení. Dalším velmi důležitým skriptem, který je třeba definovat, je master_ip_failover_script – spouští se při převzetí služeb při selhání a měl by být mimo jiné použit k zajištění toho, že se starý master nezobrazí. Pokud máte náhodou přístup k dalším způsobům, jak dosáhnout a zastavit starého mistra, je to opravdu skvělé. Mohou to být nástroje pro vzdálenou správu, jako je Integrated Lights-out, může to být přístup ke spravovatelným napájecím zásuvkám (kde stačí vypnout server), může to být přístup k CLI poskytovatele cloudu, což umožní zastavit virtuální instanci. . Je nanejvýš důležité zastavit starého mastera - jinak se může stát, že po odstranění problému se sítí skončíte se dvěma zapisovatelnými uzly v systému, což je perfektní řešení pro rozdělený mozek, stav, ve kterém data se rozcházela mezi dvěma částmi stejného clusteru.
Jak můžete vidět, MHA si docela dobře poradí s převzetím služeb při selhání MySQL. Rozhodně to vyžaduje pečlivou konfiguraci a budete muset napsat externí skripty, které budou použity k zabití starého mistra a zajištění toho, že k rozštěpení mozku nedojde. Přesto bychom stále doporučovali používat pokročilejší nástroje pro správu převzetí služeb při selhání, jako je Orchestrator nebo ClusterControl, které mohou provádět pokročilejší analýzu stavu topologie replikace (například pomocí podřízených zařízení nebo proxy k posouzení dostupnosti hlavního zařízení) a které jsou a bude zachována i v budoucnu. Pokud se chcete dozvědět, jak ClusterControl provádí převzetí služeb při selhání, rádi bychom vás pozvali, abyste si přečetli tento blogový příspěvek o procesu převzetí služeb při selhání v ClusterControl. Můžete se také dozvědět, jak ClusterControl spolupracuje s ProxySQL a zajišťuje hladké a transparentní převzetí služeb při selhání pro vaši aplikaci. ClusterControl můžete vždy otestovat jeho stažením zdarma.