In onze vorige blogs hebben we MHA besproken als een failover-tool die wordt gebruikt in MySQL-master-slave-opstellingen. Vorige maand hebben we ook geblogd over hoe om te gaan met MHA toen het crashte. Vandaag zullen we de belangrijkste problemen bekijken die DBA's gewoonlijk tegenkomen met MHA, en hoe u ze kunt oplossen.
Een korte introductie tot MHA (Master High Availability)
MHA staat voor (Master High Availability) is nog steeds relevant en wordt tegenwoordig veel gebruikt, vooral in master-slave-opstellingen op basis van niet-GTID-replicatie. MHA presteert goed als failover of master-switch, maar het heeft enkele valkuilen en beperkingen. Zodra MHA een master-failover en slave-promotie uitvoert, kan het de failover-bewerking van de database automatisch binnen ~30 seconden voltooien, wat acceptabel kan zijn in een productieomgeving. MHA kan de consistentie van gegevens waarborgen. Dit alles zonder prestatieverlies en er zijn geen extra aanpassingen of wijzigingen aan uw bestaande implementaties of instellingen vereist. Afgezien hiervan is MHA bovenop Perl gebouwd en is het een open-source HA-oplossing - dus het is relatief eenvoudig om helpers te creëren of de tool uit te breiden in overeenstemming met de door u gewenste setup. Bekijk deze presentatie voor meer informatie.
MHA-software bestaat uit twee componenten, u moet een van de volgende pakketten installeren in overeenstemming met de topologierol:
MHA-managerknooppunt =MHA-manager (manager)/MHA-knooppunt (gegevensknooppunt)
Master/Slave-knooppunten =MHA-knooppunt (gegevensknooppunt)
MHA Manager is de software die de failover beheert (automatisch of handmatig), beslissingen neemt over waar en wanneer een failover moet worden uitgevoerd en slave-herstel beheert tijdens de promotie van de kandidaat-master voor het toepassen van differentiële relaislogboeken. Als de masterdatabase uitvalt, coördineert MHA Manager met de MHA Node-agent, aangezien het differentiële relaislogboeken toepast op de slaves die niet de nieuwste binloggebeurtenissen van de master hebben. De MHA Node-software is een lokale agent die uw MySQL-instantie bewaakt en de MHA Manager in staat stelt om relaislogboeken van de slaves te kopiëren. Een typisch scenario is dat wanneer de kandidaat-master voor failover momenteel achterblijft en MHA detecteert dat deze niet over de nieuwste relaislogboeken beschikt. Daarom wacht het op zijn mandaat van MHA Manager terwijl het zoekt naar de laatste slaaf die de binlog-gebeurtenissen bevat en ontbrekende gebeurtenissen van de slaaf kopieert met scp en deze op zichzelf toepast.
Merk echter op dat MHA momenteel niet actief wordt onderhouden, maar de huidige versie zelf is stabiel en kan "goed genoeg" zijn voor productie. Je kunt je stem nog steeds via github echoën om een aantal problemen op te lossen of om patches voor de software aan te brengen.
Belangrijkste veelvoorkomende problemen
Laten we nu eens kijken naar de meest voorkomende problemen die een DBA tegenkomt bij het gebruik van MHA.
Slave loopt achter, niet-interactieve/geautomatiseerde failover is mislukt!
Dit is een typisch probleem waardoor automatische failover wordt afgebroken of mislukt. Dit klinkt misschien eenvoudig, maar het wijst niet op slechts één specifiek probleem. Slavische vertraging kan verschillende redenen hebben:
- Schijfproblemen op de kandidaat-master waardoor deze schijf-I/O gebonden is om lees- en schrijfbewerkingen te verwerken. Het kan ook leiden tot gegevenscorruptie als het niet wordt verholpen.
- Slechte zoekopdrachten worden gerepliceerd, vooral tabellen die geen primaire sleutels of geclusterde indexen hebben.
- hoge serverbelasting.
- Koude server en server is nog niet opgewarmd
- Onvoldoende serverbronnen. Het is mogelijk dat uw slave te weinig geheugen of serverbronnen heeft tijdens het repliceren van zeer intensieve schrijf- of leesbewerkingen.
Die kunnen van tevoren worden beperkt als u uw database goed bewaakt. Een voorbeeld met betrekking tot slaafvertragingen in MHA is weinig geheugen bij het dumpen van een groot binair logbestand. Als voorbeeld hieronder is een master gemarkeerd als dood en moet deze een niet-interactieve/automatische failover uitvoeren. Omdat de kandidaat-master echter achterbleef en de logs moet toepassen die nog niet zijn uitgevoerd door de replicatiethreads, zal MHA de meest up-to-date of nieuwste slave lokaliseren, aangezien het zal proberen een slave te herstellen tegen de oudste degenen. Vandaar dat, zoals je hieronder kunt zien, het geheugen tijdens het uitvoeren van een slave-herstel te laag werd:
[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.De failover is dus mislukt. Dit voorbeeld hierboven laat zien dat knooppunt 192.168.10.70 de meest bijgewerkte relaislogboeken bevat. In dit voorbeeldscenario is knooppunt 192.168.10.70 echter ingesteld als no_master omdat het weinig geheugen heeft. Terwijl het de slaaf 192.168.10.50 probeert te herstellen, mislukt het!
Oplossingen/oplossing:
Dit scenario illustreert iets heel belangrijks. Er moet een geavanceerde monitoringomgeving worden opgezet! U kunt bijvoorbeeld een achtergrond- of daemonscript uitvoeren dat de replicatiestatus bewaakt. U kunt een item toevoegen via een cronjob. Voeg bijvoorbeeld een item toe met behulp van het ingebouwde script masterha_check_repl :
/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnfof maak een achtergrondscript dat dit script aanroept en met een interval uitvoert. U kunt de report_script-optie gebruiken om een waarschuwingsmelding in te stellen voor het geval deze niet aan uw vereisten voldoet, bijvoorbeeld als de slaaf ongeveer 100 seconden achterblijft tijdens een hoge piekbelasting. U kunt ook monitoringplatforms zoals ClusterControl gebruiken om u meldingen te sturen op basis van de statistieken die u wilt controleren.
Houd er daarnaast rekening mee dat in het voorbeeldscenario de failover is mislukt vanwege een onvoldoende geheugen. U kunt overwegen ervoor te zorgen dat al uw knooppunten voldoende geheugen en de juiste grootte van binaire logbestanden hebben, aangezien ze de binlog zouden moeten dumpen voor een slave-herstelfase.
Inconsistente slaaf, toepassen van diffs mislukt!
Met betrekking tot slave-lag, aangezien MHA zal proberen om relaislogboeken te synchroniseren met een kandidaat-master, moet u ervoor zorgen dat uw gegevens gesynchroniseerd zijn. Zeg voor een voorbeeld hieronder:
...
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]Een inconsistent cluster is erg slecht, vooral wanneer automatische failover is ingeschakeld. In dit geval kan de failover niet doorgaan omdat er een dubbele vermelding wordt gedetecteerd voor de primaire sleutel '12583545 '.
Oplossingen/oplossing:
Er zijn meerdere dingen die u hier kunt doen om een inconsistente status van uw cluster te voorkomen.
- Schakel verliesloze semi-synchrone replicatie in. Bekijk deze externe blog, die een goede manier is om te leren waarom u semi-synchronisatie zou moeten overwegen in een standaard MySQL-replicatie-installatie.
- Voer constant een controlesom uit op uw master-slave-cluster. U kunt pt-table-checksum gebruiken en het een keer per week of maand uitvoeren, afhankelijk van hoe constant uw tabel wordt bijgewerkt. Houd er rekening mee dat pt-table-checksum overhead kan toevoegen aan uw databaseverkeer.
- Gebruik op GTID gebaseerde replicatie. Hoewel dit het probleem op zich niet zal beïnvloeden. Op GTID gebaseerde replicatie helpt u echter om foutieve transacties vast te stellen, met name die transacties die rechtstreeks op de slave zijn uitgevoerd. Een ander voordeel hiervan is dat het gemakkelijker is om op GTID gebaseerde replicatie te beheren wanneer u bij replicatie van hoofdhost moet wisselen.
Hardwarestoring bij de meester, maar slaven hebben het nog niet ingehaald
Een van de vele redenen waarom u in automatische failover zou investeren, is een hardwarestoring op de master. Voor sommige instellingen kan het ideaal zijn om alleen automatische failover uit te voeren wanneer de master een hardwarefout tegenkomt. De typische benadering is om te waarschuwen door een alarm te sturen - wat kan betekenen dat je de dienstdoende persoon midden in de nacht wakker maakt en de persoon laat beslissen wat hij moet doen. Dit soort benadering wordt gedaan op Github of zelfs Facebook. Een hardwarestoring, vooral als het volume waarop uw binlogs en datadirectory zich bevinden, wordt aangetast, kan uw failover verstoren, vooral als de binaire logbestanden op die defecte schijf zijn opgeslagen. Door het ontwerp zal MHA proberen binaire logboeken van de gecrashte master op te slaan, maar dit is niet mogelijk als de schijf defect is. Een mogelijk scenario is dat de server niet bereikbaar is via SSH. MHA kan geen binaire logboeken opslaan en moet een failover uitvoeren zonder binaire logboekgebeurtenissen toe te passen die alleen op de gecrashte master bestaan. Dit zal ertoe leiden dat de laatste gegevens verloren gaan, vooral als geen enkele slave de master heeft ingehaald.
Oplossingen/oplossing
Als een van de use-cases van MHA wordt aanbevolen om semi-synchrone replicatie te gebruiken, omdat dit het risico op dergelijk gegevensverlies aanzienlijk vermindert. Het is belangrijk op te merken dat alle schrijfacties die naar de master gaan, ervoor moeten zorgen dat slaves de laatste binaire loggebeurtenissen hebben ontvangen voordat ze naar schijf worden gesynchroniseerd. MHA kan de gebeurtenissen toepassen op alle andere slaven, zodat ze consistent met elkaar kunnen zijn.
Bovendien is het ook beter om een back-upstroom van uw binaire logboeken uit te voeren voor noodherstel in het geval dat het hoofdschijfvolume is uitgevallen. Als de server nog steeds toegankelijk is via SSH, kan het verwijzen van het binaire logpad naar het back-uppad van uw binaire log nog steeds werken, zodat failover en slave-herstel nog steeds vooruit kunnen gaan. Op deze manier kunt u gegevensverlies voorkomen.
VIP (virtuele IP) failover veroorzaakt split-brain
MHA behandelt standaard geen VIP-beheer. Het is echter eenvoudig om dit op te nemen in de configuratie van MHA en hooks toe te wijzen in overeenstemming met wat u wilt dat MHA doet tijdens de failover. Je kunt je eigen script opzetten en het koppelen aan de parameters master_ip_failover_script of master_ip_online_change_script. Er zijn ook voorbeeldscripts die zich in de map
Tijdens een automatische failover, zodra uw script met VIP-beheer is aangeroepen en uitgevoerd, zal MHA het volgende doen:de status controleren, de oude VIP verwijderen (of stoppen) en vervolgens de nieuwe VIP opnieuw toewijzen aan de nieuwe master. Een typisch voorbeeld van split brain is, wanneer een master als dood wordt geïdentificeerd vanwege een netwerkprobleem, maar in feite kunnen slave-knooppunten nog steeds verbinding maken met de master. Dit is een vals positief resultaat en leidt vaak tot inconsistentie van gegevens tussen de databases in de installatie. Inkomende clientverbindingen die de VIP gebruiken, worden naar de nieuwe master verzonden. Aan de andere kant kunnen er lokale verbindingen zijn die draaien op de oude master, die verondersteld wordt dood te zijn. De lokale verbindingen kunnen de unix-socket of localhost gebruiken om netwerkhops te verminderen. Dit kan ertoe leiden dat de gegevens afdrijven tegen de nieuwe master en de rest van zijn slaven, omdat gegevens van de oude master niet naar de slaven worden gerepliceerd.
Oplossingen/oplossing:
Zoals eerder vermeld, kunnen sommigen de voorkeur geven aan het vermijden van automatische failover, tenzij de controles hebben vastgesteld dat de master helemaal niet beschikbaar is (zoals een hardwarestoring), d.w.z. dat zelfs de slave-knooppunten deze niet kunnen bereiken. Het idee is dat een fout-positief kan worden veroorzaakt door een netwerkstoring tussen de MHA-node-controller en de master, dus een mens is in dit geval wellicht beter geschikt om een beslissing te nemen over een failover of niet.
Bij het omgaan met valse alarmen heeft MHA een parameter genaamd secundaire_check_script. De waarde die hier wordt geplaatst, kunnen uw aangepaste scripts zijn of u kunt het ingebouwde script /usr/local/bin/masterha_secondary_check gebruiken die samen met het MHA Manager-pakket wordt geleverd. Dit voegt extra controles toe, wat eigenlijk de aanbevolen aanpak is om valse positieven te voorkomen. In het onderstaande voorbeeld van mijn eigen setup, gebruik ik het ingebouwde 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=3306In het bovenstaande voorbeeld zal MHA Manager een lus uitvoeren op basis van de lijst met slave-knooppunten (gespecificeerd door -s argument) die de verbinding met de MySQL-master (192.168.10.60) host zal controleren. Houd er rekening mee dat deze slave-knooppunten in het voorbeeld enkele externe externe knooppunten kunnen zijn die een verbinding tot stand kunnen brengen met de databaseknooppunten binnen het cluster. Dit is een aanbevolen aanpak, vooral voor die instellingen waar MHA Manager op een ander datacenter of ander netwerk draait dan de databaseknooppunten. De volgende volgorde hieronder illustreert hoe het verder gaat met de controles:
- Vanaf de MHA-host -> controleer de TCP-verbinding met het 1e slave-knooppunt (IP:192.168.10.50). Laten we dit verbinding A noemen. Controleer vervolgens vanaf de Slave Node de TCP-verbinding met de Master Node (192.168.10.60). Laten we dit Verbinding B noemen.
Als "Verbinding A" succesvol was maar "Verbinding B" niet in beide routes, masterha_secondary_check script wordt afgesloten met retourcode 0 en MHA Manager besluit dat MySQL-master echt dood is en een failover zal starten. Als "Verbinding A" niet is gelukt, masterha_secondary_check sluit af met retourcode 2 en MHA Manager vermoedt dat er een netwerkprobleem is en start geen failover. Als "Verbinding B" succesvol was, masterha_secondary_check sluit af met retourcode 3 en MHA Manager begrijpt dat de MySQL-masterserver daadwerkelijk in leven is en geen failover start.
Een voorbeeld van hoe het reageert tijdens de failover op basis van het logboek,
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 0Een ander ding om toe te voegen is het toewijzen van een waarde aan de parameter shutdown_script. Dit script is vooral handig als je een goede STONITH- of node-afrastering moet implementeren, zodat het niet uit de dood opstaat. Dit kan inconsistentie in de gegevens voorkomen.
Zorg er ten slotte voor dat de MHA Manager zich binnen hetzelfde lokale netwerk bevindt, samen met de clusterknooppunten, omdat dit de kans op netwerkstoringen verkleint, met name de verbinding van MHA Manager naar de databaseknooppunten.
SPOF vermijden in MHA
MHA kan om verschillende redenen crashen en helaas is er geen ingebouwde functie om dit op te lossen, d.w.z. hoge beschikbaarheid voor MHA. Zoals we echter hebben besproken in onze vorige blog "Master High Availability Manager (MHA) is gecrasht! Wat moet ik nu doen?", is er een manier om SPOF voor MHA te vermijden.
Oplossingen/oplossing:
U kunt Pacemaker gebruiken om actieve/stand-by-knooppunten te maken die worden afgehandeld door cluster resource manager (crm). U kunt ook een script maken om de status van het MHA-managerknooppunt te controleren. U kunt bijvoorbeeld een stand-by-knooppunt inrichten dat actief het MHA-beheerknooppunt controleert door het ingebouwde script masterha_check_status uit te voeren. net zoals hieronder:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).doe dan wat node-afrastering als die controller niet werkt. Je kunt de MHA-tool ook uitbreiden met een helperscript dat via cron-jobs wordt uitgevoerd en het systeemproces van het masterha_manager-script bewaken en het opnieuw spawnen als het proces dood is.
Gegevensverlies tijdens failover
MHA vertrouwt op de traditionele asynchrone replicatie. Hoewel het semi-sync ondersteunt, is semi-sync toch afhankelijk van asynchrone replicatie. In dit type omgeving kan gegevensverlies optreden na een failover. Als uw database niet goed is ingesteld en een ouderwetse replicatiemethode gebruikt, kan dit lastig zijn, vooral als u te maken hebt met gegevensconsistentie en verloren transacties.
Een ander belangrijk ding om op te merken met gegevensverlies met MHA, is wanneer GTID wordt gebruikt zonder semi-synchronisatie ingeschakeld. MHA met GTID maakt geen verbinding via ssh met de master, maar zal eerst proberen de binaire logs voor node-herstel te synchroniseren met de slaves. Dit kan mogelijk leiden tot meer gegevensverlies dan vergeleken met MHA niet-GTID met semi-synchronisatie niet ingeschakeld.
Oplossingen/oplossing
Maak bij het uitvoeren van automatische failover een lijst met scenario's wanneer u verwacht dat uw MHA een failover uitvoert. Aangezien MHA te maken heeft met master-slave-replicatie, is ons advies aan u om gegevensverlies te voorkomen als volgt:
- Schakel lossless semi-sync replicatie in (bestaat in versie MySQL 5.7)
- Gebruik op GTID gebaseerde replicatie. Natuurlijk kunt u de traditionele replicatie gebruiken door de x &y-coördinaten van binlog te gebruiken. Het maakt het echter moeilijker en tijdrovender wanneer u een specifieke binaire log-invoer moet lokaliseren die niet op de slave is toegepast. Daarom is het met GTID in MySQL gemakkelijker om foutieve transacties te detecteren.
- Voor ACID-compliance van uw MySQL-master-slave-replicatie, schakelt u deze specifieke variabelen in:sync_binlog =1, innodb_flush_log_at_trx_commit =1. Dit is duur omdat het meer verwerkingskracht vereist wanneer MySQL de functie fsync() aanroept wanneer het commit, en prestaties kan schijfgebonden zijn in het geval van een groot aantal schrijfbewerkingen. Het gebruik van RAID met batterij-back-upcache bespaart echter uw schijf-I/O. Bovendien is MySQL zelf verbeterd met het vastleggen van binaire loggroepen, maar nog steeds kan het gebruik van een back-upcache enkele schijfsynchronisaties besparen.
- Maak gebruik van parallelle replicatie of multi-threaded slave-replicatie. Dit kan uw slaven helpen om beter te presteren en vermijdt slaafvertragingen ten opzichte van de master. Je wilt niet dat je automatische failover plaatsvindt wanneer de master helemaal niet bereikbaar is via een ssh- of tcp-verbinding, of als er een schijffout is opgetreden en je slaves achterblijven. Dat kan leiden tot gegevensverlies.
- Als u een online of handmatige failover uitvoert, kunt u deze het beste tijdens daluren uitvoeren om onverwachte ongelukken te voorkomen die tot gegevensverlies kunnen leiden. Of om te voorkomen dat tijdrovende zoekopdrachten door uw binaire logboeken graaien terwijl er veel activiteit gaande is.
MHA zegt dat APP niet actief is, of failover werkt niet. Wat moet ik doen?
Het uitvoeren van controles met behulp van het ingebouwde script masterha_check_status zal controleren of het mastreha_manager script actief is. Anders krijg je een foutmelding zoals hieronder:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf app1 is stopped(2:NOT_RUNNING).Er zijn echter bepaalde gevallen waarin u NOT_RUNNING kunt krijgen, zelfs wanneer masterha_manager is aan het rennen. Dit kan te wijten zijn aan het privilege van de ssh_user die je hebt ingesteld, of je hebt masterha_manager uitgevoerd met een andere systeemgebruiker, of de ssh-gebruiker heeft een geweigerde toestemming aangetroffen.
Oplossingen/oplossing:
MHA gebruikt de ssh_user gedefinieerd in de configuratie, indien opgegeven. Anders wordt de huidige systeemgebruiker gebruikt die u gebruikt om de MHA-opdrachten op te roepen. Bij het uitvoeren van het script masterha_check_status u moet er bijvoorbeeld voor zorgen dat de masterha_manager wordt uitgevoerd met dezelfde gebruiker die is opgegeven in ssh_user in uw configuratiebestand, of de gebruiker die zal communiceren met de andere databaseknooppunten in het cluster. U moet ervoor zorgen dat het wachtwoordloze SSH-sleutels zonder wachtwoordzin heeft, zodat MHA geen problemen heeft bij het tot stand brengen van verbinding met de knooppunten die MHA controleert.
Houd er rekening mee dat je de ssh_user . nodig hebt om toegang te hebben tot het volgende:
- Kan de binaire en relaislogboeken lezen van de MySQL-knooppunten die MHA controleert
- Moet toegang hebben tot de MHA-bewakingslogboeken. Bekijk deze parameters in MHA:master_binlog_dir, manager_workdir en manager_log
- Moet toegang hebben tot het MHA-configuratiebestand. Dit is ook erg belangrijk. Tijdens een failover, zodra de failover is voltooid, zal het proberen het configuratiebestand bij te werken en de invoer van de dode master te verwijderen. Als het configuratiebestand de ssh_user . niet toestaat of de OS-gebruiker die u momenteel gebruikt, zal het configuratiebestand niet worden bijgewerkt, wat leidt tot een escalatie van het probleem als het noodlot opnieuw toeslaat.
Kandidaat-master blijft achter, hoe je een mislukte failover forceert en vermijdt
Met verwijzing naar de wiki van MHA, als een slaaf meer dan 100 MB aan relaislogboeken achter de master achterlaat (=meer dan 100 MB aan relaislogboeken moet worden toegepast), kiest MHA standaard de slaaf niet als nieuwe meester omdat het te lang duurt om te herstellen .
Oplossingen/oplossing
In MHA kan dit worden overschreven door de parameter check_repl_delay=0 in te stellen. Tijdens een failover negeert MHA de replicatievertraging bij het selecteren van een nieuwe master en voert het ontbrekende transacties uit. Deze optie is handig wanneer u candidate_master=1 op een specifieke host instelt en u er zeker van wilt zijn dat de host een nieuwe master kan zijn.
Je kunt ook integreren met pt-heartbeat om de nauwkeurigheid van slave-lag te bereiken (zie deze post en deze). Maar dit kan ook worden verlicht met parallelle replicatie of multi-threaded replicatieslaves, aanwezig sinds MySQL 5.6 of, met MariaDB 10 - die beweren een boost te hebben met 10x verbetering in parallelle replicatie en multi-threaded slaves. Dit kan je slaven helpen sneller te repliceren.
MHA-wachtwoorden zijn zichtbaar
Het beveiligen of versleutelen van de wachtwoorden is niet iets dat door MHA wordt afgehandeld. 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