MySQL-replikering är ett mycket populärt sätt att bygga högt tillgängliga databaslager. Den är mycket välkänd, testad och robust. Det är dock inte utan begränsningar. En av dem är definitivt det faktum att den bara använder en "ingångspunkt" - du har en dedikerad server i topologin, mastern, och det är den enda noden i klustret som du kan skriva skrivningar till. Detta leder till allvarliga konsekvenser - mastern är den enda punkten för fel och om den misslyckas kan ingen skrivning utföras av applikationen. Det är inte en överraskning att mycket arbete har lagts på att utveckla verktyg, vilket skulle minska effekten av en masterförlust. Visst, det finns diskussioner om hur man ska närma sig ämnet, är den automatiserade failoveren bättre än den manuella eller inte. Så småningom är detta ett affärsbeslut att ta, men om du skulle besluta dig för att följa automationsvägen, kommer du att leta efter verktygen som hjälper dig att uppnå det. Ett av verktygen, som fortfarande är mycket populärt, är MHA (Master High Availability). Även om den kanske inte underhålls aktivt längre, är den fortfarande i stabil form och dess enorma popularitet gör den fortfarande till ryggraden i de högt tillgängliga MySQL-replikeringsinställningarna. Vad skulle dock hända om MHA själv blev otillgänglig? Kan det bli en enda punkt av misslyckande? Finns det något sätt att förhindra att det händer? I det här blogginlägget kommer vi att ta en titt på några av scenarierna.
Först och främst, om du planerar att använda MHA, se till att du använder den senaste versionen från repo. Använd inte binära utgåvor eftersom de inte innehåller alla korrigeringar. Installationen är ganska enkel. MHA består av två delar, chef och nod. Noden ska distribueras på dina databasservrar. Manager kommer att distribueras på en separat värd, tillsammans med nod. Så, databasservrar:nod, management host:manager och nod.
Det är ganska enkelt att kompilera MHA. Gå till GitHub och klonförråd.
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node
Då handlar det om:
perl Makefile.PL
make
make installDu kan behöva installera vissa perl-beroenden om du inte har alla nödvändiga paket redan installerade. I vårt fall, på Ubuntu 16.04, var vi tvungna att installera följande:
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"När du har installerat MHA måste du konfigurera det. Vi kommer inte att gå in på några detaljer här, det finns många resurser på internet som täcker denna del. En exempelkonfiguration (definitivt icke-produktion) kan se ut så här:
[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=1Nästa steg blir att se om allt fungerar och hur MHA ser på replikeringen:
[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).Nåväl, det kraschade. Detta beror på att MHA försöker analysera MySQL-versionen och den förväntar sig inte bindestreck i den. Lyckligtvis är korrigeringen lätt att hitta:https://github.com/yoshinorim/mha4mysql-manager/issues/116.
Nu har vi MHA redo för arbete.
[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..Som du kan se övervakar MHA vår replikeringstopologi och kontrollerar om masternoden är tillgänglig eller inte. Låt oss överväga ett par scenarier.
Scenario 1 - MHA kraschade
Låt oss anta att MHA inte är tillgängligt. Hur påverkar detta miljön? Uppenbarligen, eftersom MHA är ansvarig för att övervaka befälhavarens hälsa och utlösa failover, kommer detta inte att hända när MHA är nere. Masterkrasch kommer inte att upptäckas, failover kommer inte att ske. Problemet är att du inte riktigt kan köra flera MHA-instanser samtidigt. Tekniskt sett kan du göra det även om MHA kommer att klaga på låsfilen:
[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.Det kommer dock att starta och det kommer att försöka övervaka miljön. Problemet är när båda börjar utföra åtgärder på klustret. Värre fall skulle vara om de bestämmer sig för att använda olika slavar eftersom masterkandidaten och failover kommer att exekveras samtidigt (MHA använder en låsfil som förhindrar efterföljande failovers från att hända men om allt händer samtidigt, och det hände i vår tester, denna säkerhetsåtgärd räcker inte).
Tyvärr finns det inget inbyggt sätt att köra MHA på ett mycket tillgängligt sätt. Den enklaste lösningen är att skriva ett skript som testar om MHA körs och om inte, starta det. Sådant skript skulle behöva köras från cron eller skrivas i form av en demon, om 1 minuts granularitet av cron inte räcker.
Scenario 2 - MHA Manager Node förlorade nätverksanslutning till mastern
Låt oss vara ärliga, det här är en riktigt dålig situation. Så snart MHA inte kan ansluta till mastern kommer den att försöka utföra en failover. Det enda undantaget är om secondary_check_script är definierat och det verifierar att mastern är vid liv. Det är upp till användaren att definiera exakt vilka åtgärder MHA ska utföra för att verifiera befälhavarens status - allt beror på miljön och exakta inställningar. Ett annat mycket viktigt skript att definiera är master_ip_failover_script - detta exekveras vid failover och det bör bland annat användas för att säkerställa att den gamla mastern inte kommer att dyka upp. Om du råkar ha tillgång till ytterligare sätt att nå och stoppa den gamla mästaren är det riktigt bra. Det kan vara fjärrhanteringsverktyg som Integrated Lights-out, det kan vara tillgång till hanterbara eluttag (där du bara kan stänga av servern), det kan vara tillgång till molnleverantörens CLI, som kommer att göra det möjligt att stoppa den virtuella instansen . Det är av yttersta vikt att stoppa den gamla mastern - annars kan det hända att du, efter att nätverksproblemet är borta, kommer att få två skrivbara noder i systemet, vilket är en perfekt lösning för den delade hjärnan, ett tillstånd där data divergerade mellan två delar av samma kluster.
Som du kan se kan MHA hantera MySQL-failoveren ganska bra. Det kräver definitivt noggrann konfiguration och du måste skriva externa skript, som kommer att användas för att döda den gamla mästaren och säkerställa att den splittrade hjärnan inte kommer att hända. Med det sagt skulle vi fortfarande rekommendera att använda mer avancerade failover-hanteringsverktyg som Orchestrator eller ClusterControl, som kan utföra mer avancerad analys av replikeringstopologins tillstånd (till exempel genom att använda slavar eller proxyservrar för att bedöma masterns tillgänglighet) och vilka är och kommer att bibehållas i framtiden. Om du är intresserad av att lära dig hur ClusterControl utför failover, vill vi bjuda in dig att läsa det här blogginlägget om failover-processen i ClusterControl. Du kan också lära dig hur ClusterControl interagerar med ProxySQL och levererar smidig, transparent failover för din applikation. Du kan alltid testa ClusterControl genom att ladda ner det gratis.