Moodle, система за управление на обучението с отворен код, стана все по-популярна през миналата година, тъй като пандемията наложи тежки блокирания и по-голямата част от образователните дейности се преместиха от училища, колежи и университети към онлайн платформи. С него беше оказан натиск върху ИТ екипите да гарантират, че тези онлайн платформи ще могат да поемат много по-голямо натоварване, отколкото са изпитвали преди. Повдигнаха се въпроси - как може една платформа на Moodle да бъде мащабирана, за да се справи с увеличеното натоварване? От една страна, мащабирането на самото приложение не е трудно за изпълнение, но базата данни, от друга страна, е различно животно. Базите данни, както всички услуги с поддържане на състоянието, са изключително трудни за мащабиране. В тази публикация в блога бихме искали да обсъдим някои предизвикателства, пред които ще се сблъскате, когато мащабирате база данни на Moodle.
Мащабиране на базата данни на Moodle – Предизвикателството
Основният източник на проблеми е наследството - Moodle, подобно на много бази данни, идва от един фон на база данни и като такъв идва с някои очаквания, които са свързани с такава среда. Типичното е, че можете да изпълнявате една транзакция след друга и втората транзакция винаги ще вижда резултата от първата. Това не е непременно така в повечето среди на разпределени бази данни. Асинхронната репликация не дава обещания. Всяка транзакция може да се загуби в процеса. Достатъчно е главният да се срине, преди данните за транзакцията да бъдат прехвърлени на подчинени. Полусинхронната репликация носи обещание за безопасност на данните, но не обещава нищо друго. Подчинените все още могат да изостават и въпреки че данните се съхраняват в постоянно съхранение като релеен дневник и в крайна сметка ще бъдат приложени към набора от данни, това все още не означава, че вече са приложени. Можете да запитвате подчинените си и да не виждате данните, които току-що сте записали на главния.
Дори клъстери като Galera по подразбиране не се предлагат с наистина синхронна репликация - разликата е значително намалена в сравнение със системите за репликация, но все още е там и незабавното SELECT, изпълнено след предишно записване, може да не види данни, които току-що съхранихте в базата данни, защото вашият SELECT беше насочен към различен възел на Galera от предишното ви записване.
Има няколко решения, които можете да използвате, за да мащабирате базата данни на Moodle MySQL. Като за начало, ако използвате настройка за репликация, можете да използвате функцията „безопасно четене“ от Moodle. Разгледахме това в един от предишните ни блогове. Това ще доведе до ситуацията, в която Moodle ще реши кои записи ще бъдат разпределени между подчинените и кои ще удрят главния.
От една страна е добре - можете безопасно да използвате няколко свързани подчинени устройства на капитана, което ви позволява да разтоварите капитана поне до известна степен. От друга страна, далеч не е идеален, защото е само подмножество от SELECT, които ще можете да изпратите на подчинените. Разбира се, всичко зависи от конкретния случай, но можете да очаквате, че капитана ще остане пречка по отношение на натоварването.
Алтернативен подход може да бъде да се използва клъстерът Galera и да се разпредели натоварването равномерно между всички възли.
Само по себе си това не е достатъчно за обработка на цялото четене след -write проблеми, но за щастие можете да използвате променливата wsrep-sync-wait, която може да се използва, за да се гарантира, че проверките за причинно-следствена връзка са на място и клъстерът се държи като истински синхронен клъстер. Използването на тази настройка ще ви позволи да четете безопасно от всичките си възли на Galera.
Разбира се, налагането на проверки за причинно-следствена връзка ще повлияе на производителността на Galera, но все пак има смисъл, тъй като можете да се възползвате от четенето от множество възли на Galera едновременно. От този момент мащабирането на четенията с клъстера Galera е доста лесно - просто добавяте още възли на Galera към клъстера. Load Balancer трябва да бъде преконфигуриран, за да ги вземе и да използва като допълнителна цел за четенията, което ви позволява да разширите до дори 10+ възела за четене.
Трябва да имате предвид, че добавянето на допълнителни възли, репликация или Galera, това всъщност няма значение, добавя известна сложност към операциите в клъстера. Трябва да се уверите, че вашите възли се наблюдават правилно, че резервните копия работят, репликацията се изпълнява правилно и че самият клъстер е в правилно състояние. За среди за репликация преодоляването на отказ трябва да се обработва по един или друг начин и както за Galera, така и за репликация може да искате да можете да възстановите възлите в клъстера, ако откриете някакъв вид несъответствие на данните в клъстера. За щастие ClusterControl може значително да ви помогне да се справите с тези предизвикателства.
Как ClusterControl помага за управление на клъстера с база данни на Moodle MySQL
На първо място, ако целият клъстер се срине, ClusterControl ще извърши автоматизирано възстановяване на клъстер - докато всички възли са налични, ClusterControl ще стартира процеса на възстановяване на клъстера:
След известно време целият клъстер трябва да бъде отново онлайн.
ClusterControl се предлага с набор от опции за управление:
Можете да намалите мащаба на клъстера, като добавите възли или подчинени устройства за репликация. Можете дори да създадете цял подчинен клъстер, който ще се репликира извън основния клъстер.
Възможно е лесно да настроите график за архивиране, който да се изпълнява от ClusterControl. Можете дори да настроите автоматично потвърждаване на архивиране.
Вероятно искате да можете да наблюдавате своя клъстер от база данни. ClusterControl ви позволява да направите точно това:
Както можете да видите, ClusterControl е страхотна платформа, която може да се използва за намаляване на сложността на мащабиране и управление на базата данни Moodle MySQL. Ще се радваме да чуем за вашия опит с мащабирането на Moodle и в частност неговата база данни.
