Maximus, le CMS Français simple, rapide et sécurisé

Bon, je viens de m'apercevoir que dans l'installeur depuis la version 2008 il manque le contenu d'une table importante, puisque l'on tape tout le temps dedans et quelle est vide alors qu'elle ne devrait pas l'être

En fait ce n'est pas moi qui l'ai trouvé mais c'est Alex d' Hebeh.com qui vient de m'appeler pour me signaler le problème qui, sur des sites à fortes fréquentation, générait une latence importante sur le serveur mysql , pompait un max de ressources, bref foutait en l'air la stabilité du serveur mysql ( et rendait le site très lent ).

J'ai donc regardé dans un premier temps avec lui puisqu'il avait plusieurs problèmes, un avec plusieurs smf, un autre avec plusieurs phpbb3 et le dernier avec des maximus, pour les deux premiers il s'est débrouillé puisque c'était des index manquants pour les deux forums cités qui génèrent un ralentissement notable sur des gros forums, mais pour le troisième comme il manquait une table ça lui était impossible de résoudre le binz

bon donc pour résumer, TOUS les utilisateurs depuis la version 2008 doivent être concernés par ceci, mais je demande à tout le monde de contrôler ceci dans tous les cas

de mon coté je me suis engagé à livrer le correctif, si vous ne l'appliquez pas et que vous vous retrouvez avec un compte fermé, ne venez pas vous plaindre ( j'aurai fait mon job )


Donc pour résumer ...

Premier contrôle important

Vérifier si la table max_counter existe
Si elle existe, est ce qu'elle contient des informations ?
Si oui tout va bien, si non tout va mal

Si non, ouvrez phpmyadmin puis supprimez la table existante ( vide ), et restaurez celle ci en faisant très attention à votre préfixe !

Code: Tout sélectionner

CREATE TABLE IF NOT EXISTS `max_counter` (
  `type` varchar(80) NOT NULL default '',
  `var` varchar(80) NOT NULL default '',
  `count` int(10) unsigned NOT NULL default '0',
  KEY `type` (`type`),
  KEY `var` (`var`)
) ;


INSERT INTO `max_counter` (`type`, `var`, `count`) VALUES
('total', 'hits', 0),
('browser', 'WebTV', 0),
('browser', 'Lynx', 0),
('browser', 'MSIE', 0),
('browser', 'Opera', 0),
('browser', 'Konqueror', 0),
('browser', 'Netscape', 0),
('browser', 'FireFox', 0),
('browser', 'Bot', 0),
('browser', 'Other', 0),
('os', 'Windows', 0),
('os', 'Linux', 0),
('os', 'Mac', 0),
('os', 'FreeBSD', 0),
('os', 'SunOS', 0),
('os', 'IRIX', 0),
('os', 'BeOS', 0),
('os', 'OS/2', 0),
('os', 'AIX', 0),
('os', 'Other', 0);


Seconde étape pour tout le monde

là c'est très simple et ça concerne tout le monde, puisque si c'est déjà fait c'est pas grave, si ça n'est pas fait, ça le sera

ouvrez phpmyadmin, puis onglet SQL, copiez / collez le code suivant puis validez en faisant très attention à votre préfixe !

Code: Tout sélectionner

ALTER TABLE `max_session` ADD INDEX ( `uname` );
OPTIMIZE TABLE `max_session`;

ALTER TABLE `max_stats_date` ADD INDEX ( `year` );
ALTER TABLE `max_stats_date` ADD INDEX ( `month` );
ALTER TABLE `max_stats_date` ADD INDEX ( `date` );
OPTIMIZE TABLE `max_stats_date`;

ALTER TABLE `max_stats_hour` ADD INDEX ( `year` );
ALTER TABLE `max_stats_hour` ADD INDEX ( `month` );
ALTER TABLE `max_stats_hour` ADD INDEX ( `date` );
ALTER TABLE `max_stats_hour` ADD INDEX ( `hour` );
OPTIMIZE TABLE `max_stats_hour`;

ALTER TABLE `max_stats_month` ADD INDEX ( `year` );
ALTER TABLE `max_stats_month` ADD INDEX ( `month` );
OPTIMIZE TABLE `max_stats_month`;

ALTER TABLE `max_stats_year` ADD INDEX ( `year` );
OPTIMIZE TABLE `max_stats_year`;

Les packs maximus 2010 viennent d'être mis à jour en prenant compte de ces deux points

Et bien sur faite des sauvegarde avant toutes manipulations et après

Salut,

Pour moi, les tables _stats n'existent pas...

El_Titof a écrit:Et bien sur faite des sauvegarde avant toutes manipulations et après

oula oui bien vu !!!

Toumilovitch a écrit:Salut,

Pour moi, les tables _stats n'existent pas...

moi non plus

dans ce cas, tu peux virer aussi la table _counter

Pour qu'un plus grand nombre le fasse je pense que tu devrais mettre un systeme qui test si la manip est fête et sinon la faire lors du prochain update...

Je me disais aussi il faudrait dans les fichier update de base de donnée un systeme pour être sur d'avoir fait tout les updates précédent du genre dans la base de donnée il y a un champ avec un numéro de version et celui ci croit à chaque update de base et si tu n'a pas fait la version précédente il y a un avertissement!!!

oui el_titof tu as raison en plus

J'ai vu que tu mets à jour la version lors de l'update mais peut être faudrait avoir des chiffres après la virgule 2010.1, 2010.2...

ok, pour la prochaine reloaded je tâche de rajouter un champs dédié

Merci, avec visibilité uniquement en Admin et avec test de la version précédente si update à jour

Moi tout est bon d'avance, sauf que j'ai deux index, un avec les year hour ok...un double avec la même chose et _2 derrière (year_2, hour_2 etc...)

"Les index suivants semblent équivalents, vous devriez en éliminer un"

non?

donne moi la structure exacte de la table

--
-- Structure de la table `nuke_stats_hour`
--

CREATE TABLE IF NOT EXISTS `nuke_stats_hour` (
`year` smallint(6) NOT NULL default '0',
`month` tinyint(4) NOT NULL default '0',
`date` tinyint(4) NOT NULL default '0',
`hour` tinyint(4) NOT NULL default '0',
`hits` int(11) NOT NULL default '0',
KEY `year` (`year`),
KEY `month` (`month`),
KEY `date` (`date`),
KEY `hour` (`hour`),
KEY `year_2` (`year`),
KEY `month_2` (`month`),
KEY `date_2` (`date`),
KEY `hour_2` (`hour`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;



Le site est de bs à 2010.

ok

vire les index suivants via phpmyadmin

Code: Tout sélectionner

KEY `year_2` (`year`),
KEY `month_2` (`month`),
KEY `date_2` (`date`),
KEY `hour_2` (`hour`)

supprimé.

J'avais pas vu mais même souci sur max_session. J'ai supprimé uname_2...