OVH Community, votre nouvel espace communautaire.

Crash récurrent de bases SQLite sur hébergement mutu


janus57
23/03/2016, 07h19
Citation Envoyé par Nowwhat
TS3, par défaut, va utiliser un mini SQLite. Mais .... va voir le forum de support (il est énorme) de TS pour constater qu'il faut SURTOUT pas faire ça.
TS3 préconise un bon vieux MySQL (pardon : MariadDB maintenant).
J'ai un TS qui tourne comme ça depuis .... des années.
Bonjour,

j'ai un TS qui tourne dans sa config d'origine (SQLite) depuis un peu plus d'un an et j'ai jamais eu de problème.
Si il conseil vraiment tant que ça de passer à MySQL ou équivalent il ont cas changer la config par défaut, car perso de ce que j'ai vu SQLite peu gérer un TS3 de 512 Slots sans aucun problème et plus facilement que MySQL lors de MAJ BDD.

Cordialement, janus57

Nowwhat
22/03/2016, 23h25
Citation Envoyé par janus57
.... j'ai vu du SQLite c'était pour les logiciel TS3/Mumble, du SQLite ....
TS3, par défaut, va utiliser un mini SQLite. Mais .... va voir le forum de support (il est énorme) de TS pour constater qu'il faut SURTOUT pas faire ça.
TS3 préconise un bon vieux MySQL (pardon : MariadDB maintenant).
J'ai un TS qui tourne comme ça depuis .... des années.

janus57
22/03/2016, 23h09
Bonjour,

et encore si en local son serveur web crash au moment ou il fait une action sur sa base SQLite là aussi elle sera corrompu comme quand un serveur MySQL crash.

La différence c'est que MySQL à plusieurs palier de sécurité pour remettre le tout en marche (sans passer par la case backup).

Note : perso les seul fois ou j'ai vu du SQLite c'était pour les logiciel TS3/Mumble, du SQLite pour un site web c'est vraiment pas le top, encore moins sur des HDD "normaux" (MySQL fait beaucoup mieux à coté avec les même HDD).

Cordialement, janus57

Gaston_Phone
22/03/2016, 23h04
Merci Janus et Nowwhat pour vos explications très claires qui expliquent pourquoi cela peut fonctionner en local et pas chez OVH.

Nowwhat
22/03/2016, 22h56
SQLite : un compassant intégré dans PHP qui 'simule' une base des données.
Le tout est donc exécuté par le serveur web, les données sont présent sur l'espace hébergement, où sont également places les fichiers script PHP de votre site.
Le truc : le système de stockage de ce serveur web d'OVH est sévèrement optimalisé pour LIRE les données - vraiment moins pour y écrire - car un serveur web, il va "lire" 99,9 % du temps.
Or, opérer avec une une base des données et vous fait les deux .... (encore mieux : à la fois ...)

SQLite : ok mais SI vous pouvez utiliser votre base des données offert avec votre hébergement, utilise-le. Cette base a été optimalisé d'une façon quasi industrielle pour faire justement ce boulot.

SQLite : c'est bien si vous pouvez vraiment pas faire autrement. Ce qui n'est pas le cas ici ....

janus57
22/03/2016, 21h49
Bonjour,

chez OVH et les hébergeur qui utilisent des cluster je pense qu'il faut laisser tomber SQLite qui enregistre les données sur l’espace d'hébergement qui peu à tout moment être basculé d'un serveur à un autre de manière "soudaine" en cas de surcharge du cluster, donc forcément la BDD SQLite qui se balade à travers le réseau en cours d'utilisation va pas trop aimer.

Pourquoi pas utiliser MySQL (ou proposer le choix si ce n'est pas déjà fait) ?

Cordialement, janus57

Gaston_Phone
22/03/2016, 21h23
Désolé pour le 1er lien, je n'ai pas regardé les PSEUDOS des intervenants.

Je n'ai aucun à priori, mais il ne faut négliger aucune piste. L'Informatique est tellement complèxe.

b_b
22/03/2016, 21h15
Merci Gaston, mais au cas où tu ne l'aurais pas remarqué, c'est moi qui répondait à l'utilisateur en galère dans le premier lien que tu cites...

Pour le deuxième point, on a aucun problème avec des installations de SPIP+SQLite en local ou sur d'autres hébergeurs, et si ça venait de l'API SQL de SPIP on aurait déjà eu des retours à ce sujet (et corrigé le problème).

Gaston_Phone
22/03/2016, 20h43
A lire :

Si le 1er lien concerne aussi SQLite chez OVH, le 2ème lien indiquerait que le problème dans le code écrit pour accéder avec une base de type SQLite 3 :

Je te laisse continuer tes recherches avec l'aide de notre ami GOOGLE.

b_b
22/03/2016, 17h54
Salut, nous avons souvent des retours d'utilisateurs de SPIP dont la base SQLite est crashée, avec le code d'erreur suivant :

Code:
Erreur SQL HY000 / 11
database disk image is malformed
De mon côté, j'ai un petit site qui "tente" de fonctionner sur un mutu OVH en SQLite, et j'en suis au deuxième crash depuis le début de l'année. Du coup, à chaque fois je dois restaurer un backup de la base en tapant dans les snap ftp. Chose aisée pour quelqu'un qui connaît le problème, mais source de panique assurée pour un utilisateur lambda.

La question : faut-il qu'on annonce aux utilisateurs de SPIP qu'il est déconseillé/impossible d'utiliser SQLite chez OVH ? Ou peut-on espérer que cela s'améliore dans un futur proche ?

++
b_b