Moodle, system zarządzania nauką o otwartym kodzie źródłowym, stał się coraz bardziej popularny w zeszłym roku, gdy pandemia wymusiła twarde blokady, a większość działań edukacyjnych przeniesiono ze szkół, uczelni i uniwersytetów na platformy internetowe. Dzięki temu wywarto nacisk na zespoły IT, aby upewnić się, że te platformy internetowe będą w stanie obsłużyć znacznie większe obciążenie niż kiedyś. Pojawiły się pytania - jak można skalować platformę Moodle, aby poradzić sobie ze zwiększonym obciążeniem? Z jednej strony skalowanie samej aplikacji nie jest trudnym zadaniem, ale z drugiej strony baza danych to zupełnie inne zwierzę. Bazy danych, podobnie jak wszystkie usługi stanowe, są bardzo trudne do skalowania. W tym poście na blogu chcielibyśmy omówić niektóre wyzwania, przed którymi staniesz podczas skalowania bazy danych Moodle.
Skalowanie bazy danych Moodle – Wyzwanie
Głównym źródłem problemów jest dziedzictwo - Moodle, podobnie jak wiele baz danych, wywodzi się z jednej bazy danych i jako taki ma pewne oczekiwania, które są związane z takim środowiskiem. Typowe jest to, że możesz wykonać jedną transakcję po drugiej, a druga transakcja zawsze będzie widzieć wynik pierwszej. Niekoniecznie tak jest w większości środowisk rozproszonych baz danych. Replikacja asynchroniczna nie daje żadnych obietnic. Każda transakcja może zostać utracona w procesie. Wystarczy, że master się zawiesi, zanim dane transakcyjne zostaną przesłane do slave'ów. Replikacja półsynchroniczna zapewnia bezpieczeństwo danych, ale nie obiecuje niczego innego. Urządzenia podrzędne mogą nadal pozostawać w tyle i chociaż dane są przechowywane w pamięci trwałej jako dziennik przekaźnika i ostatecznie zostaną zastosowane do zestawu danych, nadal nie oznacza to, że zostały już zastosowane. Możesz wysyłać zapytania do swoich niewolników i nie widzieć danych, które właśnie zapisałeś do urządzenia głównego.
Nawet klastry takie jak Galera domyślnie nie są wyposażone w prawdziwie synchroniczną replikację — różnica jest znacznie zmniejszona w porównaniu z systemami replikacji, ale nadal istnieje i natychmiastowy SELECT wykonany po poprzednim zapisie może nie widzieć dane, które właśnie zapisałeś w bazie danych, ponieważ Twój SELECT został przekierowany do innego węzła Galera niż poprzedni zapis.
Istnieje kilka obejść, których można użyć do skalowania bazy danych Moodle MySQL. Na początek, jeśli używasz konfiguracji replikacji, możesz użyć funkcji „bezpiecznych odczytów” z Moodle. Omówiliśmy to na jednym z naszych poprzednich blogów. Doprowadzi to do sytuacji, w której Moodle zdecyduje, które zapisy zostaną rozdzielone na niewolników, a które trafią do głównego.
Z jednej strony jest dobrze - możesz bezpiecznie używać kilku podłączonych niewolników do mistrza, co pozwala przynajmniej do pewnego stopnia odciążyć mistrza. Z drugiej strony jest daleki od ideału, ponieważ jest to tylko podzbiór SELECTów, które będziesz mógł wysłać do niewolników. Oczywiście wszystko zależy od konkretnego przypadku, ale można się spodziewać, że kapitan pozostanie wąskim gardłem w odniesieniu do ładunku.
Alternatywne podejście mogłoby polegać na użyciu klastra Galera i równomiernym rozłożeniu obciążenia na wszystkie węzły.
Samo w sobie to nie wystarczy, aby obsłużyć wszystkie -write problemy, ale na szczęście można użyć zmiennej wsrep-sync-wait, której można użyć, aby upewnić się, że kontrole przyczynowości są na miejscu, a klaster zachowuje się jak prawdziwy klaster synchroniczny. Użycie tego ustawienia pozwoli Ci bezpiecznie czytać ze wszystkich węzłów Galera.
Oczywiście wymuszanie sprawdzania związku przyczynowego wpłynie na wydajność Galera, ale nadal ma to sens, ponieważ możesz czerpać korzyści z czytania z wielu węzłów Galera w tym samym czasie. Od tego momentu skalowanie odczytów za pomocą klastra Galera jest dość łatwe — wystarczy dodać więcej węzłów Galera do klastra. Load Balancer powinien zostać ponownie skonfigurowany, aby mógł je pobrać i wykorzystać jako dodatkowy cel dla odczytów, umożliwiając skalowanie nawet do ponad 10 węzłów czytników.
Trzeba pamiętać, że dodawanie dodatkowych węzłów, replikacji czy Galery, to nie ma większego znaczenia, dodaje trochę komplikacji do operacji na klastrze. Musisz upewnić się, że Twoje węzły są prawidłowo monitorowane, masz działające kopie zapasowe, replikacja działa prawidłowo i sam klaster jest w prawidłowym stanie. W przypadku środowisk replikacji przełączanie awaryjne musi być obsługiwane w taki czy inny sposób, a zarówno w przypadku Galera, jak i replikacji może zaistnieć potrzeba odbudowania węzłów w klastrze w przypadku wykrycia jakiejkolwiek niespójności danych w klastrze. Na szczęście ClusterControl może znacznie pomóc w radzeniu sobie z tymi wyzwaniami.
Jak ClusterControl pomaga zarządzać klastrem bazy danych Moodle MySQL
Po pierwsze, jeśli cały klaster upadnie, ClusterControl wykona automatyczną odzyskiwanie klastra - tak długo, jak wszystkie węzły będą dostępne, ClusterControl rozpocznie proces odzyskiwania klastra:
Po pewnym czasie cały klaster powinien być z powrotem online.
ClusterControl zawiera zestaw opcji zarządzania:
Możesz skalować klaster, dodając węzły lub jednostki podrzędne replikacji. Możesz nawet utworzyć cały klaster podrzędny, który będzie replikowany poza klaster główny.
Można łatwo skonfigurować harmonogram tworzenia kopii zapasowych, który będzie wykonywany przez ClusterControl. Możesz nawet skonfigurować automatyczną weryfikację kopii zapasowej.
Prawdopodobnie chcesz mieć możliwość monitorowania klastra bazy danych. ClusterControl umożliwia właśnie to:
Jak widać, ClusterControl to świetna platforma, której można użyć do zmniejszenia złożoności skalowania i zarządzania bazą danych Moodle MySQL. Chcielibyśmy usłyszeć o Twoich doświadczeniach ze skalowaniem Moodle i jego bazy danych w szczególności.
