Moodle, un sistema di gestione dell'apprendimento open source, è diventato sempre più popolare lo scorso anno quando la pandemia ha costretto a un blocco rigido e la maggior parte delle attività educative si è spostata da scuole, college e università alle piattaforme online. Con esso, è stata esercitata una pressione sui team IT per garantire che quelle piattaforme online saranno in grado di sopportare un carico molto più elevato di quello a cui erano abituati. Sono state sollevate domande:come è possibile ridimensionare una piattaforma Moodle per gestire l'aumento del carico? Da un lato, ridimensionare l'applicazione stessa non è un'impresa difficile da realizzare, ma il database, dall'altro, è un animale diverso. I database, come tutti i servizi con stato, sono notoriamente difficili da scalare. In questo post del blog vorremmo discutere alcune sfide che dovrai affrontare durante il ridimensionamento di un database Moodle.
Ridimensionamento del database Moodle - La sfida
La principale fonte di problemi è l'eredità:Moodle, proprio come molti database, proviene da un unico background di database e, come tale, presenta alcune aspettative legate a tale ambiente. Quello tipico è che puoi eseguire una transazione dopo l'altra e la seconda transazione vedrà sempre il risultato della prima. Questo non è necessariamente il caso nella maggior parte degli ambienti di database distribuiti. La replica asincrona non fa promesse. Qualsiasi transazione potrebbe andare persa nel processo. È sufficiente che il master si arresti in modo anomalo prima che i dati della transazione vengano trasferiti agli slave. La replica semisincrona offre la promessa della sicurezza dei dati ma non promette nient'altro. Gli slave possono ancora essere in ritardo e anche se i dati sono archiviati nella memoria permanente come registro di inoltro e, alla fine, verranno applicati al set di dati, ciò non significa che siano già stati applicati. Puoi interrogare i tuoi slave e non vedere i dati che hai appena scritto sul master.
Anche i cluster come Galera per impostazione predefinita non vengono forniti con la replica sincrona:il divario è notevolmente ridotto rispetto ai sistemi di replica ma è ancora presente e SELECT immediato eseguito dopo una precedente scrittura potrebbe non visualizzare il dati che hai appena archiviato nel database perché il tuo SELECT è stato instradato a un nodo Galera diverso dalla tua scrittura precedente.
Esistono diverse soluzioni alternative che puoi utilizzare per ridimensionare il database MySQL di Moodle. Per cominciare, se utilizzi l'impostazione della replica, puoi utilizzare la funzione "letture sicure" di Moodle. Ne abbiamo parlato in uno dei nostri blog precedenti. Ciò porterà alla situazione in cui Moodle deciderà quali scritture verranno distribuite tra gli schiavi e quali colpiranno il padrone.
Da un lato va bene:puoi usare più slave collegati al master, consentendoti di scaricare il master almeno in una certa misura. D'altra parte, è tutt'altro che ideale, perché è solo un sottoinsieme di SELECT che potrai inviare agli slave. Naturalmente, tutto dipende dal caso esatto, ma puoi aspettarti che il master rimarrà un collo di bottiglia per quanto riguarda il carico.
Un approccio alternativo potrebbe essere quello di utilizzare il Galera Cluster e distribuire il carico in modo uniforme su tutti i nodi.
Di per sé questo non è sufficiente per gestire tutto il read-after -write issues ma fortunatamente puoi usare la variabile wsrep-sync-wait che può essere usata per garantire che i controlli di causalità siano in atto e il cluster si comporti come un vero cluster sincrono. L'utilizzo di questa impostazione ti consentirà di leggere in sicurezza da tutti i tuoi nodi Galera.
Ovviamente, l'applicazione dei controlli di causalità avrà un impatto sulle prestazioni di Galera, ma ha comunque senso in quanto puoi trarre vantaggio dalla lettura di più nodi Galera contemporaneamente. Da quel momento, ridimensionare le letture con il cluster Galera è abbastanza semplice:basta aggiungere più nodi Galera al cluster. Load Balancer deve essere riconfigurato per raccoglierli e utilizzarli come destinazione aggiuntiva per le letture, consentendoti di scalare fino a oltre 10 nodi di lettura.
Devi tenere presente che l'aggiunta di nodi aggiuntivi, replica o Galera, non ha molta importanza, aggiunge una certa complessità alle operazioni sul cluster. Devi assicurarti che i tuoi nodi siano monitorati correttamente, che i backup funzionino, che la replica funzioni correttamente e che il cluster stesso sia in uno stato corretto. Per gli ambienti di replica il failover deve essere gestito in un modo o nell'altro e sia per Galera che per la replica potresti voler ricostruire i nodi nel cluster se rilevi qualsiasi tipo di incoerenza dei dati nel cluster. Fortunatamente, ClusterControl può aiutarti in modo significativo a gestire queste sfide.
Come ClusterControl aiuta a gestire il cluster di database Moodle MySQL
Prima di tutto, se l'intero cluster crolla, ClusterControl eseguirà un ripristino del cluster:finché tutti i nodi saranno disponibili, ClusterControl avvierà il processo di ripristino del cluster:
Dopo un po' di tempo, l'intero cluster dovrebbe essere di nuovo online.
ClusterControl viene fornito con una serie di opzioni di gestione:
Puoi scalare il cluster aggiungendo nodi o slave di replica. Puoi persino creare un intero cluster slave che verrà replicato dal cluster principale.
È possibile impostare facilmente una pianificazione di backup che verrà eseguita da ClusterControl. Puoi persino impostare la verifica di backup automatica.
Probabilmente vuoi essere in grado di monitorare il tuo cluster di database. ClusterControl ti permette di fare proprio questo:
Come puoi vedere, ClusterControl è un'ottima piattaforma che può essere utilizzata per ridurre la complessità del ridimensionamento e della gestione del database Moodle MySQL. Ci piacerebbe conoscere la tua esperienza con la scalabilità orizzontale di Moodle e del suo database in particolare.
