Moodle en français: Problèmes sauvegardes automatiques Moodle 2.9.2

Problèmes sauvegardes automatiques Moodle 2.9.2

par Séverin Terrier, jeudi 8 octobre 2015, 19:03

Bonjour à tou(te)s,

J'avais ouvert par le passé une discussion similaire pour Moodle 2.4 et 2.5, puis une autre pour Moodle 2.7. J'ouvre cette nouvelle discussion pour repartir "propre", et apporter des éléments supplémentaires (et certaines "solutions").

Pour améliorer le suivi de cette discussion, je vais découper en plusieurs sous parties, afin de parler de chaque problème indépendamment (et garder une taille correcte aux messages) :

problème de "Module de cours orphelin"
problème de "existing temptables found" et "La table « backup_logs » n'existe pas"
problème de la sauvegarde de la page d'accueil

Bien cordialement,
Séverin

Moyenne des évaluations Utile (1)

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - Module de cours orphelin

par Séverin Terrier, jeudi 8 octobre 2015, 19:26

Concernant ce problème renvoyant un message d'erreur "Module de cours orphelin", que j'avais déjà évoqué avec Moodle 2.7 (et également abordé en anglais), voici des précisions, et une solution.

Je recevais donc, par "mail interne" directement sur le serveur Moodle, le message suivant :

Module de cours orphelin (id : 60660) trouvé. Ce module ne sera pas sauvegardé.
Module de cours orphelin (id : 44659) trouvé. Ce module ne sera pas sauvegardé.

Et effectivement, je retrouve cette information dans la table mdl_backup_logs :

SELECT FROM_UNIXTIME(timecreated) AS Date, backupid, message
FROM mdl_backup_logs
WHERE loglevel=30 AND message LIKE 'Module de cours orphelin%'
ORDER BY timecreated DESC
LIMIT 20;

Qui me donne ceci (j'ai supprimé quelques redondances inutiles) :
+---------------------+----------------------------------+--------------------------------------------------------------------------------------+ | Date | backupid | message | +---------------------+----------------------------------+--------------------------------------------------------------------------------------+ | 2015-10-04 02:31:30 | aaab0c62f909bd65c19a4e65a7d0bafe | Module de cours orphelin (id : 60660) détecté. Ce module ne sera pas sauvegardé. | | 2015-10-04 02:08:33 | 72a66df43abe3b5f4e83c85a42f109ce | Module de cours orphelin (id : 44659) détecté. Ce module ne sera pas sauvegardé. +---------------------+----------------------------------+--------------------------------------------------------------------------------------+

Du coup, afin d'en savoir plus, j'ai lancé ceci :

SELECT id, course, section, module, instance, visible, added
FROM mdl_course_modules
WHERE id IN (60660, 44659) OR instance IN (60660, 44659);

+-------+--------+---------+--------+----------+---------+------------+| id | course | section | module | instance | visible | added |+-------+--------+---------+--------+----------+---------+------------+| 44659 | 60 | 3077 | 18 | 0 | 1 | 1406706501 || 60660 | 205 | 10350 | 18 | 0 | 1 | 1427362765 |+-------+--------+---------+--------+----------+---------+------------+

SELECT * FROM mdl_modules WHERE id=18;

+----+-------+------+------------+--------+---------+| id | name | cron | lastcron | search | visible |+----+-------+------+------------+--------+---------+| 18 | scorm | 300 | 1444214720 | | 1 |+----+-------+------+------------+--------+---------+

J'ai donc fouillé les cours 60 et 205, à la recherche d'activités SCORM, mais sans succès. J'ai essayé d'activer le bloc "Activités" afin de voir si des éléments s'affichaient, mais sans résultat non plus.

Je me suis donc demandé si je pouvais simplement supprimer ces lignes de la table mdl_course_modules, mais j'étais tout de même hésitant (avec le risque qu'il reste des éléments disséminés dans la base de données interne de Moodle).

Mais j'ai testé ceci : effectuer une sauvegarde complète des cours concernés, puis les restaurer sur eux même, en les supprimant d'abord. Résultat : les lignes en question n’apparaissent plus dans la table mdl_course_modules ; je suppose donc que les prochaines sauvegardes n'auront plus ce problème.

Bien cordialement,
Séverin

PS : cela m'a aussi permis de comprendre que normalement, le champ instance (de mdl_course_modules) devrait toujours être renseigné, avec le numéro de l'instance de l'activité. Cela signifie que si des lignes existent avec instance=0, elles vont poser problème...

Moyenne des évaluations Utile (1)

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - Module de cours orphelin

par Séverin Terrier, mardi 14 juin 2016, 23:26

Je viens de rencontrer à nouveau ce message d'erreur, et suis bien content de retrouver mon message (d'il y a quelques mois), qui me permet de gagner du temps dans la résolution de ce problème

Cette fois j'ai :

Module de cours orphelin (id : 82167) détecté. Ce module ne sera pas sauvegardé.
Module de cours orphelin (id : 82168) détecté. Ce module ne sera pas sauvegardé.
Module de cours orphelin (id : 82169) détecté. Ce module ne sera pas sauvegardé.

Et en lançant ma requête :

SELECT id, course, section, module, instance, visible, added
FROM mdl_course_modules
WHERE id IN (82167, 82168, 82169);

J'obtiens :

+-------+--------+---------+--------+----------+---------+------------+
| id    | course | section | module | instance | visible | added      |
+-------+--------+---------+--------+----------+---------+------------+
| 82167 |   3080 |   97157 |     18 |        0 |       1 | 1461330284 |
| 82168 |   3080 |   97157 |     18 |        0 |       1 | 1461330320 |
| 82169 |   3080 |   97157 |     18 |        0 |       1 | 1461330430 |
+-------+--------+---------+--------+----------+---------+------------+

Le module 18 correspond toujours à SCORM !

Et quand je vérifie les modules SCORM du cours 3080 :

SELECT * FROM mdl_scorm WHERE course = 3080;

Je n'ai rien !

Du coup, au lieu de passer par une sauvegarde / restauration complète du cours, je fais simplement un peu de ménage dans la table mdl_course_modules :

DELETE FROM mdl_course_modules WHERE id IN (82167, 82168, 82169);

Et je vérifies ensuite si j'ai d'autres éléments qui posent problème :

SELECT COUNT(1) FROM mdl_course_modules WHERE instance=0;

Et j'en obtiens plus de détails avec la commande :

SELECT id, course, section, module, instance, visible, added
FROM mdl_course_modules
WHERE instance=0;

Je pourrais ainsi refaire mes vérifications, avant de procéder au nettoyage...

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - "existing temptables found" et "La table « backup_logs » n'existe pas"

par Séverin Terrier, jeudi 8 octobre 2015, 21:35

Concernant ce problème, j'avais ouvert la discussion pour Moodle 2.7.

Je reviens avec des précisions supplémentaires concernant cette erreur rencontrée lors des sauvegardes automatiques.

Je reçois donc, par "mail interne" (directement sur le serveur Moodle), le message suivant :

backup_auto_failed_on_course NOM_ABRÉGÉ_DU_COURS
Potential coding error - existing temptables found when disposing database. Must be dropped!

et dans le fichier de log d'exécution de la sauvegarde automatique, j'ai ceci :

Backing up NOM_COMPLET_DU_COURS...
Scheduled task failed: Sauvegardes automatiques,La table « backup_logs » n'existe pas
!!! Erreur de lecture de la base de données !!!

En fouillant un peu la table mdl_backup_logs, je retrouve ces éléments :

SELECT FROM_UNIXTIME(timecreated) AS Date, backupid, message
FROM mdl_backup_logs
WHERE loglevel=20 AND message LIKE 'backup_auto_failed_on_course%'
ORDER BY timecreated DESC
LIMIT 20;

+---------------------+----------------------------------+----------------------------------------------------------------------------------------+ | Date | backupid | message | +---------------------+----------------------------------+----------------------------------------------------------------------------------------+ | 2015-10-04 07:00:15 | dfa0fd6d0339fe252a7f5714ffc2ff69 | backup_auto_failed_on_course SociologieG1 | | 2015-10-04 05:35:41 | 38d745847a934049e6c2274400dde705 | backup_auto_failed_on_course Dlc-Esp | | 2015-09-17 01:00:08 | be32f9db812b2af372ff734820e9df84 | backup_auto_failed_on_course Master-1° année-International and European Law | | 2015-09-10 01:00:17 | e9da28fd319865396f0e5158a1e600d6 | backup_auto_failed_on_course Master-1° année-Droit Notarial Immobilier et Patrimoine | +---------------------+----------------------------------+----------------------------------------------------------------------------------------+

SELECT FROM_UNIXTIME(timecreated) AS Date, backupid, message
FROM mdl_backup_logs
WHERE message LIKE 'Exception%'
ORDER BY timecreated DESC
LIMIT 20;

+---------------------+----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------+ | Date | backupid | message | +---------------------+----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------+ | 2015-10-04 07:00:15 | dfa0fd6d0339fe252a7f5714ffc2ff69 | Exception: directory_not_exists /home/moodle/donnees-cours/temp/backup/dfa0fd6d0339fe252a7f5714ffc2ff69/course | | 2015-10-04 05:35:41 | 38d745847a934049e6c2274400dde705 | Exception: codingerror Mismatch between provided sizes: files/3e/3e72f4feaf197733f61badfbd9e1e8b6a07df048 (was 24846336, expected 49419609) | | 2015-09-17 01:00:08 | be32f9db812b2af372ff734820e9df84 | Exception: directory_not_exists /home/moodle/donnees-cours/temp/backup/be32f9db812b2af372ff734820e9df84/activities/page_58618 | | 2015-09-10 01:00:17 | e9da28fd319865396f0e5158a1e600d6 | Exception: directory_not_exists /home/moodle/donnees-cours/temp/backup/e9da28fd319865396f0e5158a1e600d6/course | +---------------------+----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------+On constate que ces deux éléments sont liés ! En effet, les champs Date et backupid sont identiques !
Pour l'erreur du 4 octobre avec erreur de taille, je pense que c'est lié à un problème (temporaire) de disque dur plein.

Par contre, l'autre erreur est récurrente. Je ne sais pas ce qui se passe exactement, mais il semblerait que des dossiers soient vides (ou manquants), ce qui empêche la sauvegarde de se terminer correctement...

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - "existing temptables found" et "La table « backup_logs » n'existe pas"

par Séverin Terrier, jeudi 3 décembre 2015, 22:47

Bonjour,

Finalement, j'ai réglé mes problèmes en désactivant la sauvegarde de la page d'accueil.

Mais si d'autres personnes tombent sur ce message d'erreur, il est peut-être possible de le solutionner (à essayer) en modifiant les paramètres (connect_timeout, wait_timeout et interactive_timeout) de MySql, comme je l'avais évoqué il y a plusieurs années.

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.4+ - "existing temptables found" et "La table « backup_logs » n'existe pas"

par Séverin Terrier, vendredi 11 mars 2016, 18:50

Bonjour,

J'ai mis à jour deux plateformes de la version 2.9.4 (Build: 20160111) à 2.9.4+ (Build: 20160225) il y a quelques jours, et depuis je rencontre à nouveau ce problème sur ces plateformes, alors qu'une autre plateforme (restée en 2.9.4) continue de fonctionner correctement au niveau des sauvegardes

Les tables mdl_backup_logs de ces instances sont vides !

J'ai regardé les valeurs de timeout dans le fichier my.cnf (valable pour toutes les plateformes) :

connect_timeout=30
wait_timeout=240
interactive_timeout=480

Si quelqu'un a une super idée, je suis preneur...

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.4+ - "existing temptables found" et "La table « backup_logs » n'existe pas"

par Séverin Terrier, vendredi 11 mars 2016, 19:05

Allez, je me réponds !

Le mot clé important ici était "mise à jour" ; en effet, j'ai oublié, lors de celle-ci, de répercuter les modifications nécessaires pour ne pas sauvegarder la page d'accueil et éviter ainsi les blocages

L'usage de Git m'éviterait sans doute ce genre de désagrément...

Séverin

Moyenne des évaluations Utile (1)

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - Sauvegarde page d'accueil du site

par Séverin Terrier, jeudi 8 octobre 2015, 22:24

Dans le lot de mes soucis avec les sauvegardes automatiques, je rencontre le plus fréquemment celui de la sauvegarde de la page d'accueil du site.

En effet, si la sauvegarde de la plupart des cours se fait bien, celle de la page d'accueil plante très souvent

J'utilise le script admin/cli/automated_backups.php, appelé avec les paramètres suivants :

/usr/bin/php -d log_errors=1 -d error_reporting=E_ALL \
-d display_errors=0 -d html_errors=0 -d memory_limit=1024M \
-d max_execution_time=36000 admin/cli/automated_backups.php \
> FICHIER_DE_LOG_DATÉ.txt

Une de mes plateformes (la plus petite) était configurée pour exécuter les sauvegardes automatiques (donc via le cron général, et pas l'appel dédié comme ci dessus), et toutes les sauvegardes automatiques se faisaient bien (y compris la page d'accueil).

J'ai essayé de le passer en "manuel", et d'exécuter les sauvegardes avec le script dédié (comme pour les autres instances), et je me suis retrouvé avec le même problème pour la page d'accueil.

Il semblerait donc qu'il y ait une vraie différence entre le script dédié et les sauvegardes automatiques lancées via le cron général

Je précise que les paramètres de mémoire allouée et de durée d'exécution de script sont les mêmes pour le cron (général) et le script de sauvegarde (dédié).

je précise également que mes sauvegardes sont configurées pour sauvegarder les historiques (le but étant de pouvoir reconstruire l'existant), et que je conserve à la fois les historiques "obsolètes" et les historiques au nouveau format (depuis Moodle 2.7). Ceci car j'ai des requêtes qui s'appuient sur les anciens historiques, et que la sauvegarde/restauration des historiques (nouveaux format) ne fonctionne pas correctement (ceci devrait enfin être corrigé pour Moodle 3.0 : MDL-46455).

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - Sauvegarde page d'accueil du site

par Séverin Terrier, samedi 10 octobre 2015, 00:12

Bonjour,

Concernant la page d'accueil : j'ai essayé de faire une sauvegarde, uniquement de la page d'accueil, à la fois via l'interface web ou en ligne de commande, avec cette commande :

/usr/bin/php admin/cli/backup.php --courseid=1 --destination=/home/moodle/chemin/vers/dossier/sauvegardes

A chaque fois, au bout de 15 minutes, cela s'est arrêté, avec ce message (en ligne de commande) :

== Performing backup... ==
!!! Erreur de lecture de la base de données !!!
Potential coding error - existing temptables found when disposing database. Must be dropped!

Ou celui-ci (via le web) :

Erreur de lecture de la base de données
Plus d'informations sur cette erreur

Je ne sais pas trop si j'ai atteins une limite de PHP ou MySql, et je suppose que la taille des historiques de la page d'accueil n'y est pas pour rien... mais je n'ai pas encore de solution.

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - Sauvegarde page d'accueil du site

par Séverin Terrier, mercredi 21 octobre 2015, 20:53

Bonjour,

J'ai essayé autre chose : désactiver l'enregistrement des historiques dans les sauvegardes automatiques. Et du coup, toutes les sauvegardes automatiques sont passées correctement, via le script dédié. Cela a tout de même pris environ 5h pour sauvegarder 2000 cours.

Mais par contre, cela ne répond pas à la problématique de restauration à l'identique

J'ai essayé de regarder le nombre d'éléments dans les historiques qui concernent la page d'accueil :

historiques "obsolètes" : 10438293

SELECT COUNT(1) FROM mdl_log WHERE course=1;

historiques : 138319

SELECT COUNT(1) FROM mdl_logstore_standard_log WHERE courseid=1;

Séverin

Moyenne des évaluations Utile (1)

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - Sauvegarde page d'accueil du site

par Séverin Terrier, jeudi 29 octobre 2015, 01:06

Bonjour,

J'ai donc essayé d'avoir plus de détails sur ces logs pour la page d'accueil :

mysql> SELECT action, COUNT(1) FROM mdl_log WHERE course=1 AND module='course' GROUP BY action;+----------------------+----------+| action | COUNT(1) |+----------------------+----------+| add mod | 3 || delete | 147 || delete mod | 3 || editsection | 270 || new | 1330 || report live | 10 || report log | 979 || report outline | 34 || report participation | 1 || update mod | 1 || user report | 4 || view | 64293 |+----------------------+----------+mysql> SELECT component, COUNT(1) FROM mdl_logstore_standard_log WHERE courseid=1 GROUP BY component;

+----------------------+----------+| component | COUNT(1) |+----------------------+----------+| core | 226127 || gradereport_overview | 5 || mod_forum | 1468 || mod_url | 1 || report_log | 293 || report_outline | 21 |+----------------------+----------+mysql> SELECT eventname, COUNT(1) FROM mdl_logstore_standard_log WHERE courseid=1 AND component='core' GROUP BY eventname;

+---------------------------------------+----------+| eventname | COUNT(1) |+---------------------------------------+----------+| \core\event\course_module_created | 1 || \core\event\course_module_deleted | 1 || \core\event\course_section_updated | 25 || \core\event\course_user_report_viewed | 4 || \core\event\course_viewed | 226095 || \core\event\user_list_viewed | 2 |+---------------------------------------+----------+

On constate donc que la majorité des éléments sont des consultations, ce qui me semble normal pour une page d'accueil.

Du coup, je me dis qu'hormis les (rares) cours qui posent problème, et que j'espère bien corriger très prochainement, la solution serait sans doute de désactiver la sauvegarde de la page d'accueil. Quelqu'un saurait-il comment faire cela ?

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - Sauvegarde page d'accueil du site désactivée

par Séverin Terrier, mardi 17 novembre 2015, 17:21

Bonjour,

Je reviens sur mon souhait de désactiver la sauvegarde de la page d'accueil (car de toute façon, je ne la restaurerais pas en soi), afin que toutes les autres sauvegardes automatiques de cours puissent se faire correctement, avec les historiques.

J'ai envisagé la possibilité de modifier (un peu) le code source de Moodle, mais j'ai finalement trouvé une solution plus simple et plus durable (pas à maintenir au fil des versions) : simplement modifier la date de prochaine sauvegarde prévue, avec une commande du style :

UPDATE mdl_backup_courses
SET nextstarttime = 1450000000
WHERE courseid = 1;

Cela me place la date au 13/12/2015. Je mettrais sans doute une date (bien) ultérieure (par exemple 1600000000 pour aller jusqu'au 13/09/2020) une fois constaté le bon fonctionnement.

L'idéal malgré tout, au lieu de désactiver complètement la sauvegarde de la page d'accueil, serait de pouvoir spécifier que ce cours là (uniquement) devrait être sauvegardé sans les historiques...

Séverin

Moyenne des évaluations Utile (1)

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - Sauvegarde page d'accueil du site désactivée

par Séverin Terrier, lundi 23 novembre 2015, 23:09

Bonjour,

C'était une bonne idée en soi, mais cela ne fonctionne pas

J'ai également essayé de modifier le statut de la dernière sauvegarde pour l'espace de cours correspondant à la page d'accueil, en définissant ceci :

UPDATE mdl_backup_courses
SET laststatus = 1
WHERE courseid = 1;

laststatus=1 correspond à "Sauvegarde OK" ; j'avais auparavant essayé la valeur 3 ("sauté") sans plus de succès.

Mais manifestement, cela ne suffit pas pour que Moodle "saute" cette sauvegarde. Et du coup, j'ai toujours un plantage qui est généré (mêmes messages d'erreur que signalés dans ce message, mais la table mdl_backup_logs est vide), dès la page d'accueil, et les autres cours qui ne se sauvegardent pas

Si quelqu'un sait comment sauter la sauvegarde de la page d'accueil, je suis preneur...

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - Sauvegarde page d'accueil du site désactivée

par Séverin Terrier, mercredi 25 novembre 2015, 17:29

Bonjour,

Hier, j'avais essayé d'être plus complet, et de modifier tous les éléments, pour avoir une date de début de sauvegarde avant la date de fin de sauvegarde, un statut OK, et une date de prochaine sauvegarde dans le futur :

UPDATE mdl_backup_courses
SET laststarttime = 144839000, lastendtime=1448400000, laststatus = 1, nextstarttime=1450000000
WHERE courseid = 1;

Mais la sauvegarde de la page d'accueil a tout de même été démarrée, et j'ai eu le même blocage

Donc, soit il y a un autre problème, soit je ne sais toujours pas comment faire "sauter" une sauvegarde. J'ai posé la question en anglais, mais pas (encore) obtenu de réponse.

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - Sauvegarde page d'accueil du site désactivée

par Séverin Terrier, mercredi 25 novembre 2015, 21:41

Bon,

En regardant les sources, je crois que je comprends mieux pourquoi il n'est pas tenu compte de la date de prochaine exécution dans le futur.

En effet, le script moodle/admin/cli/automated_backups.php fait l'appel de fonction suivant (ligne 94) :

backup_cron_automated_helper::run_automated_backup(backup_cron_automated_helper::RUN_IMMEDIATELY);

Et du coup, en cherchant dans moodle/backup/util/helper/backup_cron_helper.class.php, on s'aperçoit que c'est le paramètre RUN_IMMEDIATELY (testé en ligne 145) qui court-circuite le respect de la future date programmée !

Du coup, je pense qu'il faudrait soit que :

j'enlève ce paramètre dans automated_backups.php
j'enlève le test dans backup_cron_helper.class.php sur ce paramètre (ligne 145)
je rajoute un test dans backup_cron_helper.class.php (ligne 145) sur le fait de ne pas être sur le cours 1

Ce qui m'embête, c'est que dans tous les cas cela impose une modification (même minime) du code source (qui sera à répercuter à chaque mise à jour).

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - Sauvegarde page d'accueil du site désactivée

par Séverin Terrier, jeudi 26 novembre 2015, 17:56

Bonjour,

J'ai adopté la 3ème solution, celle de rajouter un test sur le fait de ne pas être sur le cours 1, en modifiant la ligne 145 de moodle/backup/util/helper/backup_cron_helper.class.php ainsi :

|| ($rundirective == self::RUN_IMMEDIATELY && $backupcourse->courseid != 1) );

Du coup, enfin, mes sauvegardes se sont bien toutes passées

Le cours 1 (page d'accueil) n'a pas été sauvegardé, comme prévu. Seul détail, et léger problème, la date de prochaine sauvegarde a été modifiée automatiquement par le script de sauvegarde (comme pour tous les autres cours).

Je vais donc simplement mettre en place un cron spécifique, chaque jour, qui replacera la date de prochaine sauvegarde de ce cours (assez loin) dans le futur (afin qu'il ne cherche pas à le sauvegarder dès la prochaine exécution) ! Ainsi, je devrais être définitivement tranquille

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - Sauvegarde page d'accueil du site désactivée

par Séverin Terrier, jeudi 3 décembre 2015, 22:50

Bonjour,

Sinon, j'ai eu des propositions plus efficaces (en anglais) pour désactiver la sauvegarde de la page d'accueil.

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - log et autres éléments

par Séverin Terrier, jeudi 8 octobre 2015, 22:49

En plus des différents éléments abordés dans les autres sujets, voici également quelques précisions sur les éléments que l'on peut trouver dans les fichiers de log d'exécution des sauvegardes automatiques :

Si sauvegarde "sautée" :

car planifiée pour plus tard :

"Skipping XXX (Not scheduled for backup until DATE)" : on saute cette sauvegarde du cours XXX (pas de sauvegarde prévue avant DATE)

car non modifié :

"Skipping XXX (Not modified in the past 30 days)" : on saute cette sauvegarde du cours XXX
"Backup of 'XXX' is scheduled on DATE" : la sauvegarde de 'XXX' est prévue pour DATE

Si sauvegarde lancée :

"Backing up XXX" : début de sauvegarde de XXX
"complete - next execution" : fin de sauvegarde OK (de XXX)

Pour compter, pour un fichier de log, le nombre de chacun de ces éléments, on peut lancer (par exemple) les commandes suivantes :

grep -c "Backing up " FICHIER_DE_LOG_DATÉ.txt
grep -c "complete - next execution" FICHIER_DE_LOG_DATÉ.txt
grep -c "Not modified in the past" FICHIER_DE_LOG_DATÉ.txt
grep -c "is scheduled on" FICHIER_DE_LOG_DATÉ.txt
grep -c "Not scheduled for backup until" FICHIER_DE_LOG_DATÉ.txt

L'idée pourrait être de faire un comptage pour les différents fichiers de log, afin de savoir combien il y a d'éléments de chaque type sur chaque exécution, et éventuellement voir s'il y a eu des problèmes (et combien).

Ensuite, analyser de près ces fichiers pour savoir sur quels cours il y a eu des problèmes (et trouver pourquoi).

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - log et autres éléments

par Séverin Terrier, vendredi 9 octobre 2015, 21:24

En regardant les tables mdl_backup_logs de mes instances, je trouve des élément (très) anciens, manifestement liés à Moodle 1(.9) :

+---------------------+----------------------------------+------------------------------------------------------------------------------------+| Date | backupid | message +---------------------+----------------------------------+------------------------------------------------------------------------------------+| 2013-08-30 10:40:51 | 8dd3753e650d5cbafe66337b90f62e82 | (moodle1) error migrating file course_files/QCM-Images/barre-etat.PNG | 2012-09-04 17:11:26 | 0dd94de5d165abc64913b45db73c1a70 | (moodle1) no handler attached /MOODLE_BACKUP/COURSE/BLOCKS/BLOCK/PARTICIPANTS | 2012-09-04 17:11:26 | 0dd94de5d165abc64913b45db73c1a70 | (moodle1) no handler attached /MOODLE_BACKUP/COURSE/BLOCKS/BLOCK/ACTIVITY_MODULES | 2012-09-04 17:11:26 | 0dd94de5d165abc64913b45db73c1a70 | (moodle1) no handler attached /MOODLE_BACKUP/COURSE/BLOCKS/BLOCK/NEWS_ITEMS | 2012-09-04 17:11:26 | 0dd94de5d165abc64913b45db73c1a70 | (moodle1) no handler attached /MOODLE_BACKUP/COURSE/BLOCKS/BLOCK/CALENDAR_UPCOMING| 2012-09-04 17:11:26 | 0dd94de5d165abc64913b45db73c1a70 | (moodle1) no handler attached /MOODLE_BACKUP/COURSE/BLOCKS/BLOCK/ADMIN | 2012-09-04 17:11:26 | 0dd94de5d165abc64913b45db73c1a70 | (moodle1) no handler attached /MOODLE_BACKUP/COURSE/BLOCKS/BLOCK/RSS_CLIENT | 2012-09-04 17:11:25 | 0dd94de5d165abc64913b45db73c1a70 | (moodle1) unsupported activity module hotpot | 2012-09-04 17:11:25 | 0dd94de5d165abc64913b45db73c1a70 | (moodle1) unsupported activity module questionnaire | 2012-09-04 17:11:25 | 0dd94de5d165abc64913b45db73c1a70 | (moodle1) unsupported activity module audiorecorder +---------------------+----------------------------------+------------------------------------------------------------------------------------+
Je ne sais pas pourquoi ils n'ont pas été supprimés, mais je pense qu'ils pourraient l'être sans souci !

Par ailleurs, et pour information : les sauvegardes utilisent le dossier moodledata/temp/backup/ pour le stockage temporaire des données à sauvegarder. Normalement, lorsqu'une sauvegarde s'est bien terminée, il ne subsiste qu'un fichier .log ayant une taille de 0 !

Les données sont temporairement stockées dans un dossier spécifique à chaque sauvegarde. Les éléments contenus peuvent permettre de voir ce qui a été fait. Si un fichier .mbz existe, il y a de fortes chances que la sauvegarde ait réussi à se faire, mais que ce soit simplement la copie du fichier à sa destination finale qui ait échouée. Le bon fonctionnement de ce fichier de sauvegarde est donc à tester.

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - log et autres éléments

par Séverin Terrier, mercredi 21 octobre 2015, 21:39

Bonjour,

Afin de ne garder que les éléments utiles, j'ai supprimé de la table mdl_backup_logs tout ce qui concernait Moodle 1.9, et était très ancien :

DELETE FROM mdl_backup_logs WHERE message LIKE '(moodle1)%';

J'ai également vidé le dossier moodledata/temp/backup/ afin de pouvoir mieux observer les éléments restants.

Et pour voir les 2 dernières lignes de chaque fichier de log d'exécution des sauvegardes automatiques (+ la date/heure et la taille), j'utilise une ligne de la forme :

for i in `ls /CHEMIN/VERS/LOG/MOODLE/FICHIER_DE_LOG.2015-09-*` ; do ls -lh $i | cut -d " " -f 5- ; tail -2 $i ; echo ; done

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - log et autres éléments

par Daniel Méthot, jeudi 22 octobre 2015, 16:08

Bonjour Séverin,

Ne penses-tu pas que toutes ces mises à jour successives d'une même plate-forme entraînent intrinsèquement ce genre de problèmes ?

Il faudrait peut-être de temps à autre repartir sur une PF propre ?

Bien entendu cela dépend de la taille du travail à réaliser...

Même dans mon cas ou je repars à neuf tous les deux ou trois ans, avec restauration des cours, j'ai eu des problèmes de sauvegardes automatiques de cours de grande taille qui étaient dues à des fichiers (essentiellement des vidéos) en doublon que j'ai du supprimer puis réinstaller pour voir la taille des sauvegardes du cours diminuer très sensiblement.

Un plugin comme "course file usage report" cité récemment m'a bien aidé sur ce point.

Bravo pour ton travail et ... tes retours bien utiles.

Daniel

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - log et autres éléments

par Séverin Terrier, jeudi 22 octobre 2015, 18:02

Bonjour Daniel,

Il est fort possible et probable que l'historique joue, mais dans quelle mesure, c'est une bonne question.

Repartir sur une plateforme "propre", c'est ce que nous avons fait il y a (un peu plus de) deux ans, en installant un Moodle 2.4 tout propre. Le problème c'est que nous y avons (ré)importé plein de cours issus de notre ancienne plateforme (et leur potentiels problèmes avec) !

Mais j'imagine mal dire à tous les enseignants de tout recréer dans leurs cours en repartant de zéro

Et j'aurais tendance à dire que c'est un peu la même chose que lorsqu'on déménage (y compris dans une maison neuve) : en général, même si on change de lieu d'habitation, on conserve ses meubles, vêtements, enfants, souvenirs...

Donc, de mon point de vue, il est totalement impossible de repartir complètement de zéro, et il faut arriver (avec le temps) à repérer et éliminer les problèmes anciens.

De toute façon, je doute que tous les problèmes viennent forcément des éléments anciens, mais simplement de la masse d'information gérée...

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - log et autres éléments

par Bruno Malaval, jeudi 22 octobre 2015, 19:09

Salut Séverin,

Merci pour cette remarque, j'adore ...

"même si on change de lieu d'habitation, on conserve ses meubles, vêtements, enfants, souvenirs..."

effectivement, on a tendance à les garder, même si on déménage ...

Sinon, plus sérieusement, nous avons le même souci. Nous avons démarré Moodle il y a 10 (version 1.5 ou 1.6) et depuis je n'ai fait que des upgrades, justement pour éviter de demander aux enseignants de refaire leurs cours.

Nous essaierons l'été prochain de repartir sur une nouvelle plateforme, mais ce n'est pas évident.

De mon coté, je vide de temps en temps les logs trop anciens, pour alléger le serveur et les sauvegardes.

Le problème des upgrades, même si cela ne surcharge pas trop la bdd, est notamment la conservation des comptes utilisateurs, puisqu'il n'y a pas de réelle suppression des comptes.

J'ai maintenant 50 000 utilisateurs dans ma table user, alors que seulement 10 000 environ sont actifs.

De même, je pense qu'il me reste également pas mal de devoirs associés à des cours, pour lesquels il n'y a pas eu de réinitialisation, mais uniquement une désinscription des étudiants.

Repartir d'une plateforme neuve, c'est bien, mais selon le contexte cela peut être une opération assez lourde ... je m'y prépare pour l'an prochain ... peut-être en version 3.0 ...

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - log et autres éléments

par Séverin Terrier, jeudi 29 octobre 2015, 00:24

Bonjour,

Oui, j'avais été un peu taquin

Je ne pense pas que 50 000 utilisateurs soit vraiment gênant. De mon côté, j'en suis à plus de 57 000 lignes dans mdl_user (sur une plateforme ré-installée proprement il y a deux ans).

Par contre, c'est vrai que pour les historiques (logs), je conserve tout, et à la fois au nouveau format (depuis 2.7) et au format "obsolète" (avant 2.7). Du coup, ça fait beaucoup.

J'ai donc essayé de réduire. Mais passer à 1000 jours n'avait aucun intérêt (ma plateforme actuelle ayant moins de 3 ans), et passer à un an (seulement) serait problématique, car empêcherait de pouvoir remonter facilement dans les historiques.

Du coup, j'ai trouvé une solution pour conserver deux années (ce qui n'est malheureusement pas possible en standard), en ajoutant les éléments ci-dessous dans le fichier de configuration (config.php) :

// Paramètres supplémentaires optionnels
$CFG->loglifetime = 730;              // Conservation des historiques 2 ans !

// Paramètres supplémentaires optionnels des plugins
$CFG->forced_plugin_settings = array(
  'logstore_standard' => array('loglifetime' => 730)
);

Mais cela n'a rien changé à mes problèmes de sauvegarde !

Je rencontre toujours un blocage sur la page d'accueil, et sur un (autre) cours.

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2 - log et autres éléments

par Séverin Terrier, jeudi 29 octobre 2015, 00:47

Du coup, j'ai regardé de plus près les éléments relatifs aux cours qui posaient problème.

Tout d'abord, comment sont constituées les tables de logs :

mysql> DESC mdl_log; +--------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------+--------------+------+-----+---------+----------------+ | id | bigint(10) | NO | PRI | NULL | auto_increment | | time | bigint(10) | NO | MUL | 0 | | | userid | bigint(10) | NO | MUL | 0 | | | ip | varchar(45) | NO | | | | | course | bigint(10) | NO | MUL | 0 | | | module | varchar(20) | NO | | | | | cmid | bigint(10) | NO | MUL | 0 | | | action | varchar(40) | NO | MUL | | | | url | varchar(100) | NO | | | | | info | varchar(255) | NO | | | | +--------+--------------+------+-----+---------+----------------+

mysql> DESC mdl_logstore_standard_log;+-------------------+--------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+-------------------+--------------+------+-----+---------+----------------+| id | bigint(10) | NO | PRI | NULL | auto_increment || eventname | varchar(255) | NO | | | || component | varchar(100) | NO | | | || action | varchar(100) | NO | | | || target | varchar(100) | NO | | | || objecttable | varchar(50) | YES | | NULL | || objectid | bigint(10) | YES | | NULL | || crud | varchar(1) | NO | | | || edulevel | tinyint(1) | NO | | NULL | || contextid | bigint(10) | NO | | NULL | || contextlevel | bigint(10) | NO | | NULL | || contextinstanceid | bigint(10) | NO | | NULL | || userid | bigint(10) | NO | MUL | NULL | || courseid | bigint(10) | YES | MUL | NULL | || relateduserid | bigint(10) | YES | | NULL | || anonymous | tinyint(1) | NO | | 0 | || other | longtext | YES | | NULL | || timecreated | bigint(10) | NO | MUL | NULL | || origin | varchar(10) | YES | | NULL | || ip | varchar(45) | YES | | NULL | || realuserid | bigint(10) | YES | | NULL | |+-------------------+--------------+------+-----+---------+----------------+Puis des recherches concernant le cours 441 (qui pose problème sur une plateforme) :

SELECT component, COUNT(1)
FROM mdl_logstore_standard_log
WHERE courseid=441
GROUP BY component;

+----------------------+----------+| component | COUNT(1) |+----------------------+----------+| core | 3106550 || mod_forum | 1333 || mod_questionnaire | 319 || mod_quiz | 110927 || mod_resource | 20704 || mod_url | 1357 || report_log | 31 || report_loglive | 1 || report_outline | 15 || report_participation | 6 |+----------------------+----------+

SELECT eventname, COUNT(1)
FROM mdl_logstore_standard_log
WHERE courseid=441 AND component='core'
GROUP BY eventname;

+------------------------------------+----------+| eventname | COUNT(1) |+------------------------------------+----------+| \core\event\calendar_event_created | 41 || \core\event\calendar_event_deleted | 1 || \core\event\calendar_event_updated | 26 || \core\event\course_module_created | 70 || \core\event\course_module_deleted | 59 || \core\event\course_module_updated | 280 || \core\event\course_reset_ended | 2 || \core\event\course_reset_started | 2 || \core\event\course_restored | 2 || \core\event\course_section_updated | 30 || \core\event\course_updated | 7 || \core\event\course_viewed | 27838 || \core\event\grade_deleted | 3787 || \core\event\role_assigned | 1755 || \core\event\role_unassigned | 2161 || \core\event\user_enrolment_created | 1535698 || \core\event\user_enrolment_deleted | 1534510 || \core\event\user_list_viewed | 185 || \core\event\user_profile_viewed | 96 |+------------------------------------+----------+

SELECT module, COUNT(1)
FROM mdl_log
WHERE course=441
GROUP BY module;

+---------------+----------+| module | COUNT(1) |+---------------+----------+| blog | 8 || calendar | 109 || course | 3194075 || discussion | 1 || forum | 4113 || label | 1 || questionnaire | 509 || quiz | 183477 || resource | 42235 || role | 3916 || url | 2424 || user | 2027 |+---------------+----------+

SELECT action, COUNT(1)
FROM mdl_log
WHERE course=441 AND module='course'
GROUP BY action;

+----------------------+----------+| action | COUNT(1) |+----------------------+----------+| add mod | 129 || delete mod | 90 || editsection | 53 || enrol | 1566334 || move | 1 || report live | 7 || report log | 191 || report outline | 67 || report participation | 71 || unenrol | 1566639 || update | 9 || update mod | 315 || view | 60162 || view section | 7 |+----------------------+----------+

On constate donc bien, sur les deux types d'historiques que les éléments qui existent en très très grandes quantités (anormales) sont relatifs à des inscriptions et désinscriptions !

Et je constate exactement le même type de problème sur un cours d'une autre plateforme.

Du coup, afin d'essayer de mieux voir la "répartition" de ces éléments (dans le temps), j'ai lancé cette requête :

SELECT FROM_UNIXTIME(timecreated) AS Date, eventname AS Event, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
WHERE courseid=441
AND component='core'
AND (eventname = '\\core\\event\\user_enrolment_created'
     OR eventname = '\\core\\event\\user_enrolment_deleted')
GROUP BY timecreated
HAVING Nb > 100
ORDER BY Date DESC
LIMIT 30;

Et j'obtiens ces éléments :
+---------------------+------------------------------------+-----+| Date | Event | Nb |+---------------------+------------------------------------+-----+| 2015-10-28 16:45:16 | \core\event\user_enrolment_deleted | 125 || 2015-10-28 16:45:15 | \core\event\user_enrolment_deleted | 117 || 2015-10-28 16:45:12 | \core\event\user_enrolment_created | 499 || 2015-10-28 15:45:07 | \core\event\user_enrolment_deleted | 112 || 2015-10-28 15:45:06 | \core\event\user_enrolment_deleted | 126 || 2015-10-28 15:45:05 | \core\event\user_enrolment_deleted | 108 || 2015-10-28 15:45:02 | \core\event\user_enrolment_created | 416 || 2015-10-28 15:45:01 | \core\event\user_enrolment_created | 118 || 2015-10-28 14:25:11 | \core\event\user_enrolment_deleted | 102 || 2015-10-28 14:25:10 | \core\event\user_enrolment_deleted | 106 || 2015-10-28 14:25:09 | \core\event\user_enrolment_deleted | 118 || 2015-10-28 14:25:05 | \core\event\user_enrolment_created | 404 || 2015-10-28 14:25:04 | \core\event\user_enrolment_created | 130 || 2015-10-28 13:05:19 | \core\event\user_enrolment_deleted | 108 || 2015-10-28 13:05:18 | \core\event\user_enrolment_deleted | 105 || 2015-10-28 13:05:15 | \core\event\user_enrolment_created | 346 || 2015-10-28 13:05:14 | \core\event\user_enrolment_created | 188 || 2015-10-28 12:05:10 | \core\event\user_enrolment_deleted | 110 || 2015-10-28 12:05:09 | \core\event\user_enrolment_deleted | 128 || 2015-10-28 12:05:08 | \core\event\user_enrolment_deleted | 117 || 2015-10-28 12:05:05 | \core\event\user_enrolment_created | 245 || 2015-10-28 12:05:04 | \core\event\user_enrolment_created | 289 || 2015-10-28 10:45:21 | \core\event\user_enrolment_deleted | 115 || 2015-10-28 10:45:17 | \core\event\user_enrolment_created | 116 || 2015-10-28 10:45:16 | \core\event\user_enrolment_created | 412 || 2015-10-28 09:25:19 | \core\event\user_enrolment_deleted | 105 || 2015-10-28 09:25:18 | \core\event\user_enrolment_deleted | 117 || 2015-10-28 09:25:17 | \core\event\user_enrolment_deleted | 108 || 2015-10-28 09:25:14 | \core\event\user_enrolment_created | 459 || 2015-10-28 08:05:17 | \core\event\user_enrolment_deleted | 107 |+---------------------+------------------------------------+-----+

On constate donc bien qu'il passe son temps à inscrire et désinscrire des utilisateurs (en tout cas insérer cette information dans les historiques).

Je n'ai pas encore compris le pourquoi du comment, et comment faire pour y remédier. Si quelqu'un d'autre rencontre le même problème, n'hésitez pas à le dire.

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - log et autres éléments

par Séverin Terrier, vendredi 13 novembre 2015, 19:37

Bonjour,

Quelques nouvelles sur la façon dont j'ai géré ces problèmes là.

Pour mon cours 441, qui n'était pas encore exploité ce semestre, j'en ai réalisé une sauvegarde, puis créé un nouveau cours à partir de cette sauvegarde, avant de supprimer le cours 441. C'est également ainsi que je me suis aperçu que la suppression d'un cours ne supprimait pas les informations correspondantes dans les logs.

Pour le cours qui présentait les mêmes symptômes sur une autre plateforme, pas possible de le supprimer. Du coup, j'ai adopté une solution différente : supprimer les lignes de logs liées à ces (dés)inscriptions !

J'ai d'abord vérifié le nombre de ligne concernées :

SELECT COUNT(1)
FROM mdl_logstore_standard_log
WHERE courseid=5
AND component='core'
AND (eventname = '\\core\\event\\user_enrolment_created'
     OR eventname = '\\core\\event\\user_enrolment_deleted');

Ce qui m'a indiqué plus de 2 410 000 lignes !

Puis lancé la commande de suppression (qui a quand même pris 8 minutes) :

DELETE FROM mdl_logstore_standard_log
WHERE courseid=5
AND component='core'
AND (eventname = '\\core\\event\\user_enrolment_created'
     OR eventname = '\\core\\event\\user_enrolment_deleted');

Et de la même manière, pour les historiques "obsolètes" :

SELECT action, COUNT(1)
FROM mdl_log
WHERE course=5
AND module='course'
AND (action='enrol' OR action='unenrol');

Qui m'a renvoyé également plus de 2 410 000 lignes, que j'ai supprimées (en 10 minutes) avec :

DELETE FROM mdl_log
WHERE course=5
AND module='course'
AND (action='enrol' OR action='unenrol');

J'espère que je serais maintenant tranquille de ce point de vue là.

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - log et autres éléments

par Séverin Terrier, mardi 17 novembre 2015, 17:55

Bonjour,

La suppression du cours 441 a éliminé un problème, mais tout n'est pas fonctionnel ou optimal pour autant. Du coup, j'ai poursuivi mes recherches, en lançant quelques requêtes supplémentaires.

Liste des cours ayant un très grand nombre de logs :

SELECT courseid AS Cours, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
GROUP BY courseid
ORDER BY Nb DESC
LIMIT 10;

+-------+----------+| Cours | Nb |+-------+----------+| 0 | 13655627 || 441 | 3511715 || 275 | 2865744 || 327 | 1208524 || 301 | 722974 || 1463 | 436024 || 1255 | 431024 || 1461 | 429824 || 1464 | 428740 || 1468 | 427812 |+-------+----------+

Répartition de ces logs pour ces cours :

SELECT courseid, eventname, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
WHERE courseid IN (275, 327, 301, 1463, 1255, 1461, 1464, 1468)
AND component='core'
GROUP BY courseid, eventname
ORDER BY Nb DESC;

+----------+------------------------------------------+---------+| courseid | eventname | Nb |+----------+------------------------------------------+---------+| 275 | \core\event\user_enrolment_deleted | 1411756 || 275 | \core\event\user_enrolment_created | 1410710 || 301 | \core\event\course_viewed | 708145 || 327 | \core\event\user_enrolment_created | 665351 || 327 | \core\event\user_enrolment_deleted | 665320 || 1464 | \core\event\user_enrolment_deleted | 227621 || 1468 | \core\event\user_enrolment_deleted | 227620 || 1463 | \core\event\user_enrolment_deleted | 227617 || 1464 | \core\event\user_enrolment_created | 227587 || 1468 | \core\event\user_enrolment_created | 227586 || 1461 | \core\event\user_enrolment_created | 227586 || 1463 | \core\event\user_enrolment_created | 227584 || 1461 | \core\event\user_enrolment_deleted | 227582 || 1255 | \core\event\user_enrolment_created | 227573 || 1255 | \core\event\user_enrolment_deleted | 226998 |+----------+------------------------------------------+---------+

Constatant que c'est toujours les mêmes éléments qui reviennent, je recherche tous les cours qui ont manifestement ce problème de grand nombre de log d'inscription/désinscriptions :

SELECT courseid, eventname, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
WHERE component='core'
AND (eventname = '\\core\\event\\user_enrolment_created'
  OR eventname = '\\core\\event\\user_enrolment_deleted')
GROUP BY courseid, eventname
HAVING Nb > 10000
ORDER BY Nb DESC;

+----------+------------------------------------+---------+| courseid | eventname | Nb |+----------+------------------------------------+---------+| 441 | \core\event\user_enrolment_created | 1670712 || 441 | \core\event\user_enrolment_deleted | 1669610 || 275 | \core\event\user_enrolment_deleted | 1411756 || 275 | \core\event\user_enrolment_created | 1410710 || 327 | \core\event\user_enrolment_created | 666552 || 327 | \core\event\user_enrolment_deleted | 666520 || 1467 | \core\event\user_enrolment_deleted | 227939 || 1464 | \core\event\user_enrolment_deleted | 227939 || 1471 | \core\event\user_enrolment_deleted | 227938 || 1465 | \core\event\user_enrolment_deleted | 227938 || 1468 | \core\event\user_enrolment_deleted | 227938 || 1469 | \core\event\user_enrolment_deleted | 227937 || 1463 | \core\event\user_enrolment_deleted | 227935 || 1467 | \core\event\user_enrolment_created | 227907 || 1464 | \core\event\user_enrolment_created | 227905 || 1465 | \core\event\user_enrolment_created | 227905 || 1471 | \core\event\user_enrolment_created | 227905 || 1468 | \core\event\user_enrolment_created | 227904 || 1461 | \core\event\user_enrolment_created | 227904 || 1469 | \core\event\user_enrolment_created | 227904 || 1463 | \core\event\user_enrolment_created | 227902 || 1461 | \core\event\user_enrolment_deleted | 227900 || 1255 | \core\event\user_enrolment_created | 227891 || 1466 | \core\event\user_enrolment_deleted | 227599 || 1466 | \core\event\user_enrolment_created | 227566 || 1255 | \core\event\user_enrolment_deleted | 227316 || 1077 | \core\event\user_enrolment_created | 227267 || 1146 | \core\event\user_enrolment_deleted | 227000 || 1077 | \core\event\user_enrolment_deleted | 226998 || 448 | \core\event\user_enrolment_deleted | 226995 || 449 | \core\event\user_enrolment_deleted | 226993 || 917 | \core\event\user_enrolment_deleted | 226992 || 1146 | \core\event\user_enrolment_created | 226967 || 448 | \core\event\user_enrolment_created | 226962 || 449 | \core\event\user_enrolment_created | 226960 || 917 | \core\event\user_enrolment_created | 226960 || 2979 | \core\event\user_enrolment_created | 142790 || 2979 | \core\event\user_enrolment_deleted | 142772 |+----------+------------------------------------+---------+38 rows in set (6 min 2.26 sec)

J'ai donc maintenant la liste de tous les cours qui présentent ce problème.

Et pour connaitre leurs dernières dates représentant beaucoup de ces actions :

SELECT FROM_UNIXTIME(timecreated) AS Date, courseid, eventname AS Event, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
WHERE courseid IN (275, 327, 1467, 1464, 1471, 1465, 1468, 1469, 1463, 1461, 1255, 1466, 1077, 1146, 448, 449, 917, 2979)
AND component='core'
AND (eventname = '\\core\\event\\user_enrolment_created'
  OR eventname = '\\core\\event\\user_enrolment_deleted')
GROUP BY Date, courseid, event
HAVING Nb > 100
ORDER BY Date DESC
LIMIT 100;

+---------------------+----------+------------------------------------+-----+| Date | courseid | Event | Nb |+---------------------+----------+------------------------------------+-----+| 2015-11-16 15:17:56 | 448 | \core\event\user_enrolment_deleted | 172 || 2015-11-16 15:17:54 | 917 | \core\event\user_enrolment_deleted | 177 || 2015-11-16 15:17:52 | 1255 | \core\event\user_enrolment_deleted | 104 || 2015-11-16 15:17:51 | 1255 | \core\event\user_enrolment_deleted | 119 || 2015-11-16 15:17:42 | 1464 | \core\event\user_enrolment_deleted | 143 || 2015-11-16 15:17:41 | 1464 | \core\event\user_enrolment_deleted | 116 || 2015-11-16 15:17:15 | 1077 | \core\event\user_enrolment_deleted | 177 || 2015-11-16 15:17:13 | 1468 | \core\event\user_enrolment_deleted | 125 || 2015-11-16 15:17:12 | 1468 | \core\event\user_enrolment_deleted | 102 || 2015-11-16 15:17:11 | 1469 | \core\event\user_enrolment_deleted | 125 || 2015-11-16 15:17:10 | 1469 | \core\event\user_enrolment_deleted | 154 || 2015-11-16 15:17:05 | 1471 | \core\event\user_enrolment_deleted | 125 || 2015-11-16 15:17:04 | 1471 | \core\event\user_enrolment_deleted | 112 || 2015-11-16 15:17:02 | 1466 | \core\event\user_enrolment_deleted | 107 || 2015-11-16 15:17:01 | 1466 | \core\event\user_enrolment_deleted | 110 || 2015-11-16 15:16:43 | 327 | \core\event\user_enrolment_created | 251 || 2015-11-16 15:16:42 | 327 | \core\event\user_enrolment_created | 262 || 2015-11-16 15:16:40 | 327 | \core\event\user_enrolment_created | 211 || 2015-11-16 14:03:38 | 1461 | \core\event\user_enrolment_deleted | 107 || 2015-11-16 14:03:37 | 1461 | \core\event\user_enrolment_deleted | 101 || 2015-11-16 14:03:31 | 448 | \core\event\user_enrolment_deleted | 202 || 2015-11-16 14:03:30 | 917 | \core\event\user_enrolment_deleted | 121 || 2015-11-16 14:03:29 | 917 | \core\event\user_enrolment_deleted | 182 || 2015-11-16 14:03:28 | 1255 | \core\event\user_enrolment_deleted | 108 || 2015-11-16 14:03:27 | 1255 | \core\event\user_enrolment_deleted | 119 || 2015-11-16 14:03:25 | 449 | \core\event\user_enrolment_deleted | 118 || 2015-11-16 14:03:24 | 449 | \core\event\user_enrolment_deleted | 113 || 2015-11-16 14:03:22 | 1146 | \core\event\user_enrolment_deleted | 152 || 2015-11-16 14:03:21 | 1146 | \core\event\user_enrolment_deleted | 101 || 2015-11-16 14:03:20 | 1464 | \core\event\user_enrolment_deleted | 158 || 2015-11-16 14:03:19 | 1464 | \core\event\user_enrolment_deleted | 114 || 2015-11-16 14:02:57 | 1077 | \core\event\user_enrolment_deleted | 121 || 2015-11-16 14:02:56 | 1077 | \core\event\user_enrolment_deleted | 172 || 2015-11-16 14:02:55 | 1468 | \core\event\user_enrolment_deleted | 148 || 2015-11-16 14:02:54 | 1468 | \core\event\user_enrolment_deleted | 167 || 2015-11-16 14:02:53 | 1469 | \core\event\user_enrolment_deleted | 146 || 2015-11-16 14:02:52 | 1469 | \core\event\user_enrolment_deleted | 158 || 2015-11-16 14:02:51 | 1465 | \core\event\user_enrolment_deleted | 112 || 2015-11-16 14:02:50 | 1465 | \core\event\user_enrolment_deleted | 125 || 2015-11-16 14:02:48 | 1471 | \core\event\user_enrolment_deleted | 160 || 2015-11-16 14:02:47 | 1471 | \core\event\user_enrolment_deleted | 106 || 2015-11-16 14:02:46 | 1466 | \core\event\user_enrolment_deleted | 162 || 2015-11-16 14:02:45 | 1466 | \core\event\user_enrolment_deleted | 114 || 2015-11-16 14:02:30 | 327 | \core\event\user_enrolment_created | 121 || 2015-11-16 14:02:29 | 327 | \core\event\user_enrolment_created | 231 || 2015-11-16 14:02:28 | 327 | \core\event\user_enrolment_created | 339 || 2015-11-16 14:02:27 | 327 | \core\event\user_enrolment_created | 145 || 2015-11-16 14:02:26 | 327 | \core\event\user_enrolment_created | 145 || 2015-11-16 13:01:17 | 1461 | \core\event\user_enrolment_deleted | 128 || 2015-11-16 13:01:16 | 1461 | \core\event\user_enrolment_deleted | 134 || 2015-11-16 13:01:11 | 448 | \core\event\user_enrolment_deleted | 195 || 2015-11-16 13:01:10 | 448 | \core\event\user_enrolment_deleted | 123 || 2015-11-16 13:01:09 | 917 | \core\event\user_enrolment_deleted | 217 || 2015-11-16 13:01:08 | 1255 | \core\event\user_enrolment_deleted | 138 || 2015-11-16 13:01:07 | 1255 | \core\event\user_enrolment_deleted | 143 || 2015-11-16 13:01:05 | 449 | \core\event\user_enrolment_deleted | 129 || 2015-11-16 13:01:03 | 1146 | \core\event\user_enrolment_deleted | 155 || 2015-11-16 13:01:02 | 1146 | \core\event\user_enrolment_deleted | 135 || 2015-11-16 13:01:01 | 1464 | \core\event\user_enrolment_deleted | 179 || 2015-11-16 13:01:00 | 1464 | \core\event\user_enrolment_deleted | 117 || 2015-11-16 13:00:42 | 1467 | \core\event\user_enrolment_deleted | 107 || 2015-11-16 13:00:41 | 1467 | \core\event\user_enrolment_deleted | 112 || 2015-11-16 13:00:40 | 1077 | \core\event\user_enrolment_deleted | 185 || 2015-11-16 13:00:39 | 1077 | \core\event\user_enrolment_deleted | 133 || 2015-11-16 13:00:38 | 1468 | \core\event\user_enrolment_deleted | 181 || 2015-11-16 13:00:37 | 1469 | \core\event\user_enrolment_deleted | 110 || 2015-11-16 13:00:36 | 1469 | \core\event\user_enrolment_deleted | 173 || 2015-11-16 13:00:35 | 1465 | \core\event\user_enrolment_deleted | 101 || 2015-11-16 13:00:34 | 1465 | \core\event\user_enrolment_deleted | 147 || 2015-11-16 13:00:32 | 1471 | \core\event\user_enrolment_deleted | 187 || 2015-11-16 13:00:31 | 1466 | \core\event\user_enrolment_deleted | 138 || 2015-11-16 13:00:30 | 1466 | \core\event\user_enrolment_deleted | 180 || 2015-11-16 13:00:15 | 327 | \core\event\user_enrolment_created | 240 || 2015-11-16 13:00:14 | 327 | \core\event\user_enrolment_created | 371 || 2015-11-16 13:00:12 | 327 | \core\event\user_enrolment_created | 212 || 2015-11-16 11:47:08 | 1461 | \core\event\user_enrolment_deleted | 122 || 2015-11-16 11:47:07 | 1461 | \core\event\user_enrolment_deleted | 123 || 2015-11-16 11:47:01 | 448 | \core\event\user_enrolment_deleted | 169 || 2015-11-16 11:47:00 | 448 | \core\event\user_enrolment_deleted | 102 || 2015-11-16 11:46:59 | 917 | \core\event\user_enrolment_deleted | 194 || 2015-11-16 11:46:57 | 1255 | \core\event\user_enrolment_deleted | 137 || 2015-11-16 11:46:55 | 449 | \core\event\user_enrolment_deleted | 121 || 2015-11-16 11:46:54 | 449 | \core\event\user_enrolment_deleted | 122 || 2015-11-16 11:46:52 | 1146 | \core\event\user_enrolment_deleted | 150 || 2015-11-16 11:46:50 | 1464 | \core\event\user_enrolment_deleted | 159 || 2015-11-16 11:46:29 | 1077 | \core\event\user_enrolment_deleted | 214 || 2015-11-16 11:46:28 | 1468 | \core\event\user_enrolment_deleted | 120 || 2015-11-16 11:46:27 | 1468 | \core\event\user_enrolment_deleted | 186 || 2015-11-16 11:46:26 | 1469 | \core\event\user_enrolment_deleted | 153 || 2015-11-16 11:46:25 | 1469 | \core\event\user_enrolment_deleted | 165 || 2015-11-16 11:46:24 | 1465 | \core\event\user_enrolment_deleted | 134 || 2015-11-16 11:46:23 | 1465 | \core\event\user_enrolment_deleted | 140 || 2015-11-16 11:46:22 | 1471 | \core\event\user_enrolment_deleted | 125 || 2015-11-16 11:46:21 | 1471 | \core\event\user_enrolment_deleted | 180 || 2015-11-16 11:46:20 | 1466 | \core\event\user_enrolment_deleted | 154 || 2015-11-16 11:46:19 | 1466 | \core\event\user_enrolment_deleted | 164 || 2015-11-16 11:46:08 | 327 | \core\event\user_enrolment_created | 114 || 2015-11-16 11:46:07 | 327 | \core\event\user_enrolment_created | 300 || 2015-11-16 11:46:06 | 327 | \core\event\user_enrolment_created | 313 || 2015-11-16 11:46:05 | 327 | \core\event\user_enrolment_created | 230 |+---------------------+----------+------------------------------------+-----+100 rows in set (4 min 29.20 sec)

Je constate donc que ces cours continuent de produire régulièrement de très grands nombres de lignes de log.

Par ailleurs, en cherchant le point commun entre ces cours, il semble que ce soit la présence de liens méta-cours masqués (la méthode d'inscription correspondant à ce lien méta-cours est cachée) qui génère ces problèmes.

En effet, si on supprime ces méthodes d'inscriptions masquées, il n'y a plus de génération de lignes d'inscription/désinscription dans les historiques

Je vais donc, pour ces différents cours, supprimer ces méthodes d'inscription masquées, puis supprimer toutes les lignes correspondantes dans les tables d'historiques !

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - log et autres éléments

par Séverin Terrier, mercredi 18 novembre 2015, 00:18

Re-bonjour,

La suite des opérations.

Après suppression de ces méthodes d'inscription par méta-cours (qui étaient masquées/désactivées), j'ai également (pour test) créé dans d'autres cours (989 et 472) de telles méthodes d'inscription par méta-cours masquées.

J'ai ensuite lancé ces requêtes pour voir le nombre d'éléments récents inscrits dans les tables d'historiques (en spécifiant la date du jour, ce qui génère des requêtes qui s'exécutent plus vite) :

SELECT courseid, eventname, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
WHERE component='core'
AND timecreated > 1447750800
AND (eventname = '\\core\\event\\user_enrolment_created'
  OR eventname = '\\core\\event\\user_enrolment_deleted')
GROUP BY courseid, eventname
HAVING Nb > 30
ORDER BY Nb DESC, courseid
LIMIT 100;

+----------+------------------------------------+------+| courseid | eventname | Nb |+----------+------------------------------------+------+| 989 | \core\event\user_enrolment_deleted | 1677 || 989 | \core\event\user_enrolment_created | 1677 || 448 | \core\event\user_enrolment_created | 318 || 448 | \core\event\user_enrolment_deleted | 318 || 449 | \core\event\user_enrolment_created | 318 || 449 | \core\event\user_enrolment_deleted | 318 || 917 | \core\event\user_enrolment_created | 318 || 917 | \core\event\user_enrolment_deleted | 318 || 1077 | \core\event\user_enrolment_created | 318 || 1077 | \core\event\user_enrolment_deleted | 318 || 1146 | \core\event\user_enrolment_created | 318 || 1146 | \core\event\user_enrolment_deleted | 318 || 1255 | \core\event\user_enrolment_deleted | 318 || 1255 | \core\event\user_enrolment_created | 318 || 1461 | \core\event\user_enrolment_created | 318 || 1461 | \core\event\user_enrolment_deleted | 318 || 1463 | \core\event\user_enrolment_deleted | 318 || 1463 | \core\event\user_enrolment_created | 318 || 1468 | \core\event\user_enrolment_deleted | 318 || 1468 | \core\event\user_enrolment_created | 318 || 1469 | \core\event\user_enrolment_deleted | 318 || 1469 | \core\event\user_enrolment_created | 318 || 1471 | \core\event\user_enrolment_deleted | 318 || 1471 | \core\event\user_enrolment_created | 318 || 472 | \core\event\user_enrolment_created | 63 || 472 | \core\event\user_enrolment_deleted | 63 |+----------+------------------------------------+------+26 rows in set (0.19 sec)

SELECT course, action, COUNT(1) as Nb
FROM mdl_log
WHERE time > 1447750800
AND module='course'
AND (action='enrol' OR action='unenrol')
GROUP BY course, action
HAVING Nb > 30
ORDER BY Nb DESC, course;

+--------+---------+------+| course | action | Nb |+--------+---------+------+| 989 | enrol | 1677 || 989 | unenrol | 1677 || 448 | enrol | 318 || 448 | unenrol | 318 || 449 | enrol | 318 || 449 | unenrol | 318 || 917 | unenrol | 318 || 917 | enrol | 318 || 1077 | enrol | 318 || 1077 | unenrol | 318 || 1146 | enrol | 318 || 1146 | unenrol | 318 || 1255 | enrol | 318 || 1255 | unenrol | 318 || 1461 | enrol | 318 || 1461 | unenrol | 318 || 1463 | unenrol | 318 || 1463 | enrol | 318 || 1468 | enrol | 318 || 1468 | unenrol | 318 || 1469 | enrol | 318 || 1469 | unenrol | 318 || 1471 | unenrol | 318 || 1471 | enrol | 318 || 472 | enrol | 63 || 472 | unenrol | 63 |+--------+---------+------+26 rows in set (0.05 sec)

En relançant ces requêtes une ou deux heures plus tard, je constate que les nombres ont bien augmenté pour les nouveaux cours concernés (volontairement, pour test), alors que les autres n'ont pas changé. Cela confirme donc bien le problème (et la solution actuelle : supprimer ces méthodes d'inscriptions par méta-cours masquées).

Et si, dans mes cours de test, j'active mes méthodes d'inscription par méta-cours, j'ai bien les inscriptions (mais pas les désinscriptions) qui augmentent (un peu, du nombre d'étudiants concernés, une fois), ce qui est logique.

Ayant bien compris le problème, je fais donc maintenant le grand ménage dans mes tables d'historiques avec les requêtes suivantes (qui prennent très très longtemps, vu le nombre de lignes à supprimer) :

DELETE FROM mdl_logstore_standard_log
WHERE courseid IN (275, 327, 1467, 1464, 1471, 1465, 1468, 1469, 1463, 1461, 1255, 1466, 1077, 1146, 448, 449, 917, 2979)
AND component='core'
AND (eventname = '\\core\\event\\user_enrolment_created'
  OR eventname = '\\core\\event\\user_enrolment_deleted');

DELETE FROM mdl_log
WHERE course IN (275, 327, 1467, 1464, 1471, 1465, 1468, 1469, 1463, 1461, 1255, 1466, 1077, 1146, 448, 449, 917, 2979)
AND module='course'
AND (action='enrol' OR action='unenrol');

En gros, 50 minutes par requête, pour la suppression de plus de 11 000 000 de lignes à chaque fois !

Je viens de déclarer ce bogue lié aux inscriptions par méta-cours masquées (qui touchait déjà manifestement au moins Moodle 2.7) : MDL-52186

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - log et autres éléments

par Séverin Terrier, lundi 14 décembre 2015, 21:37

Bonjour,

En supprimant ces différents éléments des tables de log, j'avais réduit le nombre d'enregistrements des tables d'environ un tiers. Pour autant, la place occupée sur le disque est restée identique

C'est en effet "normal", et lié au moteur de stockage InnoDB de MySQL. Même en étant configuré pour avoir un fichier spécifique par table, le principe d'InnoDB est (en gros) de "réserver" de l'espace disque, qui grossi au fur et à mesure de l'utilisation (et de l’insertion de données).

Mais, lorsqu'on supprime des lignes, l'espace disque n'est pas libéré pour autant !

Si on voulait réellement récupérer de l'espace disque, il faudrait, au choix :

passer les tables concernées au format MyISAM, puis les repasser au format InnoDB
exporter/sauvegarder les tables concernées, les supprimer, puis les recréer et les ré-alimenter à partir des sauvegardes

Ces deux opérations nécessiteraient un arrêt de Moodle, assez long pour avoir le temps de traiter des tables avec autant de données. Du coup, je me suis abstenu pour le moment... Sachant malgré tout que, en faisant des sauvegardes des données, seules les données encore existantes sont sauvegardées.

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - log et autres éléments

par Anne Garnavault Remy, mercredi 6 janvier 2016, 19:20

Bonjour ,

Tout d'abord une très bonne année a ceux qui passent ici ;)

Je reviens sur ce problème, bien que pour nous il concerne Moodle 2.7.11.

Nous avons les deux méthodes d'historiques activées. ( nous ne sommes en 2.7 que depuis août et nous gardons les historiques un an) .

Nos tables grossissent à vue d' oeuil , en particulier celles des historiques standard. Depuis un mois nous avons augmenté la durée d’exécution des requêtes pour que les sauvegardes automatiques puissent s'effectuer ( elles plantaient sur la page d’accueil) .

Nous n'appliquerons pas le patch indiqué ( nous les éliminons au maximum).

A ce jour , la table mdl_logstore_standard_log est à environ 25GO ( en quatre mois!) ( en comparaison la table mdl_log qui conserve bien sur 365 jours reste stable à 17/18 GO) .

Nous sommes à la recherche d'une solution possible et voici les propositions de l'admin de base de données:

- Limiter les logs. Depuis la version 2.7, n'y a-t-il pas un moyen de spécifier quelles informations nous voulons loguer? Si oui, je pense qu'il est vraiment nécessaire de le faire, car en extrapolant nous courrons vers une table de plus de 100Go et qqs 300.000.000 de lignes qu'il faudra parser... (très gros ralentissements à prévoir...)
(ceci ne concerne pas "l'ancienne" table mdl_log)

- Créer des index supplémentaires. C'est une première option, mais cela devrait au moins résoudre le problème des backups.

- Partitionner les tables de logs. ....Le problème, c'est que le risque d'avoir des ennuis lors des mises à jour est fortement augmenté. Si la mise à jour doit modifier les tables de logs, le risque de crash est proche de 100%. Dans ce cas, il faudra restaurer les backups, refaire les tables telles qu'elles étaient, passer la mise à jour et repartitionner les tables (cette dernière opération peut prendre plus d'une heure). "

Pour limiter les logs, je n'ai rien trouvé ( à part dans les options si nous déportons la table et cela est très limité) .

Pour les deux autres solutions, avez vous des expériences à nous transmettre?

Enfin, en effectuant quelque requêtes et recherches sur les forums , j'ai trouvé cela : https://moodle.org/mod/forum/discuss.php?d=268807
une requête chez nous donne cela:

mysql> select COUNT(*) from mdl_logstore_standard_log where origin="cli" and target="calendar_event" and courseid='0';


+----------+
| COUNT(*) |
+----------+
| 54238345 |
+----------+


mysql> select COUNT(*) from mdl_logstore_standard_log where origin="cli" and target="calendar_event" and courseid != '0';


+----------+
| COUNT(*) |
+----------+
|    10363 |
+----------+

Quel est le risque de supprimer ces lignes? Ça ferait bien de la place ....D'autre part je me demandais si nous en avons autant, n'est ce pas du au fait que nous affichons le calendrier en page d’accueil (My) .
Merci
Anne

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - log et autres éléments

par Séverin Terrier, mercredi 3 février 2016, 23:16

Pour les personnes intéressées, Anne a relancé cette discussion dans un fil dédié, dans lequel des réponses adaptées auront pu être apportées.

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.3 - log et autres éléments

par Anne Garnavault Remy, mardi 16 février 2016, 17:22

Bonjour

Nous avons résolu pas mal de soucis autour des logs: voir le fil dédié.

Et au passage, nous sommes passés à une seule méthode de conservation des logs et désactivé les historiques obsolètes ( pas supprimé pour faire quelques requêtes avant l'arrivée des logs standard, soit pour nous depuis fin août 2015; fin août 2016, nous pourrons complètement les supprimer, puisque nous gardons les historiques sur un an. ) . Nous avons aussi désactivé les historiques embarqués dans les sauvegardes.

Résultat: la première requête du script automated_backup.php qui parcours la page d’accueil fait moins de 1mn ( contre 7 auparavant! ) , la page d’accueil est "passée" si non modifiée depuis moins de 30 jours ( alors qu'elle était systématiquement sauvegardée) et bien sûr nos temps de sauvegarde on considérablement diminué (passés de 12/14h à 5/7h).

Bonne journée

Anne

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2

par Bruno Malaval, mercredi 4 novembre 2015, 00:17

Bonjour Séverin,

Un petit retour sur la question de la sauvegarde de la page d'accueil

Est-ce-que le problème ne pourrait pas venir de MySQL uniquement ?
Je ne suis pas spécialiste MySQL, mais je suis tombé récemment sur un article dans lequel il était question des tables temporaires.

Si j'ai bien compris, slle sont créées en générale lors de requêtes volumineuses, qui utilisent notamment la fonction "GROUP BY"

Par contre, ces tables sont détruites dès que la session MySQL se termine, si tout se passe bien ..
Il arrive que ces tables restent dans la passe si la connexion est perdue de facon abrupte (timeout)

Il faut également faire attention aux variables d'environnement concernant ces tables dans le fichiers my.cnf
(une petite explication sur ce point : http://dasini.net/blog/2010/05/28/audit-mysql-tmp_table_size-max_heap_table_size/ )

C'était une idée en passant, il serait intéressant de pousser les logs MySQL au maximum de détails lors d'une sauvegare pour voir s'il n'y pas une indication dedans.

Mais pas trop longtemps, juste le temps de la sauvegarde, sinon tu vas remplir le disque ...

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2

par Séverin Terrier, vendredi 6 novembre 2015, 17:16

Bonjour Bruno,

Merci de t'intéresser à mes problèmes de sauvegarde, et pour cette piste.

Malgré tout, au niveau de mes réglages de MySql, dans le fichier my.cnf, j'ai les valeurs suivantes :

tmp_table_size = 512M
max_heap_table_size=512M

Et le script de vérification tuning-primer.sh m'indique que sur 30095682 tables temporaires, 12% ont été créées sur le disque. A priori, cela me semblerait pas mal. Mais il suffit effectivement que les 12% concernent et génèrent les blocages...

A une époque, ces paramètres étaient réglés à 1 G, mais je crois qu'on restait dans des valeurs équivalentes de tables créées sur le disque. Je pourrais éventuellement essayer de repasser sur ces valeurs, pour tester.

Tout logguer finement pourrait être une autre possibilité, mais à utiliser avec prudence, comme tu l'indiques.

Séverin

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2

par Luiggi Sansonetti, jeudi 26 novembre 2015, 18:18

bonjour

un gros travail de documentation, de tests, et de partage que tu nous fais là en mode lonesone cowboy

mais une bible pour ceux qui doivent gérer la chose dans le côté obscur de Moodle !

merci à toi en tout cas

Moyenne des évaluations -

Re: Problèmes sauvegardes automatiques Moodle 2.9.2

par Séverin Terrier, jeudi 26 novembre 2015, 18:52

Bonjour,

Effectivement, je me disais que j'allais poster (dans quelques jours, après vérification de tout le bon fonctionnement), un message du style "Merci à tou(te)s pour votre aide ".

Il est vrai que je me suis senti un peu seul sur ce coup là ; comme souvent sur les problématiques sur lesquelles je tombe, qui ne touchent pas forcément grand monde.

Mais pour les côtés positifs, cela m'aura permis de :

avoir des sauvegardes qui fonctionnent (enfin) toutes
faire du ménage dans ma base de données
découvrir un bogue sur les inscriptions par méta-cours masquées : MDL-52186
découvrir que la suppression d'un cours ne supprimait pas ses historiques !
mieux comprendre ce qui existe dans la base de données interne de Moodle
aider la communauté, y compris anglaise (voire moi-même si je retombe sur le même problème plus tard)

Séverin

Moyenne des évaluations Utile (1)

Re: Problèmes sauvegardes automatiques Moodle 2.9.2

par Séverin Terrier, vendredi 18 novembre 2016, 20:49

Bonjour,

Pour information, le bogue MDL-52186 lié aux inscriptions par méta-cours masquées (évoqué depuis ce message) est maintenant corrigé.

La correction sera intégrée dans Moodle 3.1.4 (elle l'est dans la dernière 3.1.3+) et Moodle 3.2.

Séverin

Moyenne des évaluations -