В предишен блог обсъдихме как да мигрираме самостоятелна настройка на Moodle към мащабируема настройка, базирана на клъстерирана база данни. Следващата стъпка, за която ще трябва да помислите, е механизмът за преодоляване на срив – какво правите, ако и когато услугата ви за база данни изпадне.
Неуспешният сървър на база данни не е необичаен, ако имате MySQL репликация като своя бекенд Moodle база данни и ако това се случи, ще трябва да намерите начин да възстановите топологията си, като например популяризирате резервен сървър до стане нов основен сървър. Наличието на автоматично преминаване при отказ за вашата база данни Moodle MySQL помага за времето на работа на приложението. Ще обясним как работят механизмите за превключване при отказ и как да вградите автоматично преминаване при отказ във вашата настройка.
Архитектура с висока достъпност за MySQL база данни
Архитектурата с висока достъпност може да бъде постигната чрез клъстериране на вашата MySQL база данни по няколко различни начина. Можете да използвате MySQL репликация, да настроите множество реплики, които отблизо следват вашата основна база данни. На всичкото отгоре можете да поставите балансьор на натоварването на базата данни, за да разделите трафика за четене/запис и да разпределите трафика между възли за четене-запис и само за четене. Архитектурата на базата данни с висока наличност, използваща MySQL репликация, може да бъде описана по-долу:
Състои се от една основна база данни, две реплики на база данни и балансьори на натоварване на база данни (в този блог ние използваме ProxySQL като балансьори на натоварване на базата данни) и keepalived като услуга за наблюдение на процесите на ProxySQL. Ние използваме виртуален IP адрес като единична връзка от приложението. Трафикът ще бъде разпределен към активния балансьор на натоварване въз основа на флага на ролята в keepalived.
ProxySQL е в състояние да анализира трафика и да разбере дали заявката е четене или запис. След това ще препрати заявката до подходящия(и) хост(и).
Отказ при репликация на MySQL
MySQL репликацията използва двоичен журнал, за да репликира данни от първичните към репликите. Репликите се свързват с основния възел и всяка промяна се реплицира и записва в релейните регистрационни файлове на възлите на репликата чрез IO_THREAD. След като промените се съхранят в регистрационния файл на релето, процесът SQL_THREAD ще продължи с прилагането на данни в базата данни с реплика.
Настройката по подразбиране за параметър read_only в реплика е ВКЛ. Използва се за защита на самата реплика от всякакво директно записване, така че промените винаги ще идват от първичната база данни. Това е важно, тъй като не искаме репликата да се отклонява от основния сървър. Сценарий на отказ в MySQL репликация се случва, когато основният не е достъпен. Може да има много причини за това; например сривове на сървъра или проблеми с мрежата.
Трябва да повишите една от репликите до основна, деактивирайте параметъра само за четене на повишената реплика, за да може да се записва. Трябва също да промените другата реплика, за да се свържете с новия първичен. В режим GTID не е необходимо да отбелязвате името на двоичния журнал и позицията, откъдето да възобновите репликацията. Въпреки това, при традиционната репликация, базирана на binlog, определено трябва да знаете последното име на двоичен журнал и позиция, от която да продължите. Отказът при репликация, базирана на binlog, е доста сложен процес, но дори и отказът при репликация, базирана на GTID, също не е тривиален, тъй като трябва да внимавате за неща като грешни транзакции. Откриването на повреда е едно нещо, а след това реагирането на повреда в рамките на кратко закъснение вероятно не е възможно без автоматизация.
Как ClusterControl активира автоматично превключване при отказ
ClusterControl има способността да извършва автоматично преминаване при отказ за вашата Moodle MySQL база данни. Има функция за автоматично възстановяване за клъстер и възел, която ще задейства процеса на отказ, когато основната база данни се срине.
Ще симулираме как се случва автоматичното превключване при отказ в ClusterControl. Ще направим срив на основната база данни и просто ще видим на таблото за управление на ClusterControl. По-долу е текущата топология на клъстера:
Основната база данни използва IP адрес 10.10.10.11 и репликите са:10.10.10.12 г. и 10.10.10.13 г. Когато сривът се случи на основния, ClusterControl задейства предупреждение и започва преодоляване на срив, както е показано на снимката по-долу:
Едно от репликите ще бъде повишено до основно, което води до Топологията като на долната снимка:
IP адресът 10.10.10.12 вече обслужва трафика за запис като основен, а също така ни остава само една реплика, която има IP адрес 10.10.10.13. От страна на ProxySQL проксито ще открие новия първичен автоматично. Hostgroup (HG10) все още обслужва трафика за запис, който има член 10.10.10.12, както е показано по-долу:
Hostgroup (HG20) все още може да обслужва трафик за четене, но както можете да видите възелът 10.10.10.11 е офлайн поради срива :
След като основният неуспешен сървър се върне онлайн, той няма да бъде автоматично повторно -въведено в топологията на базата данни. Това е, за да се избегне загубата на информация за отстраняване на неизправности, тъй като повторното въвеждане на възела като реплика може да изисква презаписване на някои регистрационни файлове или друга информация. Но е възможно да се конфигурира автоматично повторно присъединяване на неуспешния възел.
