Master High Availability Manager (MHA) er styrtet! Hvad gør jeg nu?

MySQL-replikering er en meget populær måde at bygge meget tilgængelige databaselag på. Den er meget kendt, testet og robust. Det er dog ikke uden begrænsninger. En af dem er helt klart det faktum, at det kun bruger ét "indgangspunkt" - du har en dedikeret server i topologien, masteren, og det er den eneste node i klyngen, som du kan skrive til. Dette fører til alvorlige konsekvenser - masteren er det eneste fejlpunkt, og hvis det mislykkes, kan applikationen ikke udføre nogen skrivning. Det er ikke en overraskelse, at der er lagt meget arbejde i at udvikle værktøjer, som ville reducere virkningen af ​​et mastertab. Selvfølgelig er der diskussioner om, hvordan man griber emnet an, er den automatiserede failover bedre end den manuelle eller ej. Til sidst er dette en forretningsbeslutning at tage, men hvis du beslutter dig for at følge automatiseringsstien, vil du lede efter værktøjerne til at hjælpe dig med at opnå det. Et af værktøjerne, som stadig er meget populært, er MHA (Master High Availability). Selvom den måske ikke vedligeholdes aktivt længere, er den stadig i en stabil form, og dens enorme popularitet gør den stadig til rygraden i de høje tilgængelige MySQL-replikeringsopsætninger. Hvad ville der dog ske, hvis selve MHA blev utilgængelig? Kan det blive et enkelt fiasko? Er der en måde at forhindre det i at ske? I dette blogindlæg vil vi tage et kig på nogle af scenarierne.

Først og fremmest, hvis du planlægger at bruge MHA, skal du sørge for at bruge den nyeste version fra repoen. Brug ikke binære udgivelser, da de ikke indeholder alle rettelserne. Installationen er ret enkel. MHA består af to dele, leder og node. Node skal installeres på dine databaseservere. Manager vil blive installeret på en separat vært sammen med node. Altså databaseservere:node, administrationsvært:manager og node.

Det er ret nemt at kompilere MHA. Gå til GitHub og klon depoter.

https://github.com/yoshinorim/mha4mysql-manager

https://github.com/yoshinorim/mha4mysql-node

Så handler det om:

perl Makefile.PL
make
make install

Du skal muligvis installere nogle perl-afhængigheder, hvis du ikke allerede har alle de nødvendige pakker installeret. I vores tilfælde, på Ubuntu 16.04, skulle vi installere følgende:

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 installeret MHA, skal du konfigurere den. Vi vil ikke gå ind i detaljer her, der er mange ressourcer på internettet, som dækker denne del. En eksempelkonfiguration (afgjort ikke-produktion) kan se sådan ud:

[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=1

Næste trin vil være at se, om alt fungerer, og hvordan MHA ser replikationen:

[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å, det styrtede ned. Dette skyldes, at MHA forsøger at parse MySQL-version, og den forventer ikke bindestreger i den. Heldigvis er rettelsen let at finde:https://github.com/yoshinorim/mha4mysql-manager/issues/116.

Nu har vi MHA klar til arbejde.

[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, overvåger MHA vores replikeringstopologi og tjekker, om masternoden er tilgængelig eller ej. Lad os overveje et par scenarier.

Scenarie 1 - MHA gik ned

Lad os antage, at MHA ikke er tilgængelig. Hvordan påvirker dette miljøet? Da MHA er ansvarlig for at overvåge masterens helbred og udløse failover, vil dette naturligvis ikke ske, når MHA er nede. Master crash vil ikke blive opdaget, failover vil ikke ske. Problemet er, at du ikke rigtig kan køre flere MHA-instanser på samme tid. Teknisk set kan du gøre det, selvom MHA vil klage over låsefilen:

[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.

Den starter dog, og den vil forsøge at overvåge miljøet. Problemet er, når de begge begynder at udføre handlinger på klyngen. Værre tilfælde ville være, hvis de beslutter sig for at bruge forskellige slaver, da masterkandidaten og failover vil blive udført på samme tid (MHA bruger en låsefil, som forhindrer efterfølgende failovers i at ske, men hvis alt sker på samme tid, og det skete i vores tests, er denne sikkerhedsforanstaltning ikke nok).

Desværre er der ingen indbygget måde at køre MHA på en meget tilgængelig måde. Den mest enkle løsning vil være at skrive et script, der tester, om MHA kører, og hvis ikke, start det. Et sådant script skal udføres fra cron eller skrives i form af en dæmon, hvis 1 minuts granularitet af cron ikke er nok.

Scenario 2 - MHA Manager Node mistede netværksforbindelse til masteren

Lad os være ærlige, det er en rigtig dårlig situation. Så snart MHA ikke kan oprette forbindelse til masteren, vil den forsøge at udføre en failover. Den eneste undtagelse er, hvis secondary_check_script er defineret, og det bekræfter, at masteren er i live. Det er op til brugeren at definere præcis, hvilke handlinger MHA skal udføre for at verificere masters status - det hele afhænger af miljøet og den nøjagtige opsætning. Et andet meget vigtigt script at definere er master_ip_failover_script - dette udføres ved failover, og det bør blandt andet bruges til at sikre, at den gamle master ikke dukker op. Hvis du tilfældigvis har adgang til yderligere måder at nå og stoppe den gamle mester på, er det virkelig fantastisk. Det kan være fjernstyringsværktøjer som Integrated Lights-out, det kan være adgang til håndterbare strømstik (hvor man bare kan slukke for serveren), det kan være adgang til cloududbyderens CLI, som vil gøre det muligt at stoppe den virtuelle instans. . Det er yderst vigtigt at stoppe den gamle mester - ellers kan det ske, at du, efter at netværksproblemet er væk, vil ende med to skrivbare noder i systemet, hvilket er en perfekt løsning til den splittede hjerne, en tilstand, hvor data divergeret mellem to dele af den samme klynge.

Som du kan se, kan MHA håndtere MySQL failover ret godt. Det kræver bestemt omhyggelig konfiguration, og du bliver nødt til at skrive eksterne scripts, som vil blive brugt til at dræbe den gamle mester og sikre, at den splittede hjerne ikke vil ske. Når det er sagt, vil vi stadig anbefale at bruge mere avancerede failover-styringsværktøjer som Orchestrator eller ClusterControl, som kan udføre mere avanceret analyse af replikeringstopologitilstanden (f.eks. ved at bruge slaver eller proxyer til at vurdere masterens tilgængelighed), og som er og vil blive vedligeholdt i fremtiden. Hvis du er interesseret i at lære, hvordan ClusterControl udfører failover, vil vi gerne invitere dig til at læse dette blogindlæg om failover-processen i ClusterControl. Du kan også lære, hvordan ClusterControl interagerer med ProxySQL og leverer jævn, gennemsigtig failover til din applikation. Du kan altid teste ClusterControl ved at downloade det gratis.