I våra tidigare bloggar diskuterade vi MHA som ett failover-verktyg som används i MySQL master-slave-inställningar. Förra månaden bloggade vi också om hur man hanterar MHA när det kraschade. Idag kommer vi att se de vanligaste problemen som DBA:er vanligtvis stöter på med MHA, och hur du kan åtgärda dem.
En kort introduktion till MHA (Master High Availability)
MHA står för (Master High Availability) är fortfarande relevant och används flitigt idag, speciellt i master-slave-uppsättningar baserade på icke-GTID-replikering. MHA fungerar bra med en failover eller master-switch, men det kommer med vissa fallgropar och begränsningar. När MHA väl har utfört en master-failover och slavkampanj, kan den automatiskt slutföra sin databas-failover-operation inom ~30 sekunder, vilket kan vara acceptabelt i en produktionsmiljö. MHA kan säkerställa konsistensen av data. Allt detta med noll prestandaförsämring, och det kräver inga ytterligare justeringar eller ändringar av dina befintliga distributioner eller inställningar. Bortsett från detta är MHA byggd ovanpå Perl och är en HA-lösning med öppen källkod - så det är relativt enkelt att skapa hjälpare eller utöka verktyget i enlighet med din önskade inställning. Kolla in den här presentationen för mer information.
MHA-programvaran består av två komponenter, du måste installera ett av följande paket i enlighet med dess topologiroll:
MHA manager node =MHA Manager (hanterare)/MHA Node (data nod)
Master/Slavnoder =MHA Node (datanod)
MHA Manager är programvaran som hanterar failover (automatisk eller manuell), fattar beslut om när och var failover, och hanterar slavåterställning under marknadsföring av kandidatmastern för tillämpning av differentiella reläloggar. Om masterdatabasen dör kommer MHA Manager att samordna med MHA Node-agenten eftersom den tillämpar differentiella reläloggar till slavarna som inte har de senaste binlog-händelserna från mastern. MHA Node-mjukvaran är en lokal agent som övervakar din MySQL-instans och låter MHA Manager kopiera reläloggar från slavarna. Typiskt scenario är att när kandidatmastern för failover för närvarande släpar och MHA upptäcker att den inte har de senaste reläloggarna. Därför kommer den att vänta på sitt mandat från MHA Manager när den söker efter den senaste slaven som innehåller binlog-händelserna och kopierar saknade händelser från slaven med hjälp av scp och tillämpar dem på sig själv.
Observera dock att MHA för närvarande inte underhålls aktivt, men den nuvarande versionen i sig är stabil och kan vara "tillräckligt bra" för produktion. Du kan fortfarande eka din röst genom github för att lösa vissa problem eller tillhandahålla patchar till programvaran.
De vanligaste problemen
Låt oss nu titta på de vanligaste problemen som en DBA kommer att stöta på när du använder MHA.
Slaven släpar efter, icke-interaktiv/automatiserad failover misslyckades!
Detta är ett typiskt problem som gör att automatisk failover avbryts eller misslyckas. Detta kan låta enkelt men det pekar inte bara på ett specifikt problem. Slavfördröjning kan ha olika anledningar:
- Diskproblem på kandidatmastern som gör att den är I/O-bunden för att bearbeta läsning och skrivning. Det kan också leda till datakorruption om det inte åtgärdas.
- Dåliga frågor replikeras, särskilt tabeller som inte har några primärnycklar eller klustrade index.
- hög serverbelastning.
- Kall server och server har inte värmts upp ännu
- Otillräckliga serverresurser. Möjligt att din slav kan ha för lite minne eller serverresurser medan den replikerar högintensiva skrivningar eller läsningar.
Dessa kan mildras i förväg om du har ordentlig övervakning av din databas. Ett exempel när det gäller slavlags i MHA är lågt minne vid dumpning av en stor binär loggfil. Som ett exempel nedan markerades en master som död och den måste utföra en icke-interaktiv/automatisk failover. Men eftersom kandidatmästaren släpade och den måste tillämpa loggarna som ännu inte kördes av replikeringstrådarna, kommer MHA att hitta den mest uppdaterade eller senaste slaven eftersom den kommer att försöka återställa en slav mot den äldsta ettor. Därför, som du kan se nedan, blev minnet för lågt medan det utförde en slavåterställning:
[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.Således misslyckades failover. Det här exemplet ovan visar att nod 192.168.10.70 innehåller de mest uppdaterade reläloggarna. I detta exempelscenario är dock nod 192.168.10.70 inställd som no_master eftersom den har lågt minne. När den försöker återställa slaven 192.168.10.50, misslyckas den!
Åtgärningar/upplösning:
Detta scenario illustrerar något mycket viktigt. En avancerad övervakningsmiljö måste ställas in! Du kan till exempel köra ett bakgrunds- eller demonskript som övervakar replikeringens hälsa. Du kan lägga till som en post genom ett cron-jobb. Lägg till exempel till en post med det inbyggda skriptet masterha_check_repl :
/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnfeller skapa ett bakgrundsskript som anropar detta skript och kör det i ett intervall. Du kan använda alternativet report_script för att ställa in en varningsavisering om den inte överensstämmer med dina krav, t.ex. om slaven släpar efter i cirka 100 sekunder under en hög toppbelastning. Du kan också använda övervakningsplattformar som t.ex. ClusterControl konfigurerar det för att skicka meddelanden baserat på de mätvärden du vill övervaka.
Utöver detta, notera att i exempelscenariot misslyckades failover på grund av att minnet är slut. Du kan överväga att se till att alla dina noder har tillräckligt med minne och rätt storlek på binära loggar eftersom de skulle behöva dumpa binloggen för en slavåterställningsfas.
Inkonsekvent slav, applicering av diff misslyckades!
När det gäller slavfördröjning, eftersom MHA kommer att försöka synkronisera reläloggar till en kandidatmaster, se till att dina data är synkroniserade. Säg ett exempel nedan:
...
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]Ett inkonsekvent kluster är riktigt dåligt, särskilt när automatisk failover är aktiverad. I det här fallet kan failover inte fortsätta eftersom det upptäcker en dubblettpost för primärnyckeln "12583545 '.
Åtgärningar/upplösning:
Det finns flera saker du kan göra här för att undvika inkonsekvent tillstånd för ditt kluster.
- Aktivera förlustfri semisynkron replikering. Kolla in den här externa bloggen som är ett bra sätt att lära dig varför du bör överväga att använda semi-sync i en standard MySQL-replikeringskonfiguration.
- Kör ständigt en kontrollsumma mot ditt master-slave-kluster. Du kan använda pt-table-checksum och köra det som en gång i veckan eller månaden beroende på hur konstant din tabell uppdateras. Observera att pt-table-checksum kan lägga till overhead till din databastrafik.
- Använd GTID-baserad replikering. Även om detta inte påverkar problemet i sig. GTID-baserad replikering hjälper dig dock att fastställa felaktiga transaktioner, särskilt de transaktioner som kördes direkt på slaven. En annan fördel med detta är att det är lättare att hantera GTID-baserad replikering när du behöver byta huvudvärd i replikering.
Hårdvarufel på mästaren men slavarna har inte kommit ikapp ännu
En av många anledningar till att du skulle investera i automatisk failover är ett hårdvarufel på mastern. För vissa inställningar kan det vara mer idealiskt att utföra automatisk failover endast när mastern stöter på ett maskinvarufel. Det typiska tillvägagångssättet är att meddela genom att skicka ett larm - vilket kan innebära att man väcker jourhavaren mitt i natten och låter personen bestämma vad han ska göra. Denna typ av tillvägagångssätt görs på Github eller till och med Facebook. Ett hårdvarufel, särskilt om volymen där dina binloggar och datakatalog finns påverkas, kan störa din failover, särskilt om de binära loggarna lagras på den defekta disken. Genom designen kommer MHA att försöka spara binära loggar från den kraschade mastern men detta kan inte vara möjligt om disken misslyckades. Ett möjligt scenario som kan hända är att servern inte kan nås via SSH. MHA kan inte spara binära loggar och måste göra failover utan att tillämpa binära logghändelser som bara finns på den kraschade mastern. Detta kommer att resultera i att de senaste data går förlorade, speciellt om ingen slav har hunnit ikapp mastern.
Åtgärningar/upplösning
Som ett av MHAs användningsfall rekommenderas det att använda semisynkron replikering eftersom det avsevärt minskar risken för sådan dataförlust. Det är viktigt att notera att alla skrivningar som går till mastern måste säkerställa att slavar har fått de senaste binära logghändelserna innan de synkroniseras till disken. MHA kan tillämpa händelserna på alla andra slavar så att de kan överensstämma med varandra.
Dessutom är det också bättre att köra en säkerhetskopia av dina binära loggar för katastrofåterställning om huvuddiskvolymen har misslyckats. Om servern fortfarande är tillgänglig via SSH, kan det fortfarande fungera att peka den binära loggsökvägen till backupsökvägen för din binära logg, så failover och slavåterställning kan fortfarande gå framåt. På så sätt kan du undvika dataförlust.
VIP (Virtual IP) Failover som orsakar Split-Brain
MHA hanterar som standard ingen VIP-hantering. Det är dock lätt att integrera detta med MHA:s konfiguration och tilldela krokar i enlighet med vad du vill att MHA ska göra under failover. Du kan ställa in ditt eget skript och koppla det till parametrarna master_ip_failover_script eller master_ip_online_change_script. Det finns också exempelskript som finns i katalogen
Under en automatisk failover, när ditt skript med VIP-hantering har anropats och körts, kommer MHA att göra följande:kontrollera status, ta bort (eller stoppa) den gamla VIP-enheten och sedan omtilldela den nya VIP-enheten till den nya mastern. Ett typiskt exempel på delad hjärna är när en master identifieras som död på grund av ett nätverksproblem men i själva verket kan slavnoder fortfarande ansluta till mastern. Detta är ett falskt positivt och leder ofta till datainkonsekvens mellan databaserna i installationen. Inkommande klientanslutningar som använder VIP kommer att skickas till den nya mastern. Medan å andra sidan kan det finnas lokala anslutningar som körs på gammal master, som är tänkt att vara död. De lokala anslutningarna kan vara att använda unix-uttaget eller localhost för att minska nätverkshoppen. Detta kan göra att data glider mot den nya mastern och resten av dess slavar, eftersom data från den gamla mastern inte kommer att replikeras till slavarna.
Åtgärningar/upplösning:
Som nämnts tidigare, kanske vissa föredrar att undvika automatisk failover om inte kontrollerna har fastställt att mastern är helt nere (som hårdvarufel), d.v.s. inte ens slavnoderna kan nå den. Tanken är att en falsk positiv kan orsakas av ett nätverksfel mellan MHA-nodkontrollern och mastern, så en människa kan i det här fallet vara bättre lämpad för att fatta ett beslut om en failover eller inte.
När man hanterar falsklarm har MHA en parameter som heter secondary_check_script. Värdet som placeras här kan vara dina anpassade skript eller så kan du använda det inbyggda skriptet /usr/local/bin/masterha_secondary_check som skickas tillsammans med MHA Manager-paketet. Detta lägger till extra kontroller som faktiskt är den rekommenderade metoden för att undvika falska positiva. I exemplet nedan från min egen installation använder jag det inbyggda skriptet 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=3306I exemplet ovan kommer MHA Manager att göra en loop baserat på listan över slavnoder (specificerad av -s argument) som kommer att kontrollera anslutningen mot MySQL master (192.168.10.60) värd. Observera att dessa slavnoder i exemplet kan vara några externa fjärrnoder som kan upprätta en anslutning till databasnoderna inom klustret. Detta är ett rekommenderat tillvägagångssätt speciellt för de inställningar där MHA Manager körs på ett annat datacenter eller annat nätverk än databasnoderna. Följande sekvens nedan illustrerar hur det går till med kontrollerna:
- Från MHA-värden -> kontrollera TCP-anslutningen till 1:a slavnoden (IP:192.168.10.50). Låt oss kalla detta för anslutning A. Sedan kontrollerar vi från slavnoden TCP-anslutningen till masternoden (192.168.10.60). Låt oss kalla detta anslutning B.
Om "Anslutning A" lyckades men "Anslutning B" misslyckades på båda rutterna, masterha_secondary_check skriptet avslutas med returkod 0 och MHA Manager bestämmer att MySQL master verkligen är död och kommer att starta failover. Om "Anslutning A" misslyckades, masterha_secondary_check avslutas med returkod 2 och MHA Manager gissar att det finns ett nätverksproblem och den startar inte failover. Om "Anslutning B" lyckades, masterha_secondary_check avslutas med returkod 3 och MHA Manager förstår att MySQL-masterservern faktiskt är vid liv och startar inte failover.
Ett exempel på hur det reagerar under failover baserat på loggen,
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 0En annan sak att lägga till är att tilldela ett värde till parametern shutdown_script. Det här skriptet är särskilt användbart om du måste implementera ett ordentligt STONITH- eller nodfäktning så att det inte kommer att resa sig från de döda. Detta kan undvika datainkonsekvens.
Slutligen, se till att MHA Manager finns inom samma lokala nätverk tillsammans med klusternoderna eftersom det minskar risken för nätverksavbrott, särskilt anslutningen från MHA Manager till databasnoderna.
Undviker SPOF i MHA
MHA kan krascha av olika anledningar, och tyvärr finns det ingen inbyggd funktion för att fixa detta, dvs hög tillgänglighet för MHA. Men som vi har diskuterat i vår tidigare blogg "Master High Availability Manager (MHA) Has Crashed! What Do I Do Now?", finns det ett sätt att undvika SPOF för MHA.
Åtgärningar/upplösning:
Du kan använda Pacemaker för att skapa aktiva/standby-noder som hanteras av klusterresurshanteraren (crm). Alternativt kan du skapa ett skript för att kontrollera MHA-hanterarnodens tillstånd. Du kan till exempel tillhandahålla en standby-nod som aktivt kontrollerar MHA-hanterarnoden genom att ssh'a för att köra det inbyggda skriptet masterha_check_status precis som nedan:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).gör sedan några nodfäktning om den styrenheten är borrad. Du kan också utöka MHA-verktyget med ett hjälpskript som körs via cron-jobbet och övervaka systemprocessen för masterha_manager-skriptet och skapa det igen om processen är död.
Dataförlust under failover
MHA förlitar sig på den traditionella asynkrona replikeringen. Även om det stöder semi-synkronisering, förlitar sig fortfarande semi-sync på asynkron replikering. I denna typ av miljö kan dataförlust inträffa efter en failover. När din databas inte är korrekt konfigurerad och använder en gammaldags metod för replikering, kan det vara jobbigt, särskilt när det gäller datakonsistens och förlorade transaktioner.
En annan viktig sak att notera med dataförlust med MHA, är när GTID används utan semi-sync aktiverad. MHA med GTID kommer inte att ansluta via ssh till mastern men kommer att försöka synkronisera de binära loggarna för nodåterställning med slavarna först. Detta kan potentiellt leda till mer dataförlust än jämfört med MHA icke-GTID med semi-sync inte aktiverad.
Åtgärningar/upplösning
När du utför automatisk failover, skapa en lista med scenarier när du förväntar dig att din MHA ska failover. Eftersom MHA sysslar med master-slave replikering är våra råd till dig för att undvika dataförlust följande:
- Aktivera förlustfri semi-synk replikering (finns i version MySQL 5.7)
- Använd GTID-baserad replikering. Naturligtvis kan du använda den traditionella replikeringen genom att använda binlogs x &y-koordinater. Det gör dock saker svårare och mer tidskrävande när du behöver hitta en specifik binär loggpost som inte tillämpades på slaven. Med GTID i MySQL är det därför lättare att upptäcka felaktiga transaktioner.
- För ACID-kompatibilitet för din MySQL master-slave-replikering, aktivera dessa specifika variabler:sync_binlog =1, innodb_flush_log_at_trx_commit =1. Detta är dyrt eftersom det kräver mer processorkraft när MySQL anropar fsync()-funktionen när den commits, och prestanda kan vara diskbunden vid högt antal skrivningar. Men att använda RAID med batteribackup-cache sparar din disk-I/O. Dessutom har MySQL i sig förbättrats med binär logggruppsbekräftelse, men att fortfarande använda en backupcache kan spara vissa disksynkroniseringar.
- Utnyttja parallell replikering eller flertrådig slavreplikering. Detta kan hjälpa dina slavar att bli mer presterande och undviker slavfördröjningar mot befälhavaren. Du vill inte att din automatiska failover ska inträffa när mastern inte alls kan nås via antingen ssh- eller tcp-anslutning, eller om den stötte på ett diskfel och dina slavar släpar efter. Det kan leda till dataförlust.
- När du utför en online- eller manuell failover är det bäst att du gör det under perioder utan högtrafik för att undvika oväntade missöden som kan leda till dataförlust. Eller för att undvika tidskrävande sökningar som greppar igenom dina binära loggar medan det pågår mycket aktivitet.
MHA säger att APP inte körs, eller failover fungerar inte. Vad ska jag göra?
Att köra kontroller med det inbyggda skriptet masterha_check_status kommer att kontrollera om skriptet mastreha_manager körs. Annars får du ett felmeddelande som nedan:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf app1 is stopped(2:NOT_RUNNING).Det finns dock vissa fall där du kan få NOT_RUNNING även när masterha_manager är igång. Detta kan bero på privilegiet för den ssh_user du ställer in, eller så kör du masterha_manager med en annan systemanvändare, eller så har ssh-användaren stött på en nekad behörighet.
Åtgärningar/upplösning:
MHA kommer att använda ssh_user definieras i konfigurationen om det anges. Annars kommer den att använda den nuvarande systemanvändaren som du använder för att anropa MHA-kommandon. När du kör skriptet masterha_check_status till exempel måste du se till att masterha_manager körs med samma användare som anges i ssh_user i din konfigurationsfil, eller användaren som kommer att gränssnitta med de andra databasnoderna i klustret. Du måste se till att den har lösenordslösa SSH-nycklar utan lösenordsfras så att MHA inte har några problem när du upprättar anslutning till noderna som MHA övervakar.
Observera att du behöver ssh_user för att ha tillgång till följande:
- Kan läsa binär- och reläloggarna för MySQL-noderna som MHA övervakar
- Måste ha tillgång till MHA-övervakningsloggarna. Kolla in dessa parametrar i MHA:master_binlog_dir, manager_workdir och manager_log
- Måste ha tillgång till MHA-konfigurationsfilen. Detta är också mycket viktigt. Under en failover, när den är klar med failover, kommer den att försöka uppdatera konfigurationsfilen och ta bort posten för den döda mastern. Om konfigurationsfilen inte tillåter ssh_user eller OS-användaren du använder för närvarande, kommer den inte att uppdatera konfigurationsfilen, vilket leder till en eskalering av problemet om katastrofen inträffar igen.
Kandidatmästarfördröjningar, hur man tvingar fram och undviker misslyckad misslyckande
Med hänvisning till MHA:s wiki, som standard, om en slav ligger bakom master mer än 100 MB reläloggar (=behöver använda mer än 100 MB reläloggar), väljer MHA inte slaven som ny master eftersom det tar för lång tid att återställa .
Åtgärningar/upplösning
I MHA kan detta åsidosättas genom att ställa in parametern check_repl_delay=0. Under en failover ignorerar MHA replikeringsfördröjning vid val av en ny master och kommer att exekvera saknade transaktioner. Det här alternativet är användbart när du ställer in candidate_master=1 på en specifik värd och du vill vara säker på att värden kan vara ny master.
Du kan också integrera med pt-heartbeat för att uppnå noggrannhet av slavlag (se det här inlägget och det här). Men detta kan också lindras med parallellreplikering eller flertrådiga replikeringsslavar, som finns sedan MySQL 5.6 eller, med MariaDB 10 - som hävdar att de har ett uppsving med 10x förbättring av parallell replikering och flertrådiga slavar. Detta kan hjälpa dina slavar att replikera snabbare.
MHA-lösenord är exponerade
Att säkra eller kryptera lösenorden är inte något som hanteras av 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