Mysql
 sql >> Base de données >  >> RDS >> Mysql

Défis de la mise à l'échelle de la base de données MySQL Moodle

Moodle, un système de gestion de l'apprentissage open source, est devenu de plus en plus populaire l'année dernière alors que la pandémie a forcé des fermetures strictes et que la majorité des activités éducatives sont passées des écoles, des collèges et des universités aux plateformes en ligne. Avec cela, une pression a été exercée sur les équipes informatiques pour s'assurer que ces plates-formes en ligne seront en mesure de supporter une charge beaucoup plus élevée qu'auparavant. Des questions ont été soulevées - comment une plate-forme Moodle peut-elle être mise à l'échelle pour gérer la charge accrue ? D'une part, la mise à l'échelle de l'application elle-même n'est pas une tâche difficile à accomplir, mais la base de données, d'autre part, est un animal différent. Les bases de données, comme tous les services avec état, sont notoirement difficiles à faire évoluer. Dans cet article de blog, nous aimerions discuter de certains défis auxquels vous serez confrontés lors de la mise à l'échelle d'une base de données Moodle.

Mise à l'échelle de la base de données Moodle - Le défi

La principale source de problèmes est l'héritage - Moodle, tout comme de nombreuses bases de données, provient d'un arrière-plan de base de données unique et, en tant que tel, il s'accompagne de certaines attentes liées à un tel environnement. Le plus typique est que vous pouvez exécuter une transaction après l'autre et la deuxième transaction verra toujours le résultat de la première. Ce n'est pas nécessairement le cas dans la plupart des environnements de bases de données distribuées. La réplication asynchrone ne fait aucune promesse. Toute transaction peut se perdre dans le processus. Il suffit que le maître tombe en panne avant que les données de transaction ne soient transférées aux esclaves. La réplication semi-synchrone apporte la promesse de la sécurité des données, mais elle ne promet rien d'autre. Les esclaves peuvent encore être à la traîne et même si les données sont stockées sur un stockage persistant en tant que journal de relais et, éventuellement, elles seront appliquées à l'ensemble de données, cela ne signifie toujours pas qu'elles ont déjà été appliquées. Vous pouvez interroger vos esclaves et ne pas voir les données que vous venez d'écrire sur le maître.

Même les clusters comme Galera par défaut ne sont pas livrés avec la réplication véritablement synchrone - l'écart est considérablement réduit par rapport aux systèmes de réplication mais il est toujours là et un SELECT immédiat exécuté après une écriture précédente peut ne pas voir le les données que vous venez de stocker dans la base de données car votre SELECT a été acheminé vers un nœud Galera différent de celui de votre écriture précédente.

Il existe plusieurs solutions de contournement que vous pouvez utiliser pour mettre à l'échelle la base de données Moodle MySQL. Pour commencer, si vous utilisez la configuration de la réplication, vous pouvez utiliser la fonction "lectures sécurisées" de Moodle. Nous en avons parlé dans l'un de nos blogs précédents. Cela conduira à la situation dans laquelle Moodle décidera quelles écritures seront réparties entre les esclaves et lesquelles frapperont le maître.

D'une part, c'est bien - vous pouvez utiliser plusieurs esclaves attachés en toute sécurité au maître, vous permettant de décharger le maître dans une certaine mesure au moins. D'un autre côté, c'est loin d'être idéal, car ce n'est qu'un sous-ensemble de SELECT que vous pourrez envoyer aux esclaves. Bien sûr, tout dépend du cas précis mais vous pouvez vous attendre à ce que le maître reste un goulot d'étranglement concernant la charge.

Une autre approche pourrait consister à utiliser le cluster Galera et à répartir la charge uniformément sur tous les nœuds.

En soi, cela ne suffit pas pour gérer toute la lecture après - problèmes d'écriture mais heureusement, vous pouvez utiliser la variable wsrep-sync-wait qui peut être utilisée pour s'assurer que les contrôles de causalité sont en place et que le cluster se comporte comme un véritable cluster synchrone. L'utilisation de ce paramètre vous permettra de lire en toute sécurité à partir de tous vos nœuds Galera.

Bien sûr, l'application de contrôles de causalité aura un impact sur les performances de Galera, mais cela reste logique car vous pouvez bénéficier de la lecture à partir de plusieurs nœuds Galera en même temps. À partir de là, la mise à l'échelle des lectures avec le cluster Galera est assez simple - il vous suffit d'ajouter plus de nœuds Galera au cluster. L'équilibreur de charge doit être reconfiguré pour les récupérer et les utiliser comme cible supplémentaire pour les lectures, ce qui vous permet d'évoluer jusqu'à plus de 10 nœuds de lecteur.

Vous devez garder à l'esprit que l'ajout de nœuds supplémentaires, de réplication ou de Galera, peu importe, ajoute une certaine complexité aux opérations sur le cluster. Vous devez vous assurer que vos nœuds sont correctement surveillés, que vos sauvegardes fonctionnent, que la réplication s'exécute correctement et que le cluster lui-même est dans un état correct. Pour les environnements de réplication, le basculement doit être géré d'une manière ou d'une autre et pour Galera et la réplication, vous souhaiterez peut-être pouvoir reconstruire les nœuds du cluster si vous détectez un type d'incohérence de données dans le cluster. Heureusement, ClusterControl peut vous aider de manière significative à relever ces défis.

Comment ClusterControl aide à gérer le cluster de bases de données MySQL Moodle

Tout d'abord, si tout le cluster s'effondre, ClusterControl effectuera une récupération du cluster - tant que tous les nœuds seront disponibles, ClusterControl lancera le processus de récupération du cluster :

Après un peu de temps, tout le cluster devrait être de nouveau en ligne.

ClusterControl est livré avec un ensemble d'options de gestion :

Vous pouvez faire évoluer le cluster en ajoutant des nœuds ou des esclaves de réplication. Vous pouvez même créer un cluster esclave complet qui se répliquera à partir du cluster principal.

 Il est possible de configurer facilement un calendrier de sauvegarde qui sera exécuté par ClusterControl. Vous pouvez même configurer la vérification automatique des sauvegardes.

Vous souhaitez probablement pouvoir surveiller votre cluster de bases de données. C'est exactement ce que vous permet ClusterControl :

Comme vous pouvez le voir, ClusterControl est une excellente plate-forme qui peut être utilisée pour réduire la complexité de la mise à l'échelle et de la gestion de la base de données Moodle MySQL. Nous aimerions connaître votre expérience avec la mise à l'échelle de Moodle et de sa base de données en particulier.