Crash base après upgrade 3.0.17 vers 3.0.21

phlinux

Novembre 2015

Sur l’une de mes bases passée récemment de 3.0.17 en 3.0.21, j’ai depuis, deux tables spip qui sont de temps à autre marquées comme crashées et je n’arrive pas à repérer le moment où cela se produit.

Je répare heureusement sans problème avec isamcheck -r -q table.MYI, l’erreur ne se produit plus mais reparaît quelque temps après.

Jusque là, cela s’est produit avec spip_versions et spip_versions_fragments.

Exemple de ce soir (mais pour cette fois une seule table est marquée crashée) :

Checking MyISAM file: spip_versions_fragments.MYI
Data records:    5704   Deleted blocks:       0
myisamchk: warning: Table is marked as crashed and last repair failed
- check file-size
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
- check record links
MyISAM-table 'spip_versions_fragments.MYI' is usable but should be fixed

# service mysql stop
# myisamchk -r -q spip_versions_fragments.MYI

- check record delete-chain
- recovering (with sort) MyISAM-table 'spip_versions_fragments.MYI'
Data records: 5704
- Fixing index 1

J’ai bien sûr vérifié l’arrêt et le démarrage de mysql autant en commande en ligne que via les services. Ils ne génèrent pas l’incident.

Quelqu’un a-t-il une idée sur comment tracer ce problème ?
Si le cron spip met en oeuvre les tables qui crashent ?

Je suis passé de 3.0.17 à 3.0.21. J’utilise Debian 8.2 - PHP 5.6 - MariaDB Ver 15.1 Distrib 10.0.22-MariaDB.

Merci d’avance pour toute piste ;)

Résolu

Par note Par date Par date chronologique

Indiquez l’intérêt que vous portez à cette réponse

0

phlinux

Novembre 2015

Personne n’a d’inspiration ?

En fait, à ce jour c’est la seule de mes bases dans cette version de SPIP avec laquelle cela se passe.
Je n’ai pas d’erreur dans les logs de SPIP à part l’indication des "crash" !
Je constate que cela ne se produit que lors d’une simple consultation des pages du site et pas en requêtant directement la base SPIP (select, insert, update ...).
Il y a donc bien une action sur les tables spip_version et spip_version_fragment qui provoquent le problème et, d’après le code trouvé dans inc/revisions.php, j’ai l’impression qu’elle doit être liée au « versionnage » des articles.
Or je ne fais que consulter les pages ... pas de mise à jour ... il ne devrait donc pas y avoir de modification de version ?

Merci quand même :-)
Indiquez l’intérêt que vous portez à cette réponse

0

b_b

Novembre 2015

Salut, as tu tenté de lancer une réparation de la base depuis la page de maintenance technique (?exec=admin_tech) ?
Indiquez l’intérêt que vous portez à cette réponse

0

Novembre 2015

Bonjour,

oui, j’ai essayé les deux solutions : par les outils spip et par mysql.
La réparation se fait bien via SPIP mais le problème revient.
Je ne sais toujours pas à quel moment ou avec quelle action ...

Réparation maintenance SPIP :
... spip_versions (843 éléments) : cette table est OK. spip_versions_fragments (5704 éléments) : cette table est OK. ...
La réparation a bien été faite :
# service mysql stop # myisamchk *.MYI | grep crash # service mysql start

Merci pour ton intervention
Indiquez l’intérêt que vous portez à cette réponse

0
phlinux

Décembre 2015
J’ai finalement trouvé où se situe le problème mais pas pourquoi ...

il réside dans un job lancé par spip : optimiser les revisions qui à chaque fois qu’il est lancé, provoque le crash des deux tables qui, pour rappel, sont spip_versions et spip_versions_fragments.

Il reste donc maintenant à déterminer, en partant de la fonction sql_optimize de base_abstract.php, ce qui peut bien polluer les indexes de ces tables (pb de lock, d’écriture concurrentes ?)

Si quelqu’un a une idée ...

Je détaille ci-après ici ma démarche qui pourrait éventuellement servir à d’autres.

Pour avoir un meilleure idée du problème, il a suffi d’utiliser les options dvi de myisamchk sur les tables qui crashent (thousand of thanks to montywy).

myisamchk -dvi spip_version.MDY
Dans le retour de cette commande on peut voir que le statut indique crashed on repair :
MyISAM file: spip_versions_fragments.MYI Record format: Packed Character set: latin1_swedish_ci (8) File-version: 1 Creation time: 2015-11-14 15:12:07 Recover time: 2015-12-22 18:00:01 Status: crashed on repair Data records: 5714 Deleted blocks: 0 Datafile parts: 5714 Deleted data: 0 Datafile pointer (bytes): 6 Keyfile pointer (bytes): 6 Datafile length: 1038092 Keyfile length: 79872 Max datafile length: 281474976710654 Max keyfile length: 288230376151710719 Recordlength: 60 --- snip ---
Comme mon serveur n’était pas utilisé à ce moment là (je suis par ailleurs seul à l’utiliser) le fautif était donc une tâche du genre cron et non une manipulation que j’aurais pu faire.

Or il existe dans SPIP un gestionnaire de travaux qui exécute à intervalles réguliers des travaux de maintenance. L’un deux agit sur les 2 tables *versions* : optimiser les revisions.

Pour le vérifier, il a suffit de réparer les tables, avec, par exemple :
CHECK TABLE mydoc.spip_versions_fragments;
+-------------------------------+-------+----------+---------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +-------------------------------+-------+----------+---------------------------------------------------+ | mydoc.spip_versions_fragments | check | warning | Table is marked as crashed and last repair failed | | mydoc.spip_versions_fragments | check | status | OK | +-------------------------------+-------+----------+---------------------------------------------------+
et de relancer en le forçant le job d’optimisation pour voir que le crash se reproduit immédiatement après.
Indiquez l’intérêt que vous portez à cette réponse

0

b_b

Décembre 2015

Salut, peux-tu poster toutes ces infos dans un ticket sur https://core.spip.net/ ? Ainsi on pourra garder une trace du bug et en discuter avec le reste de l’équipe.
Indiquez l’intérêt que vous portez à cette réponse

0
phlinux

Décembre 2015
Je prépare cela ... je viens de trouver le problème :
L’optimisation se fait en lançant :
req/mysql.php function spip_mysql_optimize($table, $serveur='',$requeter=true){ spip_mysql_query("OPTIMIZE TABLE ". $table); return true; }
en lançant à la main l’optimisation de mes tables qui crashent dans mysql, j’obtient :
> optimize table mydoc.spip_versions_fragments; +-------------------------------+----------+----------+-----------------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +-------------------------------+----------+----------+-----------------------------------------------------------------------------+ | mydoc.spip_versions_fragments | optimize | error | Can't create new tempfile: '/bases/mysql/mydoc/spip_versions_fragments.TMM' | | mydoc.spip_versions_fragments | optimize | status | Operation failed | +-------------------------------+----------+----------+-----------------------------------------------------------------------------+ 2 rows in set (0.00 sec)
Indiquez l’intérêt que vous portez à cette réponse

0

b_b

Décembre 2015

Re, la partie Can’t create new tempfile dans le message d’erreur peut provenir d’un problème de droits :

https://bugs.mysql.com/bug.php?id=54828

Sinon, essaye peut-être avec un myisamchk -rcf http://stackoverflow.com/questions/8843776/mysql-table-is-marked-as-crashed-and-last-automatic-repair-failed

Hésite pas à passer en discuter sur IRC http://irc.spip.net
Indiquez l’intérêt que vous portez à cette réponse

0
phlinux

Décembre 2015
@ b_b Merci pour ton retour mais ce sont des points que j’avais déjà vérifiés avec l’espace disque. Quant à la réparation des tables, elle fonctionnait bien mais le problème revenait plus tard.

En réalité, je me suis aperçu que j’avais plusieurs fichiers avec l’extension TMM. Tous ces fichiers avaient une taille à 0 ! Et c’est effectivement cité à la dernière ligne de https://bugs.mysql.com/bug.php?id=54828.

Pour terminer, voici mon raisonnement et ce que j’ai déroulé :

Je confirme, le crash est bien reproduit en forçant l’exécution de ce job. Il lance la fonction :
> SELECT descriptif, fonction FROM mydoc.spip_jobs where descriptif like '%optimiser_revisions%';
---------------------------------------------------------- --------------------- | descriptif | fonction | ---------------------------------------------------------- --------------------- | Tâche CRON optimiser_revisions (toutes les 86400 s) | optimiser_revisions | ---------------------------------------------------------- --------------------- 1 row in set (0.00 sec)
Il s’agit de la fonction plugins-dist/revisions/genie/optimiser_revisions.php.

Elle appelle entre autres optimiser_tables_revision() qui elle même appelle sql_optimize($table).

En fait sql_optimize($table), dans mon cas, lance sur la table passée en argument, la commande :
OPTIMIZE TABLE SCHEMA.SPIP_VERSIONS_FRAGMENTS

En lançant manuellement cette commande dans mysql, sans surprise, j’obtient bien un crash :
optimize table mydoc.spip_versions_fragments;
------------------------------- ---------- ---------- ----------------------------------------------------------------------------- | Table | Op | Msg_type | Msg_text | ------------------------------- ---------- ---------- ----------------------------------------------------------------------------- | mydoc.spip_versions_fragments | optimize | error | Can't create new tempfile: '/bases/mysql/mydoc/spip_versions_fragments.TMM' | | mydoc.spip_versions_fragments | optimize | status | Operation failed | ------------------------------- ---------- ---------- -----------------------------------------------------------------------------
Et là, le problème est mis en évidence : mysql ne peut pas ou ne veut pas écrire spip_versions_fragments.TMM

Les droits d’accès au répertoire et aux fichiers sont corrects (rw pour le process mysql), par contre je remarque qu’il y a plusieurs fichiers TMM, dont un pour spip_versions et un autre pour spip_versions_fragments, et ils sont tous vides !

Donc :
– myisamcheck -r -q sur les tables crashées pour les remettre d’aplomb
– arrêt de securité de service mysql et archivage du répertoire complet pour sauvegarde
destruction des TMM vides
– (Je n’ai pas trouvé d’ifo précise sur leur existance mais il semble que les fichiers *.TMM semblent être des fichiers de travail,
temporaires donc)
– relance de mysql
– myisamchk -s *version*.MYI ne montre pas de corruption
– relance d’une optimisation sur les tables : tout se passe correctement : bingo !!
optimize table mydoc.spip_versions_fragments; optimize table mydoc.spip_versions;
------------------------------- ---------- ---------- ----------------------------- | Table | Op | Msg_type | Msg_text | ------------------------------- ---------- ---------- ----------------------------- | mydoc.spip_versions_fragments | optimize | status | Table is already up to date | ------------------------------- ---------- ---------- ----------------------------- 1 row in set (0.00 sec) --------------------- ---------- ---------- ----------------------------- | Table | Op | Msg_type | Msg_text | --------------------- ---------- ---------- ----------------------------- | mydoc.spip_versions | optimize | status | Table is already up to date | --------------------- ---------- ---------- ----------------------------- 1 row in set (0.00 sec)
Dernière vérification via SPIP avec la relance du job optimiser_revisions :

Tââââ Dââââââ plus de crash :)
Indiquez l’intérêt que vous portez à cette réponse

0

b_b

Décembre 2015

Salut, d’après le ticket que je pointais il semble qu’il s’agisse d’un bug du côté de MySQL, en tout cas, content que tu aies résolu ton problème :)

Quelle version de MySQL utilises-tu ? Il faudrait peut-être envisager une mise à jour de ce côté sur ton serveur.
Indiquez l’intérêt que vous portez à cette réponse

0

phlinux

Décembre 2015

Merci b_b,

j’utilise mariadb 10.0.22 avec PHP 5.6.14-0+deb8u1 et c’est la dernière version disponible dans le repository Debian 8.

Ce problème semble exister depuis déjà pas mal de temps (j’ai trouvé la trace d’un problème identique dans mysql datant de janvier 2012)

Après recherches je vois qu’il semble être corrigé dans mariadb 10.1.x
bug MDEV-8475 corrigé en 10.1.6 pour le moteur ariadb
bug MDEV-8571 corrigé en 10.0.23, 10.1.10
bug 54828 je ne vois pas s’il a été corrigé.

Par contre, peut être que dans SPIP, quand l’optimiseur est lancé et qu’un fichier TMM existe déjà, il serait peut être souhaitable de le détruire, ou le renommer en .bak ou au moins simplement l’indiquer dans la log LOG_INFO ???

Pour information, j’ai bien la confirmation que les fichiers TMM (et TMD) sont temporaires d’après leur définition dans le code source et le fichier header myisam/myisamdef.h
#define INDEX_TMP_EXT ".TMM" #define DATA_TMP_EXT ".TMD"
Indiquez l’intérêt que vous portez à cette réponse

0

b_b

Décembre 2015

Hop, de mon côté j’utilise mariadb 10.0.23 depuis le repo http://nwps.ws/pub/mariadb/repo/10.0/ubuntu/ et je n’ai jamais rencontré ce problème (comme tu le signales, le bug est corrigé dans cette version).

Pour ce qui est du patch côté SPIP, il me semble compliqué/contre productif de demander à SPIP de gérer un éventuel bug de mysql/mariadb, car l’API sql générique se veut justement générique afin de fonctionner sur d’autres sgbd. On peut en discuter sur la liste spip-dev si tu veux.

++
Indiquez l’intérêt que vous portez à cette réponse

0

phlinux

Décembre 2015

D’après mes petites notes (celles justement gérées dans ma base de documentation) je suis à peu près sûr maintenant de l’origine du problème :

J’avais eu un problème avec spip_loader lors de ma dernière mise à jour de 3.0.17 vers 3.0.21) ? Celle-ci ne finissait pas et après avoir attendu plus d’une heure, j’avais dû l’interrompre sauvagement (kill).

Pas le temps de chercher et de faire des tests, j’ai restauré ma base, refait une installation traditionnelle à partir d’un tarball et n’ai pas rencontré de soucis particulier sauf que ...

soit les TMM existaient déjà et ce sont eux qui ont fait "hanger" le process de mise à jour, soit le process était bien toujours en route et en le tuant j’ai laissé derrière moi les TMM.

Je penche plutôt pour la seconde solution mais ce qui m’étonne c’est le temps que cela prenait. Avec mon i7 8 cœurs et 8G de RAM, en général, cela pédale plutôt bien !!!. Or, avec exactement la même base, cela a été très vite sur mon vieux pc portable qui me sert aux devs.

En ce qui concerne le patch, je pense en effet que tu as complètement raison. Ce n’est pas à SPIP de jouer des contournements pour des problèmes externes.

Par contre peut être pourrait-on laisser une trace spip_log() dans LOG_INFO voire LOG_DEBUG, qu’un ou des fichiers TMM et/ou TMD sont toujours présents car le comportement dans ce cas est loin d’être évident.

Merci encore,
A+
Indiquez l’intérêt que vous portez à cette réponse

0

b_b

Décembre 2015

Hop,

Par contre peut être pourrait-on laisser une trace spip_log() dans LOG_INFO voire LOG_DEBUG, qu’un ou des fichiers TMM et/ou TMD sont toujours présents car le comportement dans ce cas est loin d’être évident.

Malheureusement on ne peut pas accéder à ces informations sur tous les types d’hébergement.
Indiquez l’intérêt que vous portez à cette réponse

0

phlinux

Décembre 2015

Bonjour,

@b_b : bah, j’avoue que je ne comprends pas bien l’argument de ta réponse.

Les logs, c’est précieux. Si certains hebergeurs ne permettent pas la consultation des logs générés, cela doit pas faire oublier ceux qui le peuvent. De même, cela serait utile pour les sites de dev qui sont souvent perso, comme pour moi, pour lever des "loups" avant une mise en prod.

Mais bon, ce n’est que mon avis ;)

PS : j’ai essaye de te joindre sur #maria ... pas facile, on ne doit pas avoir les même heures :D

Puisqu’il ne s’agit pas d’un problème SPIP, un post sur https://core.spip.net/ est il toujours utile ?
Indiquez l’intérêt que vous portez à cette réponse

0

b_b

Décembre 2015

Hop,

bah, j’avoue que je ne comprends pas bien l’argument de ta réponse.

SPIP n’a pas forcément accès à cette information (présence de fichier tmm/tmd) suivant le type d’hébergement utilisé.

PS : j’ai essaye de te joindre sur #maria ... pas facile, on ne doit pas avoir les même heures :D

Essaye sur #spip @ freenode, tu auras plus de chances de m’y croiser :)

Pour le ticket, je ne suis pas certain qu’il soit utile, puisqu’on ne pourra pas détecter ce bug sql sur toutes les configurations.
Indiquez l’intérêt que vous portez à cette réponse

0

Pascal23

Janvier 2016

Bonjour,

J’ai le même souci depuis le début de l’année...
Un site en 3.0.17 qui soudainement m’indique que la table spip_jobs est crashée avec un tableau d’erreur (sur la droite de la page privée) me donnant plein de ligne d’ARRAY mais sans autre information.

Je vais voir la page CRON (liste des travaux de SPIP) : Aucun travail en attente, m’informe-t-on... Ce n’est pas normal, il y a toujours des tâches Cron en cours avec SPIP.

Je ne m’inquiète cependant pas et tente la réparation : ok, réparée... Ouf !
Mais hélas deux jours plus tard : même souci, sur la même table !

Après passage en SPIP 3.0.21 : idem = même souci.

J’utilise un hébergement mutualisé perfo1 chez OVH, avec PHP 5.5.30 et une BDD MySql 5.5.46-0+deb7u1-log

Que dois-je faire exactement ?
Et dois-je ouvrir un ticket ?
Indiquez l’intérêt que vous portez à cette réponse

0
Pascal23

Janvier 2016
et voici le message de SPIP lors de la réparation de la BDD :
- spip_jobs (16 éléments) : siteenquestion.spip_jobs repair warning Number of rows changed from 18 to 16
Indiquez l’intérêt que vous portez à cette réponse

0

Janvier 2016

Bonjour,

a priori, ce n’est pas lié à SPIP mais à mysql ou mariadb.

Il faudrait d’abord vérifier si c’est bien le même cas de figure que celui que j’ai eu.
A savoir des fichiers avec l’extension TMM (table temporaire d’indexes) sont présents parmi les fichiers de tables classiques. En l’occurrence, ici, vérifier s’il n’y a pas un fichier spip_jobs.TMM. (en particulier avec une taille à 0)

Si oui, avant de faire une réparation, arrêter mysql complètement et lancer un myisamchk -dvi spip_jobs.MYI afin de vérifier le contenu de Status

Pour moi, il indiquait clairement Status : crashed on repair d’où mon orientation sur les jobs de spip.

Renommer le (ou les) fichier .TMM en .old pour une sauvegarder au cas où, et réparer avec myisamchk -r -q spip_jobs.MDY. Il pourra être ensuite supprimé plus tard sans problème, quand tout sera bien ok.

Je pense avoir bien détaillé plus haut les opérations que j’ai effectuées. Essaie d’en suivre le cheminement et si quelque chose n’était pas clair n’hésites pas à poster.

A noter, dans l’onglet maintenance de la zone privée, la liste des jobs de maintenance indique dans combien de temps les jobs soumis à cron vont se ré-executer.
Indiquez l’intérêt que vous portez à cette réponse

0

Janvier 2016

Cela ressemble plutôt à un crash des données. (fichier MYD) ce qui est très différent de ce que j’ai eu. (fais bien des sauvegardes à froid des fichiers avant manip ...)
Il faudrait essayer de faire un fsck sur le disque pour voir ce qui s’y passe.
Indiquez l’intérêt que vous portez à cette réponse

0

Pascal23

Janvier 2016

Merci pour ta réponse, mais penses-tu que je puisses faire ces commandes avec PhpMyAdmin ?
N’ayant pas de serveur privé (mais mutualisé), je n’ai d’autre outil accessible à ma disposition :’(
Indiquez l’intérêt que vous portez à cette réponse

0

Janvier 2016

Désolé, je n’utilise que la commande en ligne. (J’ai aussi un serveur chez OVH mais c’est un VPS et là aussi je ne fais que de la commande en ligne ... old school)

Je ne connais pas phpmyadmin mais il me semble que l’on ne peut que passer des requêtes sql. (pas d’accès systeme)

Sans accès aux fichiers cela me semble plus compliqué.

Essaie peut être d’executer la requête :

optimize table spip_jobs;

pour voir s’il y a un peu de détails dans la colonne Msg_text
Indiquez l’intérêt que vous portez à cette réponse

0

Janvier 2016

On peut utiliser également la requête REPAIR mais je ne sais pas si cela peut être utilisé par myadminphp.

Même si elle ne renvoie pas tout ce qui est donné par myisamchk, apparemment elle donnera également le status :

soit REPAIR TABLE spip_jobs
REPAIR [NO_WRITE_TO_BINLOG | LOCAL] TABLE tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]
« REPAIR TABLE returns a result set with the following columns.
Column Value
Table The table name
Op Always repair
Msg_type status, error, info, note, or warning
Msg_text An informational message

The REPAIR TABLE statement might produce many rows of information for each repaired table. The last row has a Msg_type value of status and Msg_test normally should be OK. If you do not get OK for a MyISAM table, you should try repairing it with myisamchk —safe-recover. (REPAIR TABLE does not implement all the options of myisamchk.) With myisamchk —safe-recover, you can also use options that REPAIR TABLE does not support, such as —max-record-length. »
Indiquez l’intérêt que vous portez à cette réponse

0

Pascal23

Janvier 2016

@phlinux —>Avec PhpMyAdmin, j’ai pu exécuter :

optimize table spip_jobs
Cela m’a donné comme retour :
Op : optimize / Msg_type : Status / Msg_text : OK

REPAIR TABLE spip_jobs
Cela m’a aussi donné comme retour :
Op : repair / Msg_type : Status / Msg_text : OK

On va bien voir si dans deux jours, j’ai le même souci ou pas...
Indiquez l’intérêt que vous portez à cette réponse

0

Janvier 2016

Ok. Le problème était sans doute réparé au moins temporairement.
Si cela se reproduit, essaie d’abord le repair table et poste le résultat stp.
La colonne Msg_text pourrait être intéressante.

As tu un accès à ton serveur via ftp? Tu pourrais peut être alors voir pas ce biais, le contenu du répertoire de la base et s’il y a des fichiers TMM
Indiquez l’intérêt que vous portez à cette réponse

0

Pascal23

Janvier 2016

Petit retour depuis le 6 dernier...
Il semble que ce qui a été effectué a suffit pour régler le souci.
Voili, voilou... En tous les cas : merci pour ton aide :)

« Précédent 1 2 Suivant »