В тази серия от блогове от три части ще обясним подробностите и функционалността на рамката с висока достъпност (HA) за MySQL хостинг, използвайки полусинхронна репликация на MySQL и стека Corosync плюс Pacemaker. В част I ще ви преведем през основите на високата достъпност, компонентите на HA рамка, и след това ще ви запознаем с HA рамката за MySQL.
Какво е висока наличност?
Наличността на една компютърна система е процентът на времето, през което услугите й са в действие за определен период от време. Обикновено се изразява като серия от 9. Например, таблицата по-долу показва наличността и съответното време на престой, измерено за една година.
| % наличност | Престой на година |
| 90% („едно 9 “) | 36,53 дни |
| 99% („две 9s “) | 3,65 дни |
| 99,9% („три 9s “) | 8,77 часа |
| 99,99% („четири 9s “) | 52,60 минути |
| 99,999% („пет 9s “) | 5,26 минути |
| 99,9999% („шест 9s “) | 31,56 секунди |
Значението на високата наличност варира в зависимост от изискванията на вашето приложение и бизнес. Например, ако не можете да си позволите престой за повече от няколко минути на година във вашата услуга, ние казваме, че услугата трябва да има 99,999% висока наличност.
Компоненти на HA Framework
Същността на високодостъпността е възможността за мигновено възстановяване от повреди, които могат да се случат във всяка част на системата. Има четири изключително важни компонента във всяка рамка на HA, които трябва да работят заедно по автоматизиран начин, за да позволят тази възстановимост. Нека разгледаме подробно тези компоненти:
1. Резервиране в инфраструктура и данни
За да бъде една услуга високо достъпна, трябва да гарантираме, че има излишък в хостинга на инфраструктурата, както и актуален излишък копие на данните, които услугата използва или предоставя. Това действа като резервна услуга, готова да поеме в случай, че основната е засегната от повреди.
2. Механизъм за откриване и коригиране на неизправности
Изключително важно е незабавно да откриете всички неизправности във всяка част от основната система, които могат да повлияят на нейната наличност. Това ще позволи на рамката или да предприеме коригиращи действия на същата първична система, или да прехвърли услугите към резервна система.
3. Механизъм за отказ
Този компонент поема отговорността за преодоляване на отказ на услугите към вашата инфраструктура в режим на готовност. Моля, имайте предвид, че в случай, че има множество резервни системи, този компонент на механизма за отказ трябва да идентифицира най-подходящата система сред тях и да я популяризира като основна услуга.
4. Механизъм за пренасочване на приложения/потребител
След като системите в режим на готовност поемат ролята на основни, този компонент гарантира, че всички приложения и потребителски връзки започват да се случват с новия основен.
Обяснена рамка за висока достъпност на MySQL – част IC Кликнете, за да Tweet
Ха рамката за MySQL
Въз основа на горния модел ние използваме следната HA рамка за нашия MySQL хостинг в ScaleGrid:
- Настройка главен-подчинен с 3 възела, използваща полусинхронна репликация на MySQL за осигуряване на инфраструктура и резервиране на данни.
- Стекът Corosync плюс Pacemaker за осигуряване на откриване, коригиране и механизъм за преодоляване на отказ.
- DNS съпоставяне или компонент за виртуален IP, който осигурява механизма за пренасочване на приложението и потребителя.
Разгледайте диаграмата по-долу, за да визуализирате софтуерния пакет на тази архитектура:
Нека прегледаме функционалността на някои от ключовите компоненти в тази рамка.
-
Corosync
Corosync предоставя комуникационна рамка за възлите с надеждно предаване на съобщения между тях. Той образува клъстерен пръстен от възли и следи възлите, които се присъединяват и напускат клъстера чрез членство в клъстера. Corosync работи в тясно сътрудничество с Pacemaker, за да комуникира за наличността на възела, така че Pacemaker да може да вземе подходящи решения.
-
Пейсмейкър
Също известен като Cluster Resource Manager (CRM), Pacemaker гарантира високата наличност за MySQL, работещ в клъстера, и открива и обработва грешки на ниво възел чрез взаимодействие с Corosync. Той също така открива и обработва неизправности на MySQL чрез взаимодействие с Resource Agent (RA). Pacemaker конфигурира и управлява ресурса на MySQL чрез стартиране, спиране, наблюдение, повишаване и понижаване.
-
Агент за ресурси
Ресурсният агент действа като интерфейс между MySQL и Pacemaker. Прилага стартиране, спиране, насърчаване, понижаване и наблюдение на операциите, които се извикват от пейсмейкъра. Има напълно функционален ресурсен агент, наречен Percona Replication Manager (PRM) за MySQL, внедрен от Percona. Това е подобрено от ScaleGrid и е достъпно на нашата страница в GitHub.
-
DNS Mapping Component
Ресурсният агент, при завършване на успешно преодоляване на срив, извиква този компонент, който актуализира DNS записите на главния MySQL сървър с IP адреса на новия главен. Имайте предвид, че клиентите винаги използват главно DNS име, за да се свържат с MySQL сървъра и като управляваме съпоставянето на това DNS име с IP адреса на текущия главен, можем да гарантираме, че клиентите не трябва да променят своите низове за връзка или свойства, когато има отказ.
В част II от тази поредица от блогове ще научите за критичния компонент за резервиране на данни, който се постига с помощта на MySQL полусинхронна репликация. Също така ще се потопим дълбоко в подробностите и конфигурациите на полусинхронната репликация, които използваме, за да постигнем нашата поддръжка за висока наличност, и накрая, ще прегледаме различни сценарии на отказ в част III и начина, по който рамката реагира и се възстановява от тези условия.
