Fiabilité des révisions #3225

Open
opened 8 years ago by cerdic · 3 comments
cerdic commented 8 years ago
Owner

Les révisions zipées et stockées en binaire en base sont corrompues par certaines opérations de type backup/restauration ou migration via le plugin homonyme.
Il faut peut-être simplement supprimer le zippage binaire et stocker les révisions au format texte.

Les révisions zipées et stockées en binaire en base sont corrompues par certaines opérations de type backup/restauration ou migration via le plugin homonyme. Il faut peut-être simplement supprimer le zippage binaire et stocker les révisions au format texte.
Poster
Owner

http://zone.spip.org/trac/spip-zone/changeset/85691/core/plugins/revisions va ameliorer le probleme en desactivant la compression, mais parfois les fragments serialize cassent pour une histoire de saut de ligne, c'est pas robuste. A completer plus tard
Version cible mise à 3.2

http://zone.spip.org/trac/spip-zone/changeset/85691/_core_/plugins/revisions va ameliorer le probleme en desactivant la compression, mais parfois les fragments serialize cassent pour une histoire de saut de ligne, c'est pas robuste. A completer plus tard **Version cible mise à 3.2**
Poster
Owner

Version cible mise à 4.1

**Version cible mise à 4.1**

Mon expérience avec les révisions : J'ai une table spip_versions_fragments régulièrement plantée que je dois manuellement réparer sous phpMyadmin ! Je n'ai jamais vraiment compris d'où le pb venait. Je soupçonne les reboot réguliers de MySQL dû à des dépassements de capacité mémoire, peut-être lié aux backups automatique de l'hébergeur. J'ai ce problème depuis des années et ai remarqué une amélioration depuis quelques temps : les crash de la table sont beaucoup plus rares, et ça semble correlé aux reboot moins fréquents de MySQL. au doigt mouillé... 😅

C'est la seule table qui me pose problème, de temps en temps (SPIP 3.2 - activité éditoriale quotidienne, table spip_versions_fragments > 150 Mo).

Mon expérience avec les révisions : J'ai une table `spip_versions_fragments` régulièrement plantée que je dois manuellement réparer sous phpMyadmin ! Je n'ai jamais vraiment compris d'où le pb venait. Je soupçonne les reboot réguliers de MySQL dû à des dépassements de capacité mémoire, peut-être lié aux backups automatique de l'hébergeur. J'ai ce problème depuis des années et ai remarqué une amélioration depuis quelques temps : les crash de la table sont beaucoup plus rares, et ça semble correlé aux reboot moins fréquents de MySQL. au doigt mouillé... 😅 C'est la seule table qui me pose problème, de temps en temps (SPIP 3.2 - activité éditoriale quotidienne, table spip_versions_fragments > 150 Mo).
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.