2 enero, 2026
optimizar la tabla mdl_logstore_standard_log en Moodle sin romper tu plataforma educativa

Si administras una plataforma Moodle, tarde o temprano te encontrarás con el mismo problema: la base de datos crece y crece hasta llenar tu servidor. Una de las tablas más “glotonas” suele ser mdl_logstore_standard_log, responsable de almacenar el registro de actividades de todo el sitio.
La buena noticia: puedes reducir su tamaño sin perder la funcionalidad de Moodle y, de paso, aprender algo muy valioso para tu camino en la tecnología educativa y el aprendizaje autodidacta.


¿Qué es la tabla mdl_logstore_standard_log en Moodle y por qué crece tanto?

El “historial de eventos” de tu Moodle la tabla mdl_logstore_standard_log

La tabla mdl_logstore_standard_log pertenece al Standard log store de Moodle. Cada vez que alguien:

  • entra a un curso,
  • ve un recurso,
  • envía una tarea,
  • realiza un intento de cuestionario,
  • inicia sesión o cambia una configuración,

Moodle registra un evento en esta tabla.

Entre sus campos más importantes encontrarás:

  • eventname: tipo de evento (por ejemplo, ver curso, login, envío de tarea).
  • userid: quién realizó la acción.
  • courseid: en qué curso se produjo el evento.
  • timecreated: cuándo ocurrió.
  • ip, origin, other: datos adicionales sobre el contexto.

Todo esto se almacena físicamente en el archivo InnoDB mdl_logstore_standard_log.ibd, que puede crecer a muchos GB si no se controla.

Por qué puede convertirse en un problema la tabla mdl_logstore_standard_log en Moodle

En un sitio con muchos usuarios, cursos y años de uso continuo, esta tabla puede llegar a decenas o incluso cientos de gigabytes.
Las consecuencias:

  • Respaldo de la base de datos más lento.
  • Restauraciones pesadas y poco prácticas.
  • Falta de espacio en disco.
  • Operaciones como OPTIMIZE o ALTER TABLE que fallan porque “la tabla está llena” o no hay espacio suficiente.

Lo importante: esta tabla no almacena cursos, usuarios ni calificaciones, solo el historial de eventos. Por lo tanto, puedes limpiar registros antiguos sin romper la esencia de tu plataforma.


Primer paso: definir una política de retención de logs en Moodle refirendose a la tabla mdl_logstore_standard_log

Ajustar “Keep logs for” en el Standard log en Moodle

Antes de hacer limpieza manual, es fundamental evitar que el problema se repita. Desde la administración de Moodle:

  1. Ve a Administración del sitio → Plugins → Logging → Standard log.
  2. Busca la opción “Keep logs for” (Mantener logs durante).
  3. Elige una retención razonable, por ejemplo:
    • 90 días para sitios muy activos donde solo necesitas trazabilidad reciente.
    • 180 o 365 días para instituciones que requieren algo más de histórico.

Con esto, Moodle se encargará de ir borrando automáticamente los registros que superen ese tiempo, mediante su tarea programada de limpieza.

Revisar las tareas programadas (cron)

La retención solo funciona si el cron está bien configurado. En:

  • Administración del sitio → Servidor → Tareas programadas (Scheduled tasks)

comprueba que la tarea de limpieza de logs (por ejemplo logstore_standard\task\cleanup_task) esté:

  • Habilitada,
  • Ejecutándose con regularidad (consulta “Última ejecución”),
  • Sin errores recientes.

Esta combinación (retención + tareas programadas) es la base de un Moodle sostenible a largo plazo.


Cuando la tabla ya es gigante: estrategias de limpieza en la base de datos de la tabla mdl_logstore_standard_log en Moodle

Aunque configures bien la retención, puede que ya tengas una tabla monstruosa. Entonces toca actuar desde la base de datos (MySQL o MariaDB).

Borrar por rango de fechas con cuidado

La idea general es eliminar registros muy antiguos que ya no necesitas, por ejemplo todos los anteriores a cierta fecha.
En lugar de lanzar un DELETE masivo (que puede provocar errores como “The total number of locks exceeds the lock table size”), es mejor borrar por bloques pequeños usando LIMIT y ejecutando la sentencia varias veces, por ejemplo:

DELETE FROM mdl_logstore_standard_log
WHERE timecreated < UNIX_TIMESTAMP('2025-01-01')
ORDER BY timecreated
LIMIT 500;

Repite esta sentencia hasta que ya no se borren filas.
Si 500 filas siguen causando problemas, reduce el número a 200 o incluso 100. Lo importante es que cada operación sea ligera y se confirme sola (con autocommit=1).

Consejo de seguridad:

  • Haz un respaldo de la base de datos antes de cualquier borrado masivo.
  • Procura ejecutar estas operaciones en horarios de baja actividad (por la noche o en fin de semana).
  • Si es posible, habilita el modo mantenimiento en Moodle mientras haces limpieza.

Cómo enfrentar el error de “demasiados locks” (ERROR 1206)

Si recibes un error del tipo:

ERROR 1206 (HY000): The total number of locks exceeds the lock table size

significa que la operación está intentando bloquear más filas de las que InnoDB puede manejar con su configuración actual.

Algunas acciones que ayudan:

  • Asegurarte de que no estás dentro de una transacción enorme:
    • Ejecuta ROLLBACK; y SET autocommit = 1; antes de seguir.
  • Reducir el tamaño del bloque (LIMIT 100 en lugar de 1000).
  • Evitar sentencias demasiado complejas con subconsultas anidadas sobre la misma tabla.

El objetivo es que cada DELETE sea una operación “pequeña y digerible” para el motor de la base de datos.


Recuperar el espacio: de “Residuo a depurar” a tabla optimizada

Aunque borres millones de filas, puede que sigas viendo en herramientas como phpMyAdmin un campo llamado “Residuo a depurar” de muchos GB.
Esto significa que:

  • Las filas se borraron lógicamente,
  • Pero el espacio que ocupaban en el archivo .ibd sigue reservado.

OPTIMIZE TABLE… y sus límites

El comando clásico para “compactar” y recuperar espacio es:

OPTIMIZE TABLE mdl_logstore_standard_log;

En InnoDB, esto recrea la tabla y puede liberar gran parte del residuo. Sin embargo, para funcionar necesita espacio temporal adicional en disco. En tablas muy grandes y discos casi llenos, puede fallar con mensajes como:

  • “The table ‘mdl_logstore_standard_log’ is full”
  • “Operation failed”

En esos casos, la estrategia tiene que ser más radical.

TRUNCATE: empezar de cero con los logs

Si tu institución no requiere conservar el historial de eventos (o puedes hacer un respaldo aparte del histórico), la opción más simple es vaciar la tabla:

  1. Habilita el modo mantenimiento en Moodle.
  2. Ejecuta en la base de datos: TRUNCATE TABLE mdl_logstore_standard_log;
  3. Desactiva el modo mantenimiento.
  4. Asegúrate de que la retención de logs esté configurada para no volver a llenar la tabla sin control.

TRUNCATE elimina todas las filas y libera el espacio del archivo .ibd, dejando la tabla como nueva. A partir de ahí, Moodle seguirá guardando eventos normalmente, pero ahora bajo la nueva política de retención.

Conservar solo los logs recientes (estrategia intermedia)

Si quieres mantener, por ejemplo, solo los eventos de los últimos 12 meses:

  1. Exporta únicamente las filas recientes a un archivo .sql usando mysqldump con una condición WHERE timecreated >= ....
  2. Ejecuta TRUNCATE TABLE para limpiar la tabla.
  3. Importa de nuevo solo los registros recientes desde ese archivo.

Así tendrás un historial limitado a un periodo razonable, con una tabla mucho más ligera.


Buenas prácticas para plataformas educativas sostenibles

Optimizar mdl_logstore_standard_log no es solo un truco de base de datos: es parte de una cultura de mantenimiento preventivo muy necesaria en tecnología educativa.

Recomendaciones clave

  • Define políticas claras de retención de datos: logs, notificaciones, archivos temporales, respaldos automáticos.
  • Verifica regularmente el tamaño de las tablas más grandes de tu Moodle (logs, sesiones, archivos, etc.).
  • Automatiza tareas de limpieza desde Moodle y desde el sistema operativo (cron jobs, scripts).
  • Documenta tus procedimientos: que otros administradores (o tu yo del futuro) entiendan qué se hizo y por qué.
  • Aprovecha el proceso para aprender: cada ajuste en Moodle, MySQL o Linux es una oportunidad de profundizar en tu formación autodidacta como administrador de plataformas educativas.

Conclusión: convierte el mantenimiento de logs en una lección de aprendizaje autodidacta

Controlar el tamaño de mdl_logstore_standard_log es mucho más que un tema técnico: es una forma concreta de garantizar que tu plataforma Moodle siga siendo rápida, estable y sostenible para tus estudiantes y docentes.

Al:

  • ajustar la retención de logs,
  • limpiar de forma inteligente los registros antiguos,
  • y recuperar espacio en disco de manera segura,

estás desarrollando competencias clave en administración de sistemas, bases de datos y gestión de plataformas educativas, todas ellas fundamentales para quienes viven la tecnología educativa como un camino de aprendizaje continuo.


Llamado a la acción

Si trabajas con Moodle en contextos de educación en línea o mezclada:

  • Revisa hoy mismo el tamaño de tus tablas de logs.
  • Define una política de retención alineada con las necesidades pedagógicas y legales de tu institución.
  • Documenta lo que aprendas y compártelo con tu comunidad: colegas, estudiantes o lectores de tu blog.

Tu servidor lo agradecerá, tus cursos cargarán más rápido y tú darás un paso más en tu camino como profesional autodidacta de la tecnología educativa.


author avatar
blogdecomputo.com

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *