В предишните ни блогове обсъждахме MHA като инструмент за отказ, използван в настройките на MySQL master-slave. Миналия месец също публикувахме блог за това как да се справим с MHA, когато се срине. Днес ще видим основните проблеми, които DBA обикновено срещат с MHA, и как можете да ги отстраните.
Кратко въведение в MHA (Master High Availability)
MHA означава (Master High Availability) все още е актуален и широко използван днес, особено в настройките главен-подчинен, базирани на репликация без GTID. MHA работи добре при отказ или главен превключвател, но идва с някои клопки и ограничения. След като MHA извърши главен отказ и промоция на подчинен, той може автоматично да завърши своята операция за превключване на база данни в рамките на ~30 секунди, което може да бъде приемливо в производствена среда. MHA може да гарантира последователността на данните. Всичко това с нулево влошаване на производителността и не изисква допълнителни корекции или промени в съществуващите ви разгръщания или настройки. Освен това, MHA е изграден върху Perl и е HA решение с отворен код - така че е сравнително лесно да създадете помощници или да разширите инструмента в съответствие с желаната от вас настройка. Вижте тази презентация за повече информация.
Софтуерът MHA се състои от два компонента, трябва да инсталирате един от следните пакети в съответствие с неговата топологична роля:
MHA мениджър възел =MHA мениджър (мениджър)/MHA възел (възел с данни)
Главни/подчинени възли =MHA възел (възел с данни)
MHA Manager е софтуерът, който управлява отказоустойчивостта (автоматично или ръчно), взема решения за това кога и къде да се превключва и управлява възстановяването на подчинен по време на повишение на кандидат-главен за прилагане на диференциални релейни регистри. Ако основната база данни умре, MHA Manager ще се координира с агента на MHA Node, тъй като прилага диференциални релейни регистрационни файлове към подчинените, които нямат най-новите binlog събития от главния. Софтуерът MHA Node е локален агент, който ще следи вашия MySQL екземпляр и ще позволи на MHA Manager да копира релейни регистри от подчинените. Типичен сценарий е, че когато главният кандидат за отказ в момента изостава и MHA го открива, нямат най-новите регистрационни файлове на релето. Следователно, той ще изчака своя мандат от MHA Manager, докато търси най-новия подчинен, който съдържа събитията за binlog и копира липсващите събития от подчинения с помощта на scp и ги прилага към себе си.
Имайте предвид обаче, че MHA в момента не се поддържа активно, но самата текуща версия е стабилна и може да е „достатъчно добра“ за производство. Все още можете да повторите гласа си чрез github, за да разрешите някои проблеми или да предоставите корекции на софтуера.
Водещи често срещани проблеми
Сега нека разгледаме най-често срещаните проблеми, които DBA ще срещне, когато използва MHA.
Slave изостава, неинтерактивно/автоматично преминаване при отказ е неуспешно!
Това е типичен проблем, причиняващ прекратяване или отказ на автоматичното преминаване при отказ. Това може да звучи просто, но не сочи само един конкретен проблем. Закъснението на подчинените може да има различни причини:
- Проблеми с диска на главния кандидат, което го кара да е дисков I/O, обвързан да обработва четене и запис. Това може също да доведе до повреда на данните, ако не бъде смекчено.
- Лошите заявки се репликират, особено таблици, които нямат първични ключове или клъстерирани индекси.
- високо натоварване на сървъра.
- Студеният сървър и сървърът все още не са загрели
- Няма достатъчно ресурси на сървъра. Възможно е вашият подчинен да има твърде малко памет или ресурси на сървъра, докато репликира високо интензивно записване или четене.
Те могат да бъдат смекчени предварително, ако имате подходящ мониторинг на вашата база данни. Един пример по отношение на подчинените забавяния в MHA е с ниска памет при изхвърляне на голям двоичен регистрационен файл. Като пример по-долу, главен обект е маркиран като мъртъв и трябва да извърши неинтерактивно/автоматично преминаване при отказ. Въпреки това, тъй като главният кандидат изоставаше и трябва да приложи регистрационните файлове, които все още не са били изпълнени от нишките за репликация, MHA ще намери най-актуалния или най-новия подчинен, тъй като ще се опита да възстанови подчинен срещу най-стария нечий. Следователно, както можете да видите по-долу, докато извършваше подчинено възстановяване, паметта беше твърде ниска:
[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.По този начин преодоляването на срив се провали. Този пример по-горе показва, че възел 192.168.10.70 съдържа най-актуалните регистрационни файлове за реле. В този примерен сценарий обаче възел 192.168.10.70 е зададен като no_master, тъй като има малко памет. Докато се опитва да възстанови подчинения 192.168.10.50, не успява!
Поправки/резолюция:
Този сценарий илюстрира нещо много важно. Трябва да се настрои усъвършенствана среда за наблюдение! Например, можете да стартирате фонов или демон скрипт, който следи здравето на репликацията. Можете да добавите като запис чрез cron задание. Например добавете запис с помощта на вградения скрипт masterha_check_repl :
/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnfили създайте фонов скрипт, който извиква този скрипт и го изпълнява на интервал. Можете да използвате опцията report_script, за да настроите известие за предупреждение, в случай че то не отговаря на вашите изисквания, например подчинено устройство изостава за около 100 секунди по време на висок пиков товар. Можете също да използвате платформи за наблюдение, като ClusterControl, да го настроите да ви изпраща известия въз основа на показателите, които искате да наблюдавате.
В допълнение към това, имайте предвид, че в примерния сценарий преминаването при отказ е неуспешно поради грешка при липса на памет. Може да помислите да се уверите, че всичките ви възли имат достатъчно памет и правилния размер на двоични регистрационни файлове, тъй като те ще трябва да изхвърлят binlog за фаза на възстановяване на подчинени.
Непоследователно подчинено устройство, прилагането на разликите не бе успешно!
По отношение на подчинено забавяне, тъй като MHA ще се опита да синхронизира релейни регистрационни файлове с кандидат-главен, уверете се, че вашите данни са синхронизирани. Кажете за пример по-долу:
...
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]Непоследователният клъстер е наистина лош, особено когато е активирано автоматично превключване при отказ. В този случай преминаването при отказ не може да продължи, тъй като открива дублиран запис за първичен ключ „12583545 '.
Поправки/резолюция:
Има няколко неща, които можете да направите тук, за да избегнете непоследователно състояние на вашия клъстер.
- Активиране на полусинхронна репликация без загуби. Вижте този външен блог, който е добър начин да научите защо трябва да обмислите използването на полусинхронизиране в стандартна настройка на MySQL репликация.
- Постоянно изпълнявайте контролна сума срещу вашия главен-подчинен клъстер. Можете да използвате pt-table-checksum и да го стартирате веднъж седмично или месечно в зависимост от това колко постоянно се актуализира вашата таблица. Обърнете внимание, че pt-table-checksum може да добави допълнителни разходи към трафика на вашата база данни.
- Използвайте репликация, базирана на GTID. Въпреки че това няма да повлияе на проблема сам по себе си. Въпреки това, репликацията, базирана на GTID, ви помага да определите грешни транзакции, особено онези транзакции, които са били стартирани директно на подчинения. Друго предимство на това е, че е по-лесно да управлявате базирана на GTID репликация, когато трябва да превключите главния хост в репликация.
Повреда на хардуера на главния, но подчинените все още не са настигнали
Една от многото причини, поради които бихте инвестирали в автоматично преминаване при отказ, е хардуерна повреда на главния. За някои настройки може да е по-идеално да се извърши автоматично преминаване при отказ само когато главният срещне хардуерен отказ. Типичният подход е да се уведомява чрез изпращане на аларма - което може да означава събуждане на дежурния оператор посред нощ, оставяйки лицето да реши какво да прави. Този тип подход се прави в Github или дори във Facebook. Хардуерна повреда, особено ако обемът, в който се намират вашите binlogs и директория с данни, може да се забърква с преодоляването на срив, особено ако двоичните регистрационни файлове се съхраняват на този неуспешен диск. По замисъл MHA ще се опита да запази двоични регистрационни файлове от катастрофиралия главен файл, но това не може да бъде възможно, ако дискът се провали. Един възможен сценарий може да се случи е сървърът да не може да бъде достъпен чрез SSH. MHA не може да записва двоични регистрационни файлове и трябва да извърши отказ, без да прилага двоични регистрационни събития, които съществуват само на катастрофиралия главен файл. Това ще доведе до загуба на най-новите данни, особено ако нито един подчинен не е настигнал главния.
Поправки/Разделителна способност
Като един от случаите на използване от MHA, се препоръчва използването на полусинхронна репликация, тъй като тя значително намалява риска от такава загуба на данни. Важно е да се отбележи, че всички записи, които отиват към главния, трябва да гарантират, че подчинените са получили най-новите събития в двоичен журнал, преди да се синхронизират с диска. MHA може да приложи събитията към всички други подчинени устройства, за да могат да бъдат съвместими едно с друго.
Освен това е по-добре да стартирате архивен поток на вашите двоични регистрационни файлове за възстановяване при бедствие, в случай че основният диск се повреди. Ако сървърът все още е достъпен чрез SSH, тогава насочването на пътя на двоичния дневник към резервния път на вашия двоичен дневник все още може да работи, така че превключването при отказ и възстановяването на подчинен файл все още могат да се движат напред. По този начин можете да избегнете загуба на данни.
VIP (виртуален IP) отказ, причиняващ разделяне на мозъка
MHA по подразбиране не обработва VIP управление. Въпреки това, лесно е да включите това с конфигурацията на MHA и да зададете куки в съответствие с това, което искате MHA да прави по време на отказ. Можете да настроите свой собствен скрипт и да го свържете към параметрите master_ip_failover_script или master_ip_online_change_script. Има и примерни скриптове, които се намират в
По време на автоматично преминаване на отказ, след като вашият скрипт с управление на VIP бъде извикан и изпълнен, MHA ще направи следното:ще провери състоянието, ще премахне (или спре) стария VIP и след това присвои отново новия VIP на новия главен. Типичен пример за разделен мозък е, когато главен е идентифициран като мъртъв поради проблем с мрежата, но всъщност подчинените възли все още могат да се свържат с главния. Това е фалшиво положително и често води до несъответствие на данните в базите данни в настройката. Входящите клиентски връзки, използващи VIP, ще бъдат изпратени до новия главен. Докато от друга страна, може да има локални връзки, работещи на стария master, който се предполага, че е мъртъв. Локалните връзки могат да използват unix сокет или localhost, за да намалят мрежовите скокове. Това може да доведе до отклоняване на данните спрямо новия главен и останалите негови подчинени устройства, тъй като данните от стария главен няма да бъдат репликирани в подчинените.
Поправки/резолюция:
Както беше посочено по-рано, някои може да предпочетат да избегнат автоматичното преминаване при отказ, освен ако проверките не са установили, че главният е напълно изключен (като хардуерна повреда), т.е. дори подчинените възли не са в състояние да го достигнат. Идеята е, че фалшивият положителен резултат може да бъде причинен от мрежов проблем между контролера на MHA възел и главния, така че човек може да е по-подходящ в този случай, за да вземе решение дали да премине при отказ или не.
Когато работи с фалшиви аларми, MHA има параметър, наречен secondary_check_script. Посочената тук стойност може да бъде вашите персонализирани скриптове или можете да използвате вградения скрипт /usr/local/bin/masterha_secondary_check който се доставя заедно с пакета MHA Manager. Това добавя допълнителни проверки, което всъщност е препоръчителният подход за избягване на фалшиви положителни резултати. В примера по-долу от моята собствена настройка използвам вградения скрипт 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В горния пример, MHA Manager ще направи цикъл въз основа на списъка с подчинени възли (определени с аргумент -s), който ще провери връзката с MySQL главен (192.168.10.60) хост. Обърнете внимание, че тези подчинени възли в примера могат да бъдат някои външни отдалечени възли, които могат да установят връзка с възлите на базата данни в клъстера. Това е препоръчителен подход, особено за онези настройки, при които MHA Manager работи в различен център за данни или различна мрежа от възлите на базата данни. Следната последователност по-долу илюстрира как протича с проверките:
- От MHA хост -> проверете TCP връзката към 1-ви подчинен възел (IP:192.168.10.50). Нека наречем това като връзка А. След това от подчинения възел проверява TCP връзката към главния възел (192.168.10.60). Нека наречем тази връзка B.
Ако „Връзка А“ е била успешна, но „Връзка Б“ е била неуспешна и в двата маршрута, masterha_secondary_check скриптът излиза с код за връщане 0 и MHA Manager решава, че MySQL master наистина е мъртъв и ще започне отказ. Ако „Връзка А“ е била неуспешна, masterha_secondary_check излиза с код за връщане 2 и MHA мениджърът предполага, че има проблем с мрежата и не стартира отказ. Ако „Връзка B“ е била успешна, masterha_secondary_check излиза с код за връщане 3 и MHA мениджърът разбира, че главният сървър на MySQL всъщност е жив и не стартира отказоустойчивост.
Пример за това как реагира по време на отказ, въз основа на регистрационния файл,
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Друго нещо, което трябва да добавите, е присвояването на стойност на параметъра shutdown_script. Този скрипт е особено полезен, ако трябва да приложите подходяща STONITH или възлова ограда, така че да не възкръсне от мъртвите. Това може да избегне несъответствието на данните.
И накрая, уверете се, че MHA Manager се намира в същата локална мрежа заедно с възлите на клъстера, тъй като намалява възможността от прекъсвания на мрежата, особено връзката от MHA Manager към възлите на базата данни.
Избягване на SPOF в MHA
MHA може да се срине по различни причини и за съжаление няма вградена функция, която да коригира това, т.е. Висока наличност за MHA. Въпреки това, както обсъдихме в предишния ни блог „Master High Availability Manager (MHA) се сри! Какво да направя сега?“, има начин да избегнете SPOF за MHA.
Поправки/резолюция:
Можете да използвате Pacemaker за създаване на активни/готови възли, управлявани от мениджъра на клъстерни ресурси (crm). Като алтернатива можете да създадете скрипт, за да проверите здравето на възела на мениджъра на MHA. Например можете да осигурите резервен възел, който активно проверява възела на мениджъра на MHA чрез ssh'ing, за да изпълни вградения скрипт masterha_check_status точно както по-долу:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).след това направете някои възли фехтовка, ако този контролер е борк. Можете също да разширите MHA инструмента с помощен скрипт, който се изпълнява чрез cron задание и да наблюдава системния процес на скрипта masterha_manager и да го създаде отново, ако процесът е мъртъв.
Загуба на данни по време на отказ
MHA разчита на традиционната асинхронна репликация. Въпреки че поддържа полу-синхронизация, все пак полу-синхронизацията разчита на асинхронна репликация. В този тип среда загубата на данни може да се случи след отказ. Когато базата ви данни не е настроена правилно и използва старомоден подход на репликация, това може да бъде болка, особено когато се занимавате с последователност на данните и загубени транзакции.
Друго важно нещо, което трябва да се отбележи при загуба на данни с MHA, е когато GTID се използва без активирана полусинхронизация. MHA с GTID няма да се свърже чрез ssh към главния, но ще се опита първо да синхронизира двоичните регистрационни файлове за възстановяване на възел с подчинените. Това потенциално може да доведе до повече загуба на данни, отколкото в сравнение с MHA без GTID с неактивирана полусинхронизация.
Поправки/Разделителна способност
Когато извършвате автоматично превключване при отказ, изградете списък със сценарии, когато очаквате вашия MHA да премине при отказ. Тъй като MHA се занимава с репликация главен-подчинен, тогава нашият съвет към вас да избегнете загуба на данни е следният:
- Активиране на полусинхронизирана репликация без загуби (съществува във версия MySQL 5.7)
- Използвайте репликация, базирана на GTID. Разбира се, можете да използвате традиционната репликация, като използвате координатите x &y на binlog. Това обаче прави нещата по-трудни и отнема много време, когато трябва да намерите конкретен двоичен запис в дневника, който не е приложен към подчинения. Следователно с GTID в MySQL е по-лесно да се открият грешни транзакции.
- За съответствие с ACID на вашата репликация главен-подчинен MySQL, активирайте тези специфични променливи:sync_binlog =1, innodb_flush_log_at_trx_commit =1. Това е скъпо, тъй като изисква повече мощност на обработка, когато MySQL извиква функцията fsync() при извършване, и производителност може да бъде обвързан с диск в случай на голям брой записи. Въпреки това, използването на RAID с кеш за резервно копиране на батерията спестява входно/изходно предаване на вашия диск. Освен това самият MySQL се е подобрил с групово записване на двоичен дневник, но все пак използването на резервен кеш може да спести някои дискови синхронизации.
- Използвайте паралелна репликация или многонишкова подчинена репликация. Това може да помогне на вашите подчинени да станат по-ефективни и да избегне забавянето на роба срещу господаря. Не искате вашето автоматично превключване при отказ да се случи, когато главният не е достъпен изобщо чрез ssh или tcp връзка, или ако срещне повреда на диска и вашите подчинени са изостанали. Това може да доведе до загуба на данни.
- Когато извършвате онлайн или ръчно преодоляване на срив, най-добре е да го извършвате през периоди, които не са пикови, за да избегнете неочаквани инциденти, които могат да доведат до загуба на данни. Или за да избегнете отнемащи време търсения, които преминават през вашите двоични регистрационни файлове, докато има много активност.
MHA казва, че APP не работи, или отказът не работи. Какво трябва да направя?
Изпълнението на проверки с помощта на вградения скрипт masterha_check_status ще провери дали скриптът mastreha_manager се изпълнява. В противен случай ще получите грешка като по-долу:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf app1 is stopped(2:NOT_RUNNING).Въпреки това, има определени случаи, в които може да получите NOT_RUNNING дори когато masterha_manager бяга. Това може да се дължи на привилегията на ssh_user, който сте задали, или стартирате masterha_manager с друг потребител на системата, или потребителят на ssh е срещнал отказано разрешение.
Поправки/резолюция:
MHA ще използва ssh_user дефинирани в конфигурацията, ако е посочено. В противен случай ще използва текущия системен потребител, който използвате, за да извикате MHA командите. При изпълнение на скрипта masterha_check_status например трябва да се уверите, че masterha_manager работи със същия потребител, който е посочен в ssh_user във вашия конфигурационен файл или потребителя, който ще взаимодейства с другите възли на базата данни в клъстера. Трябва да се уверите, че има SSH ключове без парола и без парола, така че MHA няма да има проблеми при установяване на връзка с възлите, които MHA наблюдава.
Обърнете внимание, че имате нужда от ssh_user за да имате достъп до следното:
- Може да чете двоичните и релейните регистрационни файлове на MySQL възлите, които MHA наблюдава
- Трябва да има достъп до регистрационните файлове за наблюдение на MHA. Вижте тези параметри в MHA:master_binlog_dir, manager_workdir и manager_log
- Трябва да има достъп до конфигурационния файл на MHA. Това също е много важно. По време на отказ, след като завърши преминаването на отказ, той ще се опита да актуализира конфигурационния файл и да премахне записа на мъртвия главен код. Ако конфигурационният файл не позволява ssh_user или потребителят на ОС, който използвате в момента, той няма да актуализира конфигурационния файл, което води до ескалация на проблема, ако бедствието се случи отново.
Кандидат главен изоставане, как да принудим и избегнем неуспешно прекратяване на отказ
Във връзка с уикито на MHA, по подразбиране, ако подчинен участък зад главния над 100MB релейни регистри (=трябва да приложи повече от 100MB релейни регистри), MHA не избира подчинения като нов главен, защото отнема твърде много време за възстановяване .
Поправки/Разделителна способност
В MHA това може да бъде отменено чрез задаване на параметъра check_repl_delay=0. По време на отказ, MHA игнорира забавянето на репликацията при избор на нов главен код и ще изпълни липсващи транзакции. Тази опция е полезна, когато зададете kandidat_master=1 на конкретен хост и искате да сте сигурни, че хостът може да бъде нов главен.
Можете също да се интегрирате с pt-heartbeat, за да постигнете точност на подчинено забавяне (вижте тази публикация и тази). Но това може също да бъде облекчено с паралелна репликация или многонишкови подчинени устройства за репликация, присъстващи от MySQL 5.6 или, с MariaDB 10 – твърдейки, че има тласък с 10-кратно подобрение в паралелната репликация и многонишковите подчинени устройства. Това може да помогне на вашите подчинени да се репликират по-бързо.
Паролите за MHA са разкрити
Защитата или криптирането на паролите не е нещо, което се обработва от 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
