Moodle, un sistema de gestión de aprendizaje de código abierto, se hizo cada vez más popular el año pasado, ya que la pandemia obligó a realizar confinamientos estrictos y la mayoría de las actividades educativas se trasladaron de escuelas, institutos y universidades a plataformas en línea. Con esto, se ejerció presión sobre los equipos de TI para garantizar que esas plataformas en línea puedan acomodar una carga mucho mayor de la que solían experimentar. Han surgido preguntas:¿cómo se puede escalar una plataforma Moodle para manejar el aumento de carga? Por un lado, escalar la aplicación en sí no es una hazaña difícil de lograr, pero la base de datos, por otro lado, es un animal diferente. Las bases de datos, como todos los servicios con estado, son notoriamente difíciles de escalar. En esta publicación de blog, nos gustaría analizar algunos desafíos que enfrentará al escalar una base de datos de Moodle.
Ampliar la base de datos de Moodle:el desafío
La principal fuente de problemas es la herencia:Moodle, al igual que muchas bases de datos, proviene de una sola base de datos y, como tal, viene con algunas expectativas relacionadas con dicho entorno. La típica es que puedes ejecutar una transacción tras otra y la segunda transacción siempre verá el resultado de la primera. Este no es necesariamente el caso en la mayoría de los entornos de bases de datos distribuidas. La replicación asíncrona no hace promesas. Cualquier transacción puede perderse en el proceso. Es suficiente que el maestro se bloquee antes de que los datos de la transacción se transfieran a los esclavos. La replicación semisincrónica ofrece la promesa de seguridad de los datos, pero no promete nada más. Los esclavos aún pueden estar rezagados y, aunque los datos se almacenan en un almacenamiento persistente como un registro de retransmisión y, eventualmente, se aplicarán al conjunto de datos, eso no significa que ya se hayan aplicado. Puede consultar a sus esclavos y no ver los datos que acaba de escribir en el maestro.
Incluso los clústeres como Galera por defecto no vienen con la replicación verdaderamente sincrónica:la brecha se reduce significativamente en comparación con los sistemas de replicación, pero aún está allí y la SELECCIÓN inmediata ejecutada después de una escritura anterior puede no ver el datos que acaba de almacenar en la base de datos porque su SELECT se enrutó a un nodo de Galera diferente al de su escritura anterior.
Hay varias soluciones alternativas que puede usar para escalar la base de datos MySQL de Moodle. Para empezar, si usa la configuración de replicación, puede usar la función de "lecturas seguras" de Moodle. Lo cubrimos en uno de nuestros blogs anteriores. Esto conducirá a la situación en la que Moodle decidirá qué escrituras se distribuirán entre los esclavos y cuáles llegarán al maestro.
Por un lado, es bueno:es seguro usar varios esclavos conectados al maestro, lo que le permite descargar el maestro al menos hasta cierto punto. Por otro lado, está lejos de ser ideal, porque es solo un subconjunto de SELECT que podrá enviar a los esclavos. Por supuesto, todo depende del caso exacto, pero puede esperar que el maestro siga siendo un cuello de botella con respecto a la carga.
Un enfoque alternativo podría ser usar Galera Cluster y distribuir la carga de manera uniforme en todos los nodos.
Por sí solo, esto no es suficiente para manejar todas las lecturas posteriores -problemas de escritura, pero afortunadamente puede usar la variable wsrep-sync-wait que se puede usar para garantizar que las verificaciones de causalidad estén en su lugar y que el clúster se comporte como un clúster síncrono real. El uso de esta configuración le permitirá leer de forma segura desde todos sus nodos de Galera.
Por supuesto, hacer cumplir las verificaciones de causalidad afectará el rendimiento de Galera, pero aún tiene sentido, ya que puede beneficiarse de la lectura de varios nodos de Galera al mismo tiempo. A partir de ese momento, escalar las lecturas con Galera Cluster es bastante fácil:solo agrega más nodos de Galera al clúster. Load Balancer debe reconfigurarse para recogerlos y usarlos como un objetivo adicional para las lecturas, lo que le permite escalar hasta más de 10 nodos de lectura.
Debe tener en cuenta que agregar nodos adicionales, replicación o Galera, en realidad no importa, agrega cierta complejidad a las operaciones en el clúster. Debe asegurarse de que sus nodos estén monitoreados correctamente, que tenga copias de seguridad funcionando, que la replicación funcione correctamente y que el clúster en sí esté en un estado correcto. Para los entornos de replicación, la conmutación por error debe manejarse de una forma u otra y, tanto para Galera como para la replicación, es posible que desee poder reconstruir los nodos en el clúster si detecta algún tipo de inconsistencia de datos en todo el clúster. Afortunadamente, ClusterControl puede ayudarlo significativamente a manejar esos desafíos.
Cómo ayuda ClusterControl a administrar el clúster de base de datos MySQL de Moodle
En primer lugar, si todo el clúster colapsa, ClusterControl realizará un recuperación del clúster:siempre que todos los nodos estén disponibles, ClusterControl iniciará el proceso de recuperación del clúster:
Después de un tiempo, todo el clúster debería volver a estar en línea.
ClusterControl viene con un conjunto de opciones de administración:
Puede escalar horizontalmente el clúster agregando nodos o esclavos de replicación. Incluso puede crear un clúster esclavo completo que se replicará fuera del clúster principal.
Es posible configurar fácilmente un programa de copia de seguridad que será ejecutado por ClusterControl. Incluso puede configurar la verificación automática de copias de seguridad.
Probablemente desee poder monitorear su clúster de base de datos. ClusterControl le permite hacer precisamente eso:
Como puede ver, ClusterControl es una gran plataforma que puede usarse para reducir la complejidad de escalar y administrar la base de datos Moodle MySQL. Nos encantaría conocer su experiencia con la ampliación de Moodle y su base de datos en particular.
