Administración de Moodle (Parte 1) – El motor de base de datos

Consideraciones

• Para MySQL/MariaDB, a partir de la versión 3.3+ se utiliza la codificación utf8mb4_unicode_ci. Para actualizar se debe migrar a esa codificación.
• Formato de filas Compressed¹
• Características de la base de datos:
  • Entre 383 tablas²
  • Tipo InnoDB por defecto
  • No se maneja lógica en la base de datos
  • Prefijo en las tablas para permitir múltiples instalaciones en una misma bases de datos

Tablas importantes para gestión por BD

• Auditoría (logstore_standard_log): requiere depuración, crece considerablemente. Se puede buscar información de depuración, por ejemplo de seguridad. Ejemplo:

  SELECT *  FROM `mdl_logstore_standard_log` WHERE `action` = 'deleted' AND target = 'user' ORDER BY timecreated DESC LIMIT 5;

• Historial de calificaciones: En las tablas “grade history” se puede revisar qué calificaciones ha tenido una actividad, si la configuración de la calificación ha cambiado, entre otra información. Ejemplo con un cuestionario:Determinar el id de la actividad: (reemplazar “?” por el id que aparece en la actividad en Moodle.

  SELECT instance FROM `mdl_course_modules` WHERE `id` = ?;

  Luego buscar el item de calificación asociado a la instancia encontrada: (reemplazar “?” por el valor de la instancia obtenido en la consulta anterior).

  SELECT * FROM `mdl_grade_items` WHERE itemtype = 'mod' AND itemmodule = 'quiz' AND `iteminstance` = ?;

  Nota: si no se desean hacer los pasos anteriores, el id del item también se puede observar en Moodle yendo al libro de calificaciones, en la pestaña Vista > Vista simple, y escogiendo en “Seleccionar Calificación” la actividad correspondiente. En la URL el id estará en el campo itemid.
  Luego, con el id del item, se puede consultar qué calificaciones ha tenido:

  SELECT * FROM `mdl_grade_grades_history` WHERE itemid = ?;

  La calificación queda almacenada en el campo rawgrade y el valor final en finalgrade, lo anterior debido a que las calificaciones pueden ser sobrescritas manualmente o sufrir cambios por otros modificadores automáticos.

  Nota: el historial de calificaciones se puede desactivar desde la configuración de Moodle utilizando la variable disablegradehistory en Administración del sitio > Servidor > Limpieza. También, se puede programar que se elimine el historial utilizando el parámetro gradehistorylifetime en la misma sección.
  Por auditoría, se recomienda mantener habilitado el historial y mantener en nunca eliminar.

• Configuración (config): se requiere intervenir en algunos casos, por ejemplo cuando no se puede acceder a la configuración de la plataforma por problemas en la actualización. Dos de los parámetros que son más útiles en esos casos:debug: en 32767 para habilitar el nivel de depuración en “desarrollador”debugdisplay: en 1 para habilitar depuraciónNota: también es posible sobrescribir los parámetros de configuración directamente en el archivo config.php.
• Archivos (files): es útil el acceso a dicha tabla para consultar información, por ejemplo para conocer los archivos más pesados de la plataforma y poder así hacer depuraciones. Por ejemplo, para conocer los archivos más pesados y su peso en MB:

  SELECT *, (filesize/(1024*1024)) AS MB FROM `mdl_files` ORDER BY `filesize` DESC ;

  Con el valor del campo contenthash se puede ubicar el archivo en el servidor, en el directorio<moodledata>/filedir. En un escenario normal se debe encontrar siguiendo la estructura: los dos primeros caracteres del contenthash corresponden al nombre de una carpeta que debe contener en su interior otra carpeta nombrada con los caracteres 3 y 4 del contenthash, el archivo se encontrará dentro de esa segunda carpeta y su nombre será igual al contenthash y sin extensión.

  Otro ejemplo, asignando copias de seguridad de un usuario a otro usuario específico para poder gestionarlas desde su área de archivos:

  UPDATE `mdl_files` SET `contextid` = '1111', `userid` = '0000', `component` = 'user', `filearea` = 'backup' WHERE userid = 2222 AND filename like '%copia_de_seguridad%' and filearea = 'automated' and component = 'backup';

  En el ejemplo anterior: 1111 es el contexto de copias de seguridad del usuario destino y 0000 es el id de ese usuario. 2222 es el id del usuario al que se le retirarán las copias de seguridad. Es útil por ejemplo cuando un usuario tiene copias de seguridad demasiado pesadas y se desea que la gestión recaiga en otro usuario, sin tener que hacer un proceso manual de enviar el archivo.

• Usuarios (user): en algunos casos se requiere hacer tareas manuales sobre los usuarios directamente en la base de datos. La idea es hacerlo desde la interfaz de gestión de Moodle mientras sea posible, pero hay casos en los que no es posible, como recuperar un usuario eliminado o cambiar masivamente un campo.Un ejemplo recuperando un usuario eliminado:Cuando un usuario se elimina, se establece el campo deleted en 1, para recuperarlo se debe pasar ese campo a 0. Además, el campo username se sobrescribe con el correo y una marca de tiempo, es preciso entonces devolver el valor original o asignar un nuevo nombre de usuario y un correo electrónico válido.

  Otro ejemplo, asignando un tema específico (clean) a los usuarios de una ciudad:

  UPDATE `mdl_user` SET theme = 'clean' WHERE `city` LIKE 'Medellín';

Log de operaciones en la base de datos

La BD suele requerir algunas tareas de mantenimiento. La principal de ellas es la limpieza de los log de auditoría. Aunque se puede configurar una limpieza automática (Administración del sitio > Extensiones > Logging > Log estándar), eso implica que se eliminan los registros automáticamente y en muchos casos se quiere mantener dichos registros aunque en otro espacio. Para eso, se aconseja mantener deshabilitada la limpieza automática de los log y hacer el proceso manualmente. Hay dos maneras rápidas de hacerlo:

La primera es exportando los registros antiguos y borrandolos posteriormente. Es una tarea que se puede realizar desde el cliente de MySQL en el servidor o utilizando una herramienta como phpMyAdmin, sin embargo, específicamente el borrado se aconseja que se lleve a cabo desde el cliente de MySQL para que el rendimiento en la ejecución no se vea limitado por el servidor Web. Esta estrategia es posible cuando los registros no son demasiados y no se afecta el rendimiento de la base de datos. Se puede hacer en caliente, es decir, no se tiene que dejar de prestar servicio en la plataforma, no obstante, si son demasiados registros o no se cuenta con muchos recursos en el servidor, puede verse afectada la plataforma mientras dura el proceso.

La segunda opción es exportar los registros antiguos, clonar la estructura de la tabla logstore_standard_log en una nueva tabla, pasar a la nueva los registros que se desea mantener, eliminar la tabla logstore_standard_log, renombrar la tabla temporal para que sea la nueva logstore_standard_log. Este proceso es necesario cuando los registros son demasiados ya que la primera opción puede hacer colapsar el motor de base de datos y detener la plataforma por mucho tiempo. Sin embargo, se debe detener la plataforma mientras se ejecuta el trabajo, sea poniéndola en mantenimiento o desde el servidor Web.

MariaDB

La mayoría de comportamientos son similares cuando se usa MariaDB o MySQL y de hecho se utiliza el mismo cliente de conexión al momento de trabajar con uno u otro motor, no obstante, es adecuado mantener configurada la conexión diferenciando según el motor que se usa y para MariaDB los parámetros que varían son los siguientes:

$CFG->dbtype = 'mariadb'; 
        $CFG->dblibrary = 'native';