MySQL-replicatie is een zeer populaire manier om zeer beschikbare databaselagen te bouwen. Het is zeer bekend, getest en robuust. Het is echter niet zonder beperkingen. Een daarvan is zeker het feit dat het slechts één "toegangspunt" gebruikt - je hebt een toegewijde server in de topologie, de master, en het is het enige knooppunt in het cluster waarnaar je schrijfbewerkingen kunt uitgeven. Dit leidt tot ernstige gevolgen - de master is het enige storingspunt en als het faalt, kan er geen schrijven worden uitgevoerd door de toepassing. Het is geen verrassing dat er veel werk is gestoken in het ontwikkelen van tools die de impact van een masterverlies zouden verminderen. Natuurlijk, er zijn discussies over hoe het onderwerp moet worden benaderd, is de geautomatiseerde failover beter dan de handmatige of niet. Uiteindelijk is dit een zakelijke beslissing die u moet nemen, maar mocht u besluiten het automatiseringspad te volgen, dan zult u op zoek gaan naar de tools om u daarbij te helpen. Een van de tools die nog steeds erg populair is, is MHA (Master High Availability). Hoewel het misschien niet meer actief wordt onderhouden, is het nog steeds in een stabiele vorm en zijn enorme populariteit maakt het nog steeds de ruggengraat van de hoog beschikbare MySQL-replicatie-setups. Wat zou er echter gebeuren als de MHA zelf niet meer beschikbaar zou zijn? Kan het een single point of failure worden? Is er een manier om te voorkomen dat het gebeurt? In deze blogpost zullen we enkele scenario's bekijken.
Allereerst, als u van plan bent MHA te gebruiken, zorg er dan voor dat u de nieuwste versie van de repo gebruikt. Gebruik geen binaire releases omdat deze niet alle fixes bevatten. De installatie is vrij eenvoudig. MHA bestaat uit twee delen, manager en node. Node moet worden geïmplementeerd op uw databaseservers. Manager wordt samen met node op een aparte host geïmplementeerd. Dus databaseservers:knooppunt, beheerhost:manager en knooppunt.
Het is vrij eenvoudig om MHA te compileren. Ga naar de GitHub en kloon opslagplaatsen.
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node
Dan draait het allemaal om:
perl Makefile.PL
make
make installMogelijk moet u enkele perl-afhankelijkheden installeren als u niet alle vereiste pakketten al hebt geïnstalleerd. In ons geval, op Ubuntu 16.04, moesten we het volgende installeren:
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"Nadat u MHA hebt geïnstalleerd, moet u het configureren. We zullen hier niet op details ingaan, er zijn veel bronnen op internet die dit deel behandelen. Een voorbeeldconfiguratie (zeker niet-productie) kan er als volgt uitzien:
[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=1De volgende stap is om te kijken of alles werkt en hoe MHA de replicatie ziet:
[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).Nou, het is gecrasht. Dit komt omdat MHA probeert de MySQL-versie te ontleden en er geen koppeltekens in verwacht. Gelukkig is de oplossing gemakkelijk te vinden:https://github.com/yoshinorim/mha4mysql-manager/issues/116.
Nu hebben we MHA klaar voor gebruik.
[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..Zoals u kunt zien, bewaakt MHA onze replicatietopologie en controleert of het hoofdknooppunt beschikbaar is of niet. Laten we een paar scenario's bekijken.
Scenario 1 - MHA gecrasht
Laten we aannemen dat MHA niet beschikbaar is. Hoe beïnvloedt dit het milieu? Aangezien MHA verantwoordelijk is voor het bewaken van de gezondheid van de master en het activeren van failover, zal dit uiteraard niet gebeuren wanneer MHA niet beschikbaar is. Mastercrash wordt niet gedetecteerd, failover zal niet plaatsvinden. Het probleem is dat u niet echt meerdere MHA-instanties tegelijkertijd kunt uitvoeren. Technisch gezien kun je het doen, hoewel MHA zal klagen over het vergrendelingsbestand:
[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.Het zal echter starten en het zal proberen de omgeving te bewaken. Het probleem is wanneer ze allebei acties op het cluster beginnen uit te voeren. Erger zou zijn als ze besluiten om verschillende slaves te gebruiken als master-kandidaat en de failover tegelijkertijd wordt uitgevoerd (MHA gebruikt een lock-bestand dat voorkomt dat volgende failovers plaatsvinden, maar als alles tegelijkertijd gebeurt, en het gebeurde in onze testen, is deze beveiligingsmaatregel niet voldoende).
Helaas is er geen ingebouwde manier om MHA op een zeer beschikbare manier uit te voeren. De eenvoudigste oplossing is om een script te schrijven dat zou testen of MHA actief is en zo niet, het te starten. Een dergelijk script zou moeten worden uitgevoerd vanuit cron of geschreven in de vorm van een daemon, als 1 minuut granulariteit van cron niet genoeg is.
Scenario 2 - MHA Manager-knooppunt verbroken netwerkverbinding met de master
Laten we eerlijk zijn, dit is echt een slechte situatie. Zodra MHA geen verbinding kan maken met de master, zal het proberen een failover uit te voeren. De enige uitzondering is als secundair_check_script is gedefinieerd en het geverifieerd heeft dat de master actief is. Het is aan de gebruiker om precies te definiëren welke acties MHA moet uitvoeren om de status van de master te verifiëren - het hangt allemaal af van de omgeving en de exacte installatie. Een ander zeer belangrijk script om te definiëren is master_ip_failover_script - dit wordt uitgevoerd bij een failover en moet onder andere worden gebruikt om ervoor te zorgen dat de oude master niet verschijnt. Als je toevallig toegang hebt tot extra manieren om de oude meester te bereiken en te stoppen, is dat echt geweldig. Het kunnen tools voor beheer op afstand zijn, zoals Integrated Lights-out, het kan toegang zijn tot beheersbare stopcontacten (waar u de server gewoon kunt uitschakelen), het kan toegang zijn tot de CLI van de cloudprovider, waardoor het mogelijk wordt om de virtuele instantie te stoppen . Het is van het grootste belang om de oude meester te stoppen - anders kan het gebeuren dat je, nadat het netwerkprobleem is verholpen, twee beschrijfbare knooppunten in het systeem hebt, wat een perfecte oplossing is voor het gespleten brein, een toestand waarin gegevens verschilden tussen twee delen van hetzelfde cluster.
Zoals u kunt zien, kan MHA de MySQL-failover redelijk goed aan. Het vereist absoluut een zorgvuldige configuratie en je zult externe scripts moeten schrijven, die zullen worden gebruikt om de oude meester te doden en ervoor te zorgen dat het gespleten brein niet zal plaatsvinden. Dat gezegd hebbende, raden we nog steeds aan om meer geavanceerde tools voor failoverbeheer te gebruiken, zoals Orchestrator of ClusterControl, die geavanceerdere analyses van de replicatietopologiestatus kunnen uitvoeren (bijvoorbeeld door slaves of proxy's te gebruiken om de beschikbaarheid van de master te beoordelen) en die zijn en in de toekomst zal worden gehandhaafd. Als u geïnteresseerd bent in hoe ClusterControl failover uitvoert, nodigen wij u uit om deze blogpost over het failoverproces in ClusterControl te lezen. U kunt ook leren hoe ClusterControl samenwerkt met ProxySQL en zo een soepele, transparante failover voor uw toepassing levert. U kunt ClusterControl altijd testen door het gratis te downloaden.