Aide - Recherche - Membres - Calendrier
Version complète : [resolu] OSC compatible MYSQL version 4 ?
Forum osCommerce-fr > Vie du groupe > Archives
mayu
Salut à tous,
Je voudrais savoir si l'OSC est compatible avec la version 4 de mysql.

Y a t-il des modif à faire pour rendre compatible ?

Merci
frenchgre
a priori il semble bien que oui ! laugh.gif

http://www.oscommerce.com/about/features
xaglo
c'est pas gentil frenchgre de lui donnner un lien sur les features de la 2.1 laugh.gif

Donc mayu, oui pas de pb OsC/php4 par contre de ce que j'ai pu constater ou lire, tu peux avoir les soucis propre à php4 ("header allready send" pour les lignes vides php4.0... ou des choses comme ça).
Il semble aussi qu'il y ai quelques soucis php 4.3/easyphp
Donc si c'est pour un php installé chez ton hébergeur, pas de problème, la version la plus récente sera la mieux.
Si c'est pour du local sous easyphp, php4.2 semble le plus approprié.
Si tu as la chance de faire la nique à Billy... pas de problème pour php4.3 laugh.gif
pericles
En effet, xaglo, pour PHP 4.
Mais, concernant MySQL 4, a priori il ne devrait pas y avoir de problemes (compatibilite conserve).
xaglo
QUOTE (pericles)
En effet, xaglo, pour PHP 4.

ouf!!! j'ai pas trop dit de bêtises laugh.gif
ça me fait toujours flipper quand pericles répond deriere moi wink.gif
pericles
Y a pas de raison. Pour PHP 4, c'est tout vrai. Le mieux est d'avoir un serveur en PHP 4.1+ (4.0.6 a eviter) wink.gif
mayu
Bah apparement je pense que pas que cela soit dû à la version de mysql mais cependant je n'ai pas trouvé la solution de ma fameuse problème de la dernière fois que j'ai retrouvée aujourd"hui aussi sad.gif

cry.gif trop fatigué !

En fait ce problème de lecture est revenue
QUOTE
Can't open file: 'whos_online.MYI'. (errno: 145)


C'est quoi ce fichier d'extension MYI ?
Où se trouve-t-il ?

A un jour d'intervalle, ce même problème arrive ! A votre avis, c'est quoi l'origine du problème ?
D'ailleurs la table whos_online est à supprimer et remettre une nouvelle !

C'est à chaque fois des décisions catégoriques à prendre !

Sur la page default.php, j'ai lors de ce problème ce message :
QUOTE
1016 - Can't open file: 'whos_online.MYI'. (errno: 145)

delete from whos_online where time_last_click < '1056735494'

[TEP STOP]

vanadium2
Je confirme que ça marche avec la dernière version MySql 4.0.13 !
vanadium2
Quand au problème, supprimes la table via phpMyAdmin et réinstalle la.

Voici la structure:
CODE
CREATE TABLE `whos_online` (

 `customer_id` int(11) default NULL,

 `full_name` varchar(64) NOT NULL default '',

 `session_id` varchar(128) NOT NULL default '',

 `ip_address` varchar(15) NOT NULL default '',

 `time_entry` varchar(14) NOT NULL default '',

 `time_last_click` varchar(14) NOT NULL default '',

 `last_page_url` varchar(64) NOT NULL default ''

) TYPE=MyISAM;
mayu
oui en fait j'ai du remettre la structure effectivement.

Sinon le problème est propre à mon hébergeur (Je ne cite pas ici le nom de l'hébergeur) et d'ailleurs ca dure depuis plus d'un an apparement, j'ai vu que des personnes qui utilisaient SPIP avaient le même problème aussi chez eux !
mayu
QUOTE
Warning: open_basedir restriction in effect. File is in wrong directory in /web/admin/whos_online.php on line 106

Warning: file(\"/tmp/sess_1ba2e5b53f332f02bd476195524f4fe6\") - Operation not permitted in /web/admin/whos_online.php on line 106

Warning: Bad arguments to implode() in /web/admin/whos_online.php on line 107


Je comprends pas ces warning. Le 2eme a l'air d'être un problème de session je crois non ? J'ai désactivé l'enregistrement dans la base pour les sessions.
Ceci pourrait mes problèmes précédements ? Cad le problème de la base whos_online qui se détériore toute seule !
vanadium2
Une directive de php permet de limiter les inclusions et accès, aux fichiers et dossiers (et sous-dossiers) courants, en général à partir de la racine publiable de ton site.
Si ton dossier web a comme path /var/www/htdocs/tonsite/html (=open_basedir), et bien tu ne pourras pas inclure ou accéder à un fichier en dehors de se chemin (par sécurité).

Dans ce cas tes sessions ne pouront être stoquées à la racine du serveur dans /tmp, il te faudra créer un dossier tmp (ou autre) ex: /var/www/htdocs/tonsite/html/tmp (ATTENTION de préférable en dehors de la racine publiable) et de modifier ensuite, dans l'admin (Configuration>Sessions) le "Session Directory".

Une autre méthode consiste à enregistrer les sessions dans la base, includes/configure.php:
define('STORE_SESSIONS', 'mysql');
mayu
enregistrement dans la base mysql, c'est meme pas la peine, j'ai essayé et de tres fort ralentissements !
Sinon je voudrais savoir où tu changes pour le repertoire /tmp ?
Dans l'interface admin, j'ai pas vu ca à part ceci :

QUOTE
fichier de logging : /var/log/www/tep/page_parse_time.log


dans la catégorie "configuration" et y aussi
QUOTE
cache : /tmp/

mais ce cache est désactivé.

et dans les fichiers de configure.php, j'ai vu rien de ce genre
vanadium2
Demande à ton hébergeur, il a du te désigner un dossier pour tes sessions.

Sinon dans application_top.php environ à la ligne 142 tu as :
define('PHP_SESSION_SAVE_PATH', '/tmp');
mais il me semble que la fonction ne sera utilisée qu'en cas ou tu es en php3.

Bref regarde ton phpinfo(), mais si tes accès à la base sont trop lents, et que tu n'as pas activé la persistence des connections (mysql):
define('USE_PCONNECT', 'true');
et que tu n'as pas bidouillé ton osC, prend contact à ce sujet, avec ton hébergeur, et après tu aviseras.
mayu
Salut à tous,
Là je ne sais plus quoi faire ! cry.gif

J'ai toujours ce problème :
QUOTE
1016 - Can't open file: 'whos_online.MYI'. (errno: 145)

delete from whos_online where time_last_click < '1057393235'

[TEP STOP]


Ca me dépasse ca !

J'ai cherché des docs pour connaître l'origine du problème et là j'ai eu ce lien :
http://www.mysql.com/doc/fr/Crashing.html

Très intéressant et la partie intéressante est :

QUOTE

_Quelqu'un ou quelque chose a coupé mysqld ou la machine au milieu d'une mise à jour.  

_Vous avez trouvé un bogue dans mysqld qui le termine au milieu d'une mise à jour.  

_Quelqu'un manipule les fichiers de données ou d'index en dehors de mysqld sans verrouiller proprement les tables.  

_Si vous faites tourner plusieurs serveurs mysqld avec les mêmes données sur un système qui ne gère pas bien les vérrous de fichiers (normalement gérés par le démon lockd) ou que vous le faites avec --skip-external-locking  

_Vous avez un fichier de données ou d'index corrompu qui contient des données faussées ce qui amène mysqld à confusion.  
Vous avez trouvé un bogue dans le système de stockage des données. _

_Cela parait impossible, mais sait-on jamais ? Dans ce cas, essayez de changer le type de fichier pour qu'il soit pris en charge par un autre gestionnaire de bases de données en utilisant ALTER TABLE sur une copie réparée de la table !  


Et ce qui me paraît encore plus intéressant est :

QUOTE
Vous avez un fichier de données ou d'index corrompu qui contient des données faussées ce qui amène mysqld à confusion.


Comment sous OSC, comment on peut aboutir à un fichier de données ou d'index corrompu ?

Je voudrais aussi vous faire remarquer que seul la table "whos_online" est concerné par ce problème.
C'est tout de même curieux non ?
Gnidhal
bin vu que ça semble venir de ta base mysql, je te suggère :
1 - une sauvegarde de la base complète et vérification des tables (vérif à la main sur la sauvegarde)
2 - un effacement de la base et suppression
3 - une nouvelle création de base et réinstallation de la sauvegarde.

Si tu ne peux agir sur la base (chez les hébergeurs, il est rare de pouvoir supprimer ou modifier la base elle-même)
tu fais pareil en vidant complètement la base de ses tables et en réinstallant tout.
C'est plus fiable que que faire un restore par dessus.

Après faut voir... c'est le fichier d'index mysql qui semble corrompu. Donc cette opération devrait obliger le serveur à recréer son fichier d'index.
Surtout si tu laisses un temps de latence entre l'effacement et la restauration des tables.
mayu
Salut,
Une réinstallation totale, je l'ai faite la derniere fois que j'ai eu ce problème.
Et pourtant, cela n'avait pas changé grand chose !

Tu crois que cela vient de ma config ou de l'hébergeur ?
Gnidhal
Je crois ce que je vois laugh.gif
le problème est un problème de serveur mysql.
PHP ou a fortiori oscommerce ne semblent pas en cause !

Donc c'est toi qui déduis ce que tu veux wink.gif
mais je penche pour un pb sur la base de donnée.Or, le fait de réinstaller une table n'est pas suffisant, car le pb peut persister entre un effacement et une réinstall. Donc effacement, changement de nom de la base si tu peux et réinstall...
si pb tu vois avec ton hébergeur.
Parfois les caches sont si malins qu'ils te récupèrent même les problèmes !
vanadium2
Recommence une installation de test, nouveau dossier, nouvelle base !

Des problèmes materiels ou logiciels seront envisageable ,si les même problèmes se reproduisent.
pitstop
Je me permet de répondre et d'apporter ma solution.
Travaillant avec plusieurs hébergeurs, j'ai noté ce problème récurrent chez Amen et Alpes Hosting.

CODE
$current_time = time();

$xx_mins_ago = ($current_time - 300);

// remove entries that have expired

tep_db_query("delete from " . TABLE_WHOS_ONLINE . " where time_last_click < '" . $xx_mins_ago . "'");


En fait, c'est assez simple...
Les hébergeurs ont une certaine config de serveur MySql qui ferme les tables ou il y a ce que ils appellent des "connexions persistantes". Au bout d'un certains nombre de secondes, la machine rend la table inutilisable pour ne pas saturer.

Si un visiteur ou un robot vient sur le site et reste 20 minutes sur la même page sans rien faire, il occupe la table Who's Online ce qui provoque la fermeture par le serveur et provoque l'impossibilité d'accèder au site.

En "kilant" les requêtes par le logiciel au bout de 300 secondes, ça évite de dépasser les délais de la machine et de se retrouver planter.

J'ajoute que ce problème existe aussi avec la table Sessions lorsqu'on l'utilise et que l'on ne met pas les sessions dans un fichier!

Je crois que ce type de problème arrive plus fréquement aux sites ayant un nombre important de visiteurs, les chances de bloquer le bordel étant plus grande.
Ma boutique principale reçoit 5 à 600 visites par jour et j'était obliger de tout débloquer une à deux fois par jour!
Philippe
Perso en version 4 j'ai eu le même problème et sur la même table.

Affaire à suivre !

A+

Philippe
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'informations, la mise en page et les images, veuillez cliquer ici.
Invision Power Board © 2001-2014 Invision Power Services, Inc.