Moodle, een open source leerbeheersysteem, werd het afgelopen jaar steeds populairder toen de pandemie harde lockdowns dwong en de meeste onderwijsactiviteiten zijn verplaatst van scholen, hogescholen en universiteiten naar online platforms. Hiermee werd druk uitgeoefend op de IT-teams om ervoor te zorgen dat die online platforms een veel hogere belasting aankunnen dan vroeger. Er zijn vragen gerezen - hoe kan een Moodle-platform worden geschaald om de toegenomen belasting aan te kunnen? Aan de ene kant is het schalen van de applicatie zelf niet moeilijk, maar database aan de andere kant is een ander dier. Databases zijn, net als alle stateful services, notoir moeilijk uit te schalen. In deze blogpost willen we enkele uitdagingen bespreken waarmee u te maken krijgt bij het schalen van een Moodle-database.
Moodle-database schalen - De uitdaging
De belangrijkste bron van problemen is het erfgoed - Moodle komt, net als veel andere databases, voort uit een enkele database-achtergrond en als zodanig komt het met enkele verwachtingen die verband houden met een dergelijke omgeving. De typische is dat u de ene transactie na de andere kunt uitvoeren en dat de tweede transactie altijd het resultaat van de eerste zal zien. Dit is niet noodzakelijk het geval in de meeste gedistribueerde databaseomgevingen. Asynchrone replicatie belooft niets. Elke transactie kan verloren gaan in het proces. Het is voldoende dat de master crasht voordat de transactiegegevens worden overgedragen aan slaves. Semisynchrone replicatie biedt de belofte van gegevensveiligheid, maar belooft niets anders. Slaven kunnen nog steeds achterblijven en hoewel de gegevens op permanente opslag worden opgeslagen als een relaislogboek en uiteindelijk worden toegepast op de dataset, betekent dit nog niet dat het al is toegepast. U kunt uw slaven opvragen en de gegevens die u zojuist naar de master hebt geschreven niet zien.
Zelfs clusters zoals Galera worden standaard niet geleverd met de echt synchrone replicatie - de kloof is aanzienlijk kleiner in vergelijking met de replicatiesystemen, maar het is er nog steeds en onmiddellijke SELECT uitgevoerd na een eerdere schrijfbewerking ziet mogelijk niet de gegevens die u zojuist in de database hebt opgeslagen omdat uw SELECT naar een ander Galera-knooppunt is gerouteerd dan uw vorige schrijfactie.
Er zijn verschillende tijdelijke oplossingen die u kunt gebruiken om de Moodle MySQL-database te schalen. Om te beginnen, als je replicatie-instellingen gebruikt, kun je de functie "veilig lezen" van Moodle gebruiken. Daar hebben we het in een van onze vorige blogs over gehad. Dit zal ertoe leiden dat Moodle beslist welke schrijfacties over de slaven worden verdeeld en welke de master raken.
Aan de ene kant is het goed - u kunt veilig meerdere aangesloten slaves gebruiken naar de master, zodat je de master in ieder geval tot op zekere hoogte kunt ontlasten. Aan de andere kant is het verre van ideaal, omdat het slechts een subset van SELECT's is die je naar de slaven kunt sturen. Het hangt natuurlijk allemaal af van het exacte geval, maar je kunt verwachten dat de master een bottleneck blijft met betrekking tot de belasting.
Een alternatieve benadering zou kunnen zijn om de Galera-cluster te gebruiken en de belasting gelijkmatig over alle knooppunten te verdelen.
Op zichzelf is dit niet genoeg om alle lees-na -schrijfproblemen, maar gelukkig kun je de wsrep-sync-wait-variabele gebruiken die kan worden gebruikt om ervoor te zorgen dat de causaliteitscontroles zijn uitgevoerd en dat het cluster zich gedraagt als een echt synchrone cluster. Als u deze instelling gebruikt, kunt u veilig lezen vanaf al uw Galera-knooppunten.
Natuurlijk heeft het afdwingen van causaliteitscontroles invloed op de Galera-prestaties, maar het is nog steeds logisch omdat u kunt profiteren van het lezen van meerdere Galera-knooppunten tegelijk. Vanaf dat moment is het schalen van lezen met de Galera-cluster vrij eenvoudig - u voegt gewoon meer Galera-knooppunten toe aan de cluster. Load Balancer moet opnieuw worden geconfigureerd om ze op te pikken en te gebruiken als een extra doel voor de uitlezingen, zodat u kunt uitschalen naar zelfs 10+ lezerknooppunten.
Je moet er rekening mee houden dat het toevoegen van extra nodes, replicatie of Galera, het maakt niet echt uit, enige complexiteit toevoegt aan de operaties op het cluster. U moet ervoor zorgen dat uw nodes goed worden bewaakt, dat de back-ups werken, dat de replicatie goed werkt en dat het cluster zelf in de juiste staat is. Voor replicatieomgevingen moet failover op de een of andere manier worden afgehandeld en voor zowel Galera als replicatie wilt u misschien de knooppunten in het cluster opnieuw kunnen opbouwen als u enige vorm van inconsistentie in de gegevens in het cluster ontdekt. Gelukkig kan ClusterControl je aanzienlijk helpen om die uitdagingen aan te gaan.
Hoe ClusterControl helpt bij het beheren van het Moodle MySQL-databasecluster
Ten eerste, als het hele cluster instort, zal ClusterControl een geautomatiseerd clusterherstel - zolang alle knooppunten beschikbaar zijn, start ClusterControl het clusterherstelproces:
Na een tijdje zou het hele cluster weer online moeten zijn.
ClusterControl wordt geleverd met een reeks beheeropties:
U kunt het cluster uitschalen door knooppunten of replicatieslaves toe te voegen. Je kunt zelfs een hele slave-cluster maken die van de hoofdcluster wordt gerepliceerd.
Het is mogelijk om eenvoudig een back-upschema in te stellen dat door ClusterControl wordt uitgevoerd. U kunt zelfs automatische back-upverificatie instellen.
U wilt waarschijnlijk uw databasecluster kunnen controleren. Met ClusterControl kunt u precies dat doen:
Zoals u kunt zien, is ClusterControl een geweldig platform dat kan worden gebruikt om de complexiteit van het schalen en beheren van de Moodle MySQL-database te verminderen. We horen graag wat je ervaring is met het uitschalen van de Moodle en zijn database in het bijzonder.