Discussion :

[Fabien Celaia]

Mais à quoi sert ce "truc" ?

Petit exemple de corruption...

1) je crée une table
2) je supprime son ficher de format (.frm)

Contrôle avec mysqlcheck => ne détecte rien (puisqu'il ne semble traiter que les tables depuis leur .frm)
Tentative de créer une table du même nom => table already exists (puisque, physiquement, la table est toujours présente !)

En environnement innodb (innodb_file_per_table=1) et MyISAM (ce n'est donc pas que lié à de l'Innodb), je me retrouve parfois avec des tables présentes sur disque (fichiers de format, de données et d'index), mais que la base ne reconnais plus... et là, mysqldump les détecte comme corrompues...

Autre question : puisqu'il ne gère pas les table MEMORY, y a-t-il possibilité de lui dire de les éviter, ceci afin de ne pas avoir de faux positifs dans l'output ?

[SQLpro]

Mais à quoi sert ce "truc" ?....

Tu te pose trop de questions.... Les autres ne s'en posent pas autant et ça les empêche pas de travailler avec des bases corrompues, mais comme MySQL ne dit rien, ils ne le savant pas et ça passe très bien !!!!



A +

[Artemus24]

Salut fadace.

Pourquoi venir bidouiller dans le répertoire "/data", pour s'apercevoir qu'ensuite plus rien ne fonctionne correctement ?
Franchement, qu'elle est l'intérêt de supprimer le fichier ".frm" ?

Je sais très bien que les anciennes DS de chez Citroën pouvait rouler sur trois roues, voir l'image ci-après :



oui, sauf que c'était un argument commercial de Citroën.

Je ne crois pas que MySql puisse encore fonctionner normalement, si l'on supprimer un de ces fichiers.

Autre question : puisqu'il ne gère pas les table MEMORY,

Qui a dit que MySql ne sait pas gérer le "ENGINE=MEMORY" ???

@+

[Fabien Celaia]

Quand on fait de l'exploitation, gérer des scénari, c'est le b-a-ba.
En quelques mois d'administration mySQL, j'ai eu plus de corruptions qu'en années d'administration Postgresql, Oracle, Sybase et autres MSSQL... donc je trouve adéquat de tester quelques "pannes".... et la perte d'un fichier en est une...
Je préfère provoquer des corruptions et apprendre à les régler plutôt qu'attendre patiemment qu'elles se produisent en production.

Je ne crois pas que MySql puisse encore fonctionner normalement, si l'on supprimer un de ces fichiers.

Mais c'est bien ce que j'aimerai voir... et là, le check montre qu'il continue à fonctionner correctement bien que la base soit corrompue...

Qui a dit que MySql ne sait pas gérer le "ENGINE=MEMORY" ???

Je ne parle pas de mysql, mais de mysqlcheck

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
keelee.test
note     : The storage engine for the table doesn't support check

[Artemus24]

Salut Fadace.

En quelques mois d'administration mySQL, j'ai eu plus de corruptions qu'en années d'administration Postgresql, Oracle, Sybase et autres MSSQL...

J'utilise MySql depuis plusieurs années sans avoir rencontré de graves problèmes, genre base irrécupérable.
J'ai de temps temps un problème de corruption que je résous assez facilement en faisant régulièrement de la maintenance.
Cela arrive quand un traitement se termine mal. Faut faire avec !
J'ai déjà eu aussi des plantages, mais grâce à mes sauvegardes quotidiennes, j'ai pu réparer ces désagréments, sans perdre la totalité de la base.

S'il y a une instabilité sur vos bases MySql, c'est qu'il y a une instabilité dans l'usage que vous en faites.
Avant de dire que MySql est pire que les autres SGBD, il ne faudrait pas le solliciter autrement que pour ce qu'il est prévu.
Il est destiné pour de la petite volumétrie, autour de la gestion d'un site, pas pour faire de la sécurité ou des traitements de masse.

@+

[Fabien Celaia]

Hello Artemus24,

Merci de tes informations. C'est noté.

Je vais corriger notre charte SGBDR en conséquent... et le comparatif pour DVP...

Merci de ton aide
Fadace