Автоматизираният отказ е почти задължителен за много приложения - времето за работа се приема за даденост. Доста трудно е да приемем, че приложение не работи за 20 или 30 минути, защото някой трябва да бъде изпратен на страница, за да влезе и да проучи ситуацията, преди да предприеме действия.
В реалния свят настройките за репликация са склонни да нарастват с течение на времето, за да станат сложни, понякога разхвърляни. И има ограничения. Например, не всеки възел в една настройка е добър кандидат за главен. Може би хардуерът се различава и някои от репликите имат по-малко мощен хардуер, тъй като са предназначени да се справят с някои специфични видове натоварване? Може би сте в средата на миграция към нова версия на MySQL и някои от подчинените вече са надградени? Предпочитате да нямате главен в по-нова версия, който да репликира към стари реплики, тъй като това може да наруши репликацията. Ако имате два центъра за данни, един активен и един за възстановяване след бедствие, може да предпочетете да изберете главни кандидати само в активния център за данни, за да запазите главния близо до хостовете на приложението. Това са само примерни ситуации, в които може да се окажете, че се нуждаете от ръчна намеса по време на процеса на отказ. За щастие, много инструменти за отказване имат опция да поемат контрола над процеса чрез използване на бели и черни списъци. В тази публикация в блога бихме искали да ви покажем някои примери как можете да повлияете на алгоритъма на ClusterControl за избор на главни кандидати.
Конфигуриране на бели и черни списъци
ClusterControl ви дава възможност да дефинирате както белия, така и черния списък с реплики. Белият списък е списък с реплики, които са предназначени да станат главни кандидати. Ако нито един от тях не е наличен (или защото не работи, или има грешни транзакции, или има други пречки, които пречат на който и да е от тях да бъде повишен), преминаването при отказ няма да се извърши. По този начин можете да дефинирате кои хостове са налични, за да станете главен кандидат. Черните списъци, от друга страна, определят кои реплики не са подходящи, за да станат главен кандидат.
И двата списъка могат да бъдат дефинирани в cmon конфигурационния файл за даден клъстер. Например, ако вашият клъстер има идентификатор „1“, искате да редактирате „/etc/cmon.d/cmon_1.cnf“. За бял списък ще използвате променлива „replication_failover_whitelist“, за черен списък ще бъде „replication_failover_blacklist“. И двете приемат разделен със запетая списък „хост:порт“.
Нека разгледаме следната настройка за репликация. Имаме активен главен (10.0.0.141), който има две реплики (10.0.0.142 и 10.0.0.143), и двата действат като междинни главни и имат по една реплика (10.0.0.144 и 10.0.0.147). Ние също така имаме резервен главен код в отделен център за данни (10.0.0.145), който има реплика (10.0.0.146). Тези хостове са предназначени да се използват в случай на бедствие. Репликата 10.0.0.146 и 10.0.0.147 действат като резервни хостове. Вижте екранната снимка по-долу.
Като се има предвид, че вторият център за данни е предназначен само за възстановяване след бедствие, ние не искаме нито един от тези хостове да бъде популяризиран като главен. В най-лошия случай ще предприемем ръчни действия. Инфраструктурата на втория център за данни не е мащабирана до размера на производствения център за данни (има три копия по-малко в центъра за данни DR), така че така или иначе са необходими ръчни действия, преди да можем да популяризираме хост в центъра за данни DR. Също така не бихме искали резервна реплика (10.0.0.147) да бъде популяризирана. Нито искаме трета реплика във веригата да бъде взета като главен (въпреки че може да се направи с GTID).
Конфигурация на белия списък
Можем да конфигурираме или бял списък, или черен списък, за да сме сигурни, че преминаването при отказ ще бъде обработено по наш вкус. В тази конкретна настройка използването на бял списък може да е по-подходящо - ние ще дефинираме кои хостове могат да се използват за отказ и ако някой добави нов хост към настройката, той няма да бъде взет под внимание като главен кандидат, докато някой ръчно не реши, че е добре да го използвате и да го добавите към белия списък. Ако използвахме черен списък, добавянето на нова реплика някъде във веригата може да означава, че такава реплика теоретично може да се използва автоматично за отказване, освен ако някой изрично не каже, че не може да се използва. Нека останем на сигурно място и да дефинираме бял списък в нашия конфигурационен файл на клъстер (в този случай това е /etc/cmon.d/cmon_1.cnf, тъй като имаме само един клъстер):
replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306Трябва да се уверим, че cmon процесът е рестартиран, за да приложим промените:
service cmon restartДа предположим, че нашият господар се е сринал и не може да бъде достигнат от ClusterControl. Ще бъде стартирана задача за преодоляване на срив:
Топологията ще изглежда така:
Както можете да видите, старият главен код е деактивиран и ClusterControl няма да се опита да го възстанови автоматично. От потребителя зависи да провери какво се е случило, да копира всички данни, които може да не са били репликирани в главния кандидат и да изгради отново стария главен код:
Тогава става въпрос за няколко промени в топологията и можем да приведем топологията в първоначалното състояние, като просто заменим 10.0.0.141 с 10.0.0.142:
Конфигуриране на черен списък
Сега ще видим как работи черният списък. Споменахме, че в нашия пример може да не е най-добрият вариант, но ще го опитаме за илюстрация. Ще поставим в черен списък всеки хост с изключение на 10.0.0.141, 10.0.0.142 и 10.0.0.143, тъй като това са хостовете, които искаме да видим като главни кандидати.
replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306Също така ще рестартираме процеса cmon, за да приложим промените в конфигурацията:
service cmon restartПроцесът на отказ е подобен. Отново, след като главният срив бъде открит, ClusterControl ще започне работа за преодоляване на срив.
Когато реплика може да не е добър главен кандидат
В този кратък раздел бихме искали да обсъдим по-подробно някои от случаите, в които може да не искате да популяризирате дадена реплика, за да станете нов главен. Надяваме се, че това ще ви даде някои идеи за случаите, в които може да се наложи да обмислите въвеждането на повече ръчен контрол на процеса на отказ.
Различна версия на MySQL
Първо, ако вашата реплика използва различна версия на MySQL от основната, не е добра идея да я популяризирате. Най-общо казано, по-нова версия винаги е забранена, тъй като репликацията от новата към старата версия на MySQL не се поддържа и може да не работи правилно. Това важи най-вече за основните версии (например, 8.0 репликиране на 5.7), но добрата практика е да се избягва тази настройка като цяло, дори ако говорим за малки разлики във версиите (5.7.x+1 -> 5.7.x). Реплицирането от по-ниска към по-висока/нова версия се поддържа, тъй като е задължително за процеса на надстройка, но все пак бихте искали да избегнете това (например, ако вашият главен код е на 5.7.x+1, предпочитате да не го заменяте с реплика на 5.7.x).
Различни роли
Можете да зададете различни роли на вашите реплики. Можете да изберете един от тях, за да бъде достъпен за разработчиците, за да тестват своите заявки в набор от производствени данни. Можете да използвате един от тях за натоварване на OLAP. Можете да използвате един от тях за архивиране. Без значение какво е, обикновено не бихте искали да популяризирате такава реплика за майстор. Всички тези допълнителни, нестандартни натоварвания могат да причинят проблеми с производителността поради допълнителните режийни разходи. Добър избор за главен кандидат е реплика, която обработва „нормално“ натоварване, повече или по-малко от същия тип натоварване като текущия главен. След това можете да сте сигурни, че ще се справи с главния товар след отказ, ако го е обработил преди това.
Различни хардуерни спецификации
Споменахме различни роли за репликите. Не е необичайно да видите и различни хардуерни спецификации, особено във връзка с различни роли. Например, резервното подчинено устройство най-вероятно не трябва да бъде толкова мощно, колкото обикновената реплика. Разработчиците могат също да тестват своите заявки в по-бавна база данни от производствената (най-вече защото не бихте очаквали същото ниво на едновременност на база данни за разработка и производство) и например броят на процесорните ядра може да бъде намален. Настройките за възстановяване при бедствия също могат да бъдат намалени по размер, ако основната им роля е да поддържат репликацията и се очаква, че настройката на DR ще трябва да бъде мащабирана (както вертикално, чрез оразмеряване на екземпляра, така и хоризонтално, чрез добавяне на повече реплики) преди трафикът да може да бъде пренасочен към него.
Отложени реплики
Някои от репликите може да са забавени - това е много добър начин за намаляване на времето за възстановяване, ако данните са загубени, но ги прави много лоши кандидати за главен. Ако реплика се забави с 30 минути, вие или ще загубите тези 30 минути транзакции, или ще трябва да изчакате (вероятно не 30 минути, тъй като най-вероятно репликата може да навакса по-бързо), за да приложи репликата всички забавени транзакции. ClusterControl ви позволява да изберете дали искате да изчакате или да преминете към отказ незабавно, но това ще работи добре за много малко забавяне - най-много десетки секунди. Ако се предполага, че преминаването при отказ трябва да отнеме минути, просто няма смисъл да използвате такава реплика и затова е добра идея да я поставите в черен списък.
Различен център за данни
Споменахме намалени настройки на DR, но дори ако вторият ви център за данни е мащабиран до размера на производството, все пак може да е добра идея да запазите отказите само в рамките на един DC. Като за начало, вашите активни хостове на приложения може да се намират в главния център за данни, като по този начин преместването на главния в резервен DC би увеличило значително латентността за заявки за запис. Също така, в случай на разделяне на мрежата, може да искате да се справите ръчно с тази ситуация. MySQL няма вграден механизъм за кворум, поради което е малко трудно да се обработва правилно (по автоматичен начин) загубата на мрежа между два центъра за данни.
