Top almindelige problemer med MHA og hvordan man løser dem

En inkonsekvent klynge er virkelig dårlig, især når automatisk failover er aktiveret. I dette tilfælde kan failover ikke fortsætte, da det registrerer en dublet indtastning for primærnøgle '12583545 '.

Retninger/opløsning:

Der er flere ting, du kan gøre her for at undgå inkonsekvent tilstand af din klynge.

• Aktiver tabsfri semisynkron replikering. Tjek denne eksterne blog, som er en god måde at lære, hvorfor du bør overveje at bruge semi-synkronisering i en standard MySQL-replikeringsopsætning.
• Kør konstant en kontrolsum mod din master-slave-klynge. Du kan bruge pt-table-checksum og køre det en gang om ugen eller måneden afhængigt af, hvor konstant din tabel opdateres. Bemærk, at pt-table-checksum kan tilføje overhead til din databasetrafik.
• Brug GTID-baseret replikering. Selvom dette ikke vil påvirke problemet i sig selv. GTID-baseret replikering hjælper dig dog med at bestemme fejlagtige transaktioner, især de transaktioner, der blev kørt direkte på slaven. En anden fordel ved dette er, at det er nemmere at administrere GTID-baseret replikering, når du skal skifte mastervært i replikering.

Hardwarefejl på masteren, men slaverne har ikke indhentet det endnu

En af de mange grunde til, at du vil investere i automatisk failover, er en hardwarefejl på masteren. For nogle opsætninger kan det være mere ideelt kun at udføre automatisk failover, når masteren støder på en hardwarefejl. Den typiske tilgang er at give besked ved at sende en alarm - hvilket kan betyde, at man vækker vagtpersonen midt om natten og lader personen bestemme, hvad han skal gøre. Denne type tilgang udføres på Github eller endda Facebook. En hardwarefejl, især hvis volumen, hvor dine binlogs og databibliotek findes, er påvirket, kan rode med din failover, især hvis de binære logfiler er gemt på den fejlbehæftede disk. Ved design vil MHA forsøge at gemme binære logfiler fra den nedbrudte master, men dette kan ikke være muligt, hvis disken fejlede. Et muligt scenarie, der kan ske, er, at serveren ikke kan nås via SSH. MHA kan ikke gemme binære logfiler og skal udføre failover uden at anvende binære loghændelser, der kun findes på den nedbrudte master. Dette vil resultere i tab af de seneste data, især hvis ingen slave har indhentet masteren.

Retninger/opløsning

Som et af MHA's use cases, anbefales det at bruge semi-synkron replikering, da det i høj grad reducerer risikoen for sådanne datatab. Det er vigtigt at bemærke, at enhver skrivning, der går til masteren, skal sikre, at slaver har modtaget de seneste binære loghændelser, før de synkroniseres til disken. MHA kan anvende begivenhederne på alle andre slaver, så de kan være i overensstemmelse med hinanden.

Derudover er det også bedre at køre en backup-stream af dine binære logfiler til gendannelse af katastrofer, hvis hoveddiskenheden har fejlet. Hvis serveren stadig er tilgængelig via SSH, kan det stadig fungere at pege den binære logsti til backupstien til din binære log, så failover og slavegendannelse kan stadig gå videre. På denne måde kan du undgå tab af data.

VIP (Virtual IP) Failover forårsager split-hjerne

MHA håndterer som standard ikke nogen VIP-administration. Det er dog nemt at inkorporere dette med MHAs konfiguration og tildele hooks i overensstemmelse med, hvad du ønsker, at MHA skal gøre under failoveren. Du kan opsætte dit eget script og tilslutte det til parametrene master_ip_failover_script eller master_ip_online_change_script. Der er også eksempler på scripts, som er placeret i mappen /samples/scripts/. Men lad os gå tilbage til hovedproblemet, og det er den splittede hjerne under failover.

Under en automatisk failover, når dit script med VIP-administration er påkaldt og udført, vil MHA gøre følgende:kontrollere status, fjerne (eller stoppe) den gamle VIP og derefter gentildele den nye VIP til den nye master. Et typisk eksempel på split brain er, når en master identificeres som død på grund af et netværksproblem, men faktisk er slaveknudepunkter stadig i stand til at oprette forbindelse til masteren. Dette er en falsk positiv og fører ofte til datainkonsistens på tværs af databaserne i opsætningen. Indgående klientforbindelser ved hjælp af VIP vil blive sendt til den nye master. Mens der på den anden side kan være lokale forbindelser kørende på gammel master, som formodes at være død. De lokale forbindelser kunne bruge unix-socket eller localhost for at mindske netværkshop. Dette kan få data til at drive mod den nye master og resten af ​​dens slaver, da data fra den gamle master ikke vil blive replikeret ind i slaverne.

Retninger/opløsning:

Som nævnt tidligere kan nogle foretrække at undgå automatisk failover, medmindre kontrollerne har fastslået, at masteren er helt nede (som hardwarefejl), dvs. selv slaveknuderne er ikke i stand til at nå den. Ideen er, at en falsk positiv kan være forårsaget af en netværksfejl mellem MHA-nodecontrolleren og masteren, så et menneske kan i dette tilfælde være bedre egnet til at træffe en beslutning om, hvorvidt der skal failover eller ej.

Ved håndtering af falske alarmer har MHA en parameter kaldet secondary_check_script. Værdien placeret her kan være dine brugerdefinerede scripts, eller du kan bruge det indbyggede script /usr/local/bin/masterha_secondary_check som sendes sammen med MHA Manager-pakken. Dette tilføjer ekstra kontroller, som faktisk er den anbefalede tilgang til at undgå falske positiver. I eksemplet nedenfor fra min egen opsætning bruger jeg det indbyggede script 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=3306 

I ovenstående eksempel vil MHA Manager lave en løkke baseret på listen over slaveknuder (specificeret ved -s argument), som vil kontrollere forbindelsen mod MySQL master (192.168.10.60) vært. Bemærk, at disse slaveknudepunkter i eksemplet kan være nogle eksterne fjernknudepunkter, der kan etablere en forbindelse til databasenoderne i klyngen. Dette er en anbefalet tilgang, især til de opsætninger, hvor MHA Manager kører på et andet datacenter eller andet netværk end databasenoderne. Følgende sekvens nedenfor illustrerer, hvordan det skrider frem med kontrollerne:

• Fra MHA-værten -> kontroller TCP-forbindelsen til 1. slavenode (IP:192.168.10.50). Lad os kalde dette som forbindelse A. Så kontrollerer vi fra slaveknuden TCP-forbindelsen til masternoden (192.168.10.60). Lad os kalde denne forbindelse B.

Hvis "Forbindelse A" var vellykket, men "Forbindelse B" var mislykket på begge ruter, masterha_secondary_check script afsluttes med returkode 0, og MHA Manager beslutter, at MySQL-master virkelig er død, og vil starte failover. Hvis "Forbindelse A" mislykkedes, masterha_secondary_check afsluttes med returkode 2 og MHA Manager gætter på, at der er et netværksproblem, og den starter ikke failover. Hvis "Forbindelse B" lykkedes, masterha_secondary_check afsluttes med returkode 3, og MHA Manager forstår, at MySQL-masterserveren faktisk er i live, og starter ikke failover.

Et eksempel på, hvordan den reagerer under failover baseret 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 0 

En anden ting at tilføje er at tildele en værdi til parameteren shutdown_script. Dette script er især nyttigt, hvis du skal implementere et ordentligt STONITH- eller nodehegn, så det ikke rejser sig fra de døde. Dette kan undgå datainkonsistens.

Til sidst skal du sikre dig, at MHA Manager er bosat inden for det samme lokale netværk sammen med klyngen noderne, da det mindsker muligheden for netværksafbrydelser, især forbindelsen fra MHA Manager til databasenoderne.

Undgå SPOF i MHA

MHA kan gå ned af forskellige årsager, og desværre er der ingen indbygget funktion til at løse dette, dvs. High Availability for MHA. Men som vi har diskuteret i vores tidligere blog "Master High Availability Manager (MHA) Has Crashed! What Do I Do Now?", er der en måde at undgå SPOF for MHA.

Retninger/opløsning:

Du kan udnytte Pacemaker til at oprette aktive/standby noder, der håndteres af cluster resource manager (crm). Alternativt kan du oprette et script for at kontrollere MHA-managerknudepunktets tilstand. For eksempel kan du klargøre en standby-knude, som aktivt tjekker MHA-managerknuden ved at ssh'ing for at køre det indbyggede script masterha_check_status ligesom nedenfor:

[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING). 

så lav noget nodehegn, hvis controlleren er borket. Du kan også udvide MHA-værktøjet med et hjælpescript, der kører via cron-job og overvåge systemprocessen for masterha_manager-scriptet og genskabe det, hvis processen er død.

Datatab under failover

MHA er afhængig af den traditionelle asynkrone replikering. Selvom det understøtter semi-synkronisering, er semi-synkronisering stadig afhængig af asynkron replikering. I denne type miljø kan datatab ske efter en failover. Når din database ikke er konfigureret korrekt og bruger en gammeldags tilgang til replikering, så kan det være en smerte, især når det drejer sig om datakonsistens og tabte transaktioner.

En anden vigtig ting at bemærke med tab af data med MHA er, når GTID bruges uden semi-synkronisering aktiveret. MHA med GTID vil ikke oprette forbindelse via ssh til masteren, men vil prøve at synkronisere de binære logfiler til node-gendannelse med slaverne først. Dette kan potentielt føre til mere datatab end sammenlignet med MHA non-GTID med semi-sync ikke aktiveret.

Retninger/opløsning

Når du udfører automatisk failover, skal du bygge en liste over scenarier, når du forventer, at din MHA vil failover. Da MHA beskæftiger sig med master-slave-replikering, er vores råd til dig for at undgå datatab følgende:

• Aktiver tabsfri semi-synkroniseringsreplikering (findes i version MySQL 5.7)
• Brug GTID-baseret replikering. Selvfølgelig kan du bruge den traditionelle replikering ved at bruge binlogs x &y koordinater. Det gør dog tingene sværere og mere tidskrævende, når du skal finde en specifik binær logindgang, der ikke blev anvendt på slaven. Med GTID i MySQL er det derfor nemmere at opdage fejlagtige transaktioner.
• For ACID-kompatibilitet af din MySQL master-slave-replikering skal du aktivere disse specifikke variabler:sync_binlog =1, innodb_flush_log_at_trx_commit =1. Dette er dyrt, da det kræver mere processorkraft, når MySQL kalder fsync()-funktionen, når den commiter, og ydeevne kan være diskbundet i tilfælde af højt antal skrivninger. Men brug af RAID med batteri-backup cache gemmer din disk I/O. Derudover er MySQL i sig selv blevet forbedret med binær log gruppe commit, men stadig brug af en backup cache kan gemme nogle disksynkroniseringer.
• Udnyt parallel replikering eller multi-threaded slave replikering. Dette kan hjælpe dine slaver med at blive mere performante og undgår slavelags mod mesteren. Du ønsker ikke, at din automatiske failover skal ske, når masteren slet ikke er tilgængelig via enten ssh- eller tcp-forbindelse, eller hvis den stødte på en diskfejl, og dine slaver halter bagud. Det kan føre til tab af data.
• Når du udfører en online eller manuel failover, er det bedst, at du udfører det i ikke-spidsbelastningsperioder for at undgå uventede uheld, der kan føre til datatab. Eller for at undgå tidskrævende søgninger, der trænger gennem dine binære logfiler, mens der foregår en masse aktivitet.

MHA siger, at APP ikke kører, eller failover virker ikke. Hvad skal jeg gøre?

Kørsel af kontroller ved hjælp af det indbyggede script masterha_check_status vil kontrollere, om mastreha_manager scriptet kører. Ellers får du en fejl som nedenfor:

[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf                                                                                                                       app1 is stopped(2:NOT_RUNNING). 

Der er dog visse tilfælde, hvor du muligvis får NOT_RUNNING, selv når masterha_manager løber. Dette kan skyldes privilegiet for den ssh_user, du har angivet, eller du kører masterha_manager med en anden systembruger, eller ssh-brugeren stødte på en tilladelse nægtet.

Retninger/opløsning:

MHA vil bruge ssh_user defineret i konfigurationen, hvis det er angivet. Ellers vil bruge den aktuelle systembruger, som du bruger til at kalde MHA-kommandoerne. Når du kører scriptet masterha_check_status for eksempel skal du sikre dig, at masterha_manager kører med den samme bruger, som er angivet i ssh_user i din konfigurationsfil, eller den bruger, der vil interface med de andre databasenoder i klyngen. Du skal sikre dig, at den har adgangskodeløse SSH-nøgler uden adgangskodesætning, så MHA vil ikke have nogen problemer, når der etableres forbindelse til de noder, som MHA overvåger.

Bemærk, at du har brug for ssh_user for at have adgang til følgende:

• Kan læse de binære og relælogfiler for de MySQL-noder, som MHA overvåger
• Skal have adgang til MHA-overvågningsloggene. Tjek disse parametre i MHA:master_binlog_dir, manager_workdir og manager_log
• Skal have adgang til MHA-konfigurationsfilen. Dette er også meget vigtigt. Under en failover, når den er færdig med failover, vil den forsøge at opdatere konfigurationsfilen og fjerne indtastningen af ​​den døde master. Hvis konfigurationsfilen ikke tillader ssh_user eller den OS-bruger, du bruger i øjeblikket, opdaterer den ikke konfigurationsfilen, hvilket fører til en eskalering af problemet, hvis katastrofen rammer igen.

Kandidat Master Lags, hvordan man tvinger og undgår mislykket failover

Med henvisning til MHA's wiki, som standard, hvis en slave står bag master mere end 100MB relælogfiler (=skal anvende mere end 100MB relælogfiler), vælger MHA ikke slaven som ny master, fordi det tager for lang tid at genoprette .

Retninger/opløsning

I MHA kan dette tilsidesættes ved at indstille parameteren check_repl_delay=0. Under en failover ignorerer MHA replikeringsforsinkelse ved valg af en ny master og vil udføre manglende transaktioner. Denne mulighed er nyttig, når du indstiller candidate_master=1 på en specifik vært, og du vil sikre dig, at værten kan være ny master.

Du kan også integrere med pt-heartbeat for at opnå nøjagtighed af slavelag (se dette indlæg og dette). Men dette kan også afhjælpes med parallel replikering eller multi-threaded replikeringsslaver, der er til stede siden MySQL 5.6 eller, med MariaDB 10 - hævder at have et boost med 10x forbedring i parallel replikering og multi-threaded slaver. Dette kan hjælpe dine slaver til at replikere hurtigere.

MHA-adgangskoder er afsløret

Sikring eller kryptering af adgangskoder er ikke noget, der håndteres af 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