Je travaille sur des tables MySQL de plusieurs Go où il leur arrive souvent d'avoir des pbs (index corrompues,etc.). Une solution éventuelle serait de séparer les tables en plusieurs petites avec une séparation par contrainte de temps (par jour, semaine, mois, etc.) ou de taille (100Mo,500Mo...). Précision : ce n'est pas un entrepôt de données mais des tables avec l'enregistrements de plusieurs lignes/secondes donc cette séparation se ferait en temps réelle.
D'où ma question : est-ce possible, automatisable ? Si oui comment ?  
Merci pour toute précision et expérience personnelle !

ben ça dépend quelles données tu exploite dans ces tables, si ce ne sont que les plus récentes, tu peux déplacer les anciennes données.
 
C'est automatisable en utilisant cron (ou le planificateur windows).

Le pb c'est que c'est des données qui sont éventuellement exploitables donc pas possible de faire un backup et de les déplacer pour plus s'en servir. Par contre comment créer des "anciennes données" comme tu dis ? (précision, quoique je pense que c pareil sous Windows, mais je suis sous Linux). Je sais que le format de tables InnoDB permet de créer plusieurs fichiers automatiquement lorsqu'il atteint la limite du système de fichier. J'aimerai donc faire un truc dans le genre mais en choississant mes propres tailles de fichiers... Possible ?

je trouve ca anormale que tu es des index corrompus comment tu te demerdes ?

Ben à vrai dire si j'arrivais à le reproduire quand je veux ça m'arrangerait ! J'ai assez régulièrmeent des erreurs 'Duplicate index entry' et des 'Can't open file: xxxx.MYD (errno: 145)' (l'erreur 145 correspondant à 'Table was marked as crashed and should be repaired'.
Je tourne pour l'instant sur un MySQL 3.23.40 et j'envisage de voir pour passer sur une 3.23.51 mais bon je suis pas convaincu que ça puisse résoudre mes problèmes...

ca m'est jamais arrivé sur HFR, t'as pas un problème de dur ou un pb materiel ?

 
Euh, ca m'est déjà arrivé aussi, et pas sur une grande table et la machine était pas naze... Je faisais juste bcp d'insert en un très court laps de temps, et il aimait pas du tout.
 
Essaie d'upgrader quand même  

Zion a écrit a écrit :     Euh, ca m'est déjà arrivé aussi, et pas sur une grande table et la machine était pas naze... Je faisais juste bcp d'insert en un très court laps de temps, et il aimait pas du tout.   Essaie d'upgrader quand même

heu on peut pas dire sur HFR je fasse pas bcp d'insert en un coup surtout quand tu regardes le moteur de recherche

Moi aussi au niveau de l'utilisation, c'est pas mal d'insert et de select en même temps mais bon vu les différentes applications (web ou non) qui utilisent MySQL, je ne pense pas que mon appli le fasse fonctionner de manière particulièrement critique... Par contre, le fait que ce ne soit pas un serveur dédié mais une machine qui fasse plein d'autres choses dont loguer en base y joue surement. Là, on m'a demandé de reproduire en test les plantages... Alors bon à mon avis si il y avait un "truc" pour faire planter MySQL ça se saurait !
zion: ça s'est résolu comment ton problème ? D'autres expériences, problèmes identiques ?

 
Ca date d'il y a quasi 2 ans, et ca s'est résolu par un bout de ficelle en calculant l'ID moi même (Je sais, c'est mal   )
 
Mais joce, c'était pas un script c'était un programme qui en rajoutait quelques dizaines de milliers d'affilées, et MySQL aimait vraiment pas

Ct un champ auto_increment qui posait problème ? Ca peut correspondre à mes erreurs. De mon côté c également un programme en C qui balance des logs donc beaucoup d'un coup également. J'ai peur que de calculer l'id manuellement ralentisse pas mal le système.

 
Oui c'était un auto_increment, et c'est clair que ca ralenti si c'est toi qui le calcule, mais bon... essaie toujours d'upgrader, j'ai plus jamais eu un truc équivalent sur les dernières versions  

Je bosse actuellement sur MySQL 3.23.40 (qui a un an) donc bon ça devait pas être la même que pour toi. Je vais essayer de passer sur la 3.23.51 (ou 4 ??) mais j'aimerai bien arriver à faire un jeu de test qui arrive à me la faire planter pour voir si ça change quelque chose. Mais bon c pas gagné !

Passe à la 4.0.2 !

joce a écrit a écrit : Passe à la 4.0.2 !

elle sort quand la finale ?

attends déjà la beta
mais ca fait longtemps que j'ai pas vu de bugs pour la 4.0.2

ah vi, c'est tjs la alpha

c'est peut-être de l'alpha mais c'est stable et ca rocks (le forum HFR tourne avec la 4.0.2)

Et elle est vraiment mieux ?
niveau rapidité ?
 
mais bon, je pense quand meme attendre la version finale qu'on va installer sur le serveur.

oh oui elle est vraiment mieux
Et elle rocks niveau rapidité.
Enfin chez MySQL de l'alpha ca correspond à du final chez Crosoft

mais, tu as eu des bugs depuis que tu l'as installé ?
t'as du faire des reports de bugs, nan ?  
 
Ou elle est vraiment nickel ?
 
je vais quand meme l'installer en local

Je vais également faire des tests mais bon une alpha en production (même si elle est stable) ça passerait moyen... Je pense qu'au niveau rapidité c'est surtout la mise en cache qui optimise les select non ? D'ailleurs vu que ça devient le topic tests MySQL, est-ce que quelqu'un a testé les tables InnoDB ? Fiabilité, performances ? Sur le papier ça semble vraiment bien en tout cas...

RELAX Sky a écrit a écrit : je vais mettre la 4.0 rien ke pour les subselect

y a pas de subselect dans la 4.0

Limit a écrit a écrit : mais, tu as eu des bugs depuis que tu l'as installé ? t'as du faire des reports de bugs, nan ?     Ou elle est vraiment nickel ?   je vais quand meme l'installer en local

je suis responsable de 1/3 des bugs reports sur MySQL 4.0.2

4.0.3 est une beta.
le query cache optimise bcp oui.
InnoDB c'est stable (c'est dans la branche 3.23.xx également)

heu le forum est très stable, jamais vu de plantage de mysql

cte troll  

heu nan

 
 
 
c'est l'association "forum hfr" et "stable" qui m'a fait sourire.
me fait pas ressortir mes screenshots stp
 
maintenant que ce soit du à mysql ou pas, prttt....
 
 

--greg-- a écrit a écrit :       c'est l'association "forum hfr" et "stable" qui m'a fait sourire. me fait pas ressortir mes screenshots stp   maintenant que ce soit du à mysql ou pas, prttt....

faut pas confondre quand je tripotte le code et quand y a une vrai merde.
Y a jamais eu aucune merde liée à MySQL en tout cas.

jdis pas
mais quand tu "tripottes" le code, ça rend le forum instable on est bien d'accords
tiens tant que je t'ai sous la main: j'ai jamais compris pourquoi tu faisais pas ces tripotages sur une machine de test? à la limite meme sur la meme machine, mais sur une copie du script??

 
Parce que ca donne tout son charme à HFR... Les gens sont contents sur BlaBla, ca donne de l'animation quand joce code  

Zion a écrit a écrit :     Parce que ca donne tout son charme à HFR... Les gens sont contents sur BlaBla, ca donne de l'animation quand joce code

 
au fait il a changé le smiley lol ou j'ai revé?

t'as révé