fichiers mysql

Le 09 Oct 2012 12:56:35 GMT, Kevin Denis <kevin@nowhere.invalid>
écrivait dans fr.comp.applications.sgbd:

Bonjour,

j'ai quelques questions pour mySQL v5:

Lors de la création d'une table "table" dans une base "base", on
constate la création de 3 fichiers:
base/table.frm
base/table.MYD
base/table.MYI

savez vous si ces fichiers sont toujours créés? (pas de dépendance au
format utilisé comme myISAM ou autre format de stockage).

Ce sont des fichiers pour le format myISAM. Avec un autre format,
on peut avoir d'autres fichiers. Cela m'est déjà arrivé (j'avais
coché un autre format et je ne trouvais pas ces fichiers !).

savez vous si en ayant uniquement ces trois fichiers on peut connaître
le format de stockage et/ou version de mySQL utilisée pour leur création?

est-ce que ces fichiers sont déplaçables d'une bdd mySQL à une autre
facilement?

J'ai déjà essayé, passage de Windows à Linux, et cela a fonctionné.
Mais sans garantie que ce soit toujours possible !


Denis

Le 09-10-2012, Denis Beauregard a écrit :

j'ai quelques questions pour mySQL v5:

Lors de la création d'une table "table" dans une base "base", on
constate la création de 3 fichiers:
base/table.frm
base/table.MYD
base/table.MYI

savez vous si ces fichiers sont toujours créés? (pas de dépendance au
format utilisé comme myISAM ou autre format de stockage).

Ce sont des fichiers pour le format myISAM. Avec un autre format,
on peut avoir d'autres fichiers. Cela m'est déjà arrivé (j'avais
coché un autre format et je ne trouvais pas ces fichiers !).

Ok, savez vous s'il existe un lien qui indique la correspondance
entre les fichiers créés et le format?

savez vous si en ayant uniquement ces trois fichiers on peut connaître
le format de stockage et/ou version de mySQL utilisée pour leur création?

est-ce que ces fichiers sont déplaçables d'une bdd mySQL à une autre
facilement?

J'ai déjà essayé, passage de Windows à Linux, et cela a fonctionné.
Mais sans garantie que ce soit toujours possible !

yep, mais sans autre manip? C'est à dire que si je copie le répertoire
base/* d'une bdd mysql vers un autre hôte, la base apparaitra automagiquement
en faisant un show databases; ?
--
Kevin

Le 09 Oct 2012 13:48:07 GMT, Kevin Denis <kevin@nowhere.invalid>
écrivait dans fr.comp.applications.sgbd:

Le 09-10-2012, Denis Beauregard a écrit :

j'ai quelques questions pour mySQL v5:

Lors de la création d'une table "table" dans une base "base", on
constate la création de 3 fichiers:
base/table.frm
base/table.MYD
base/table.MYI

savez vous si ces fichiers sont toujours créés? (pas de dépendance au
format utilisé comme myISAM ou autre format de stockage).

Ce sont des fichiers pour le format myISAM. Avec un autre format,
on peut avoir d'autres fichiers. Cela m'est déjà arrivé (j'avais
coché un autre format et je ne trouvais pas ces fichiers !).

Ok, savez vous s'il existe un lien qui indique la correspondance
entre les fichiers créés et le format?

Aucune idée et bonne recherche...

savez vous si en ayant uniquement ces trois fichiers on peut connaître
le format de stockage et/ou version de mySQL utilisée pour leur création?

est-ce que ces fichiers sont déplaçables d'une bdd mySQL à une autre
facilement?

J'ai déjà essayé, passage de Windows à Linux, et cela a fonctionné.
Mais sans garantie que ce soit toujours possible !

yep, mais sans autre manip? C'est à dire que si je copie le répertoire
base/* d'une bdd mysql vers un autre hôte, la base apparaitra automagiquement
en faisant un show databases; ?

Il faut sans doute relancer l'application SQL.


Denis

dans (in) fr.comp.applications.sgbd, Kevin Denis <kevin@nowhere.invalid>
ecrivait (wrote) :

Bonjour Kevin,

yep, mais sans autre manip? C'est à dire que si je copie le répertoire
base/* d'une bdd mysql vers un autre hôte, la base apparaitra automagiquement
en faisant un show databases; ?

Ça ne me semble pas très casher, voire un peu (trop) magique comme façon
de procéder :)

La manipulation que j'utilise pour déplacer une base d'un serveur à un
autre est la suivante :

1. sauvegarde de l'ancienne base de données en local (via phpMyAdmin ou
directement sur le serveur en ligne de commande si tu as un accès
SSH -- bien sur, si la base est en local sur ta machine, ça
simplifie).

2. Création de la base de données vide sur le nouveau serveur (on peut
lui donner le même nom), en prenant soin de définir le même jeu de
caractères et le même moteur de recherche (MyISAM ou InnoDB), le même
identifiant et le même mot de passe que l'ancienne base [*]. Là
aussi, phpMyAdmin ou ligne de commande.

3. Importation du contenu de l'ancienne dans la nouvelle. phpMyAdmin ou
ligne de commande, encore et toujours.

J'utilise cette procédure fréquemment, et comme disait le fou tombant du
haut d'un gratte-cile en passant devant le 22ème étage « pour le moment
tout va bien ».

Murphy n'étant jamais loin, il faut se méfier quand même d'un certain
nombre de choses, par exemple des éventuelles différences de versions
entre l'ancien et le nouveau moteur MySQL.

S'il y a généralement compatibilité descendante (si le nouveau est plus
récent que l'ancien, a priori pas de problème, encore que...) ;
l'inverse est souvent facteur de désagréments et oblige à éditer le dump
(la sauvegarde) à la main, ce qui implique de savoir ce qu'on fait et
d'utiliser un éditeur de texte acceptant le jeu de caractères utilisé
pour renseigner le contenu des champs, et ne mettant pas les retours à
la ligne en charpie par exemple.

En d'autres termes, si on est sous Ms-Windows, le bloc-note est à
proscrire absolument, car c'est le meilleur moyen de rendre le fichier
inutilisable en un temps record. On lui préfèrera par exemple Notepad++,
que j'utilise avec bonheur.

Bien entendu, si la base données comprend quelques dizaines de milliers
d'enregistrements, ce qui arrive plus souvent qu'on ne l'imagine,
forcément, ça complique.

On travaillera toujours sur une copie de la sauvegarde, histoire de
pouvoir se donner un droit à l'erreur et de conserver l'original. Mais
je ne t'apprendrai rien en disant que quelles que soient les
manipulations réalisées, il faut toujours assurer ses arrières, n'est-ce
pas ?

Toutes ces considérations peuvent se résumer à pas grand-chose si tout
se passe bien, mais d'une part il est bien connu que tout se passe
rarement bien du premier coup ; d'autre part les éléments ci-dessus
peuvent aider à flairer les pièges.

Il ne te reste plus qu'à nous tenir au courant des tes (més)aventures :)

[*] Nom de la base, identifiant et mot de passe peuvent différer entre
l'ancienne et la nouvelle base, mais dans ce cas, il faudra bien
vérifier ces valeurs dans les scripts de connexion à la base.
Vérifications nécessaires de toute façon, puisqu'il faudra le cas
échéant indiquer l'emplacement du nouveau serveur, car il existe
d'autres possibilités que 127.0.0.1 ou localhost, si si.

--
Eric

Eric Demeester <eric+usenet@galacsys.net> écrivait :

Bonjour Kevin,

> yep, mais sans autre manip? C'est à dire que si je copie le répertoire
> base/* d'une bdd mysql vers un autre hôte, la base apparaitra automagiquement
> en faisant un show databases; ?

Ça ne me semble pas très casher, voire un peu (trop) magique comme façon
de procéder :)

Procédé de la dernière chance pour ceux qui ont été obligés de
réinstaller un serveur MySQL et qui n'avaient pas suivis les trois
règles de l'informatique. Jusqu'à présent, ça a fonctionné pour ceux qui
ont posés cette question sur le forum Wampserver.

Murphy n'étant jamais loin, il faut se méfier quand même d'un certain
nombre de choses, par exemple des éventuelles différences de versions
entre l'ancien et le nouveau moteur MySQL.

C'est pourquoi il faut impérativement effectuer "mysql_upgrade.exe" non
seulement en cas d'évolution de version de MySQL, mais également dans le
cas, cité ici, de transfert de dossier contenant les bases, AVANT de
vouloir travailler sur lesdites bases, même avec PhpMyAdmin et, bien
sûr, on travaille sur une copie des dossiers, pas sur les originaux.[1]

En d'autres termes, si on est sous Ms-Windows, le bloc-note est à
proscrire absolument, car c'est le meilleur moyen de rendre le fichier
inutilisable en un temps record. On lui préfèrera par exemple Notepad++,
que j'utilise avec bonheur.

D'autant plus que le bloc-note a une fâcheuse tendance à sauvegarder
subrepticement en utf-8 AVEC BOM sans prévenir.

[1] mysql_upgrade.exe - Pour Windows.

- 1 - Dans le dossier contenant vos bases de données, avez-vous un
fichier mysql_upgrade_info ?
Nota : Le dossier contenant vos bases de données correspond au contenu
de "datadir=...." du fichier "my.ini" de la version de MySQL utilisée
- 2 - Contient-il "5.x.y" ? (Numéro de la version MySQL utilisée)

Si vous répondez NON à 1 ou NON à 2, vous avez de grands risques de voir
survenir l'erreur : "Table 'mysql.servers' doesn't exist" et,
éventuellement d'autres erreurs car il n'y a pas eu de vérification de
la concordances de vos bases de données avec la nouvelle version de
MySQL.

mysql_upgrade.exe DOIT être exécuté après chaque mise à jour ou
évolution de version de MySQL.

--- Effectuer mysql_upgrade.exe ---
Pour les utilisateurs de Windows, non aficionado de la ligne de
commande, voici la procédure à effectuer.
Sauvegarder les bases de données existantes (mieux vaut prévenir que
guérir !).

Tout d'abord, il faut lancer le serveur MySql pour que MySQL soit actif.

Ensuite, lancer une fenêtre de commande par démarrer, exécuter et taper
%SystemRoot%system32cmd.exe

Se placer dans le dossier "bin" de la version de mysql utilisée.

Arrivé la il faut savoir si vous avez ou non mis un mot de passe à
root@localhost

si mot de passe, taper
mysql_upgrade.exe --user=root --host=localhost --password=mot_de_passe

si pas de mot de passe, taper
mysql_upgrade.exe --user=root --host=localhost --password
et attendre la fin de la procédure qui doit indiquer OK pour chacune des
tables.
--
Le logiciel de courrier d'Opera n'a rien de révolutionnaire
Forté Agent en faisait déjà autant, et même beaucoup plus, depuis trois lustres
Tout comme The Bat depuis belle lurette !

dans (in) fr.comp.applications.sgbd, Otomatic <otomatic@oto.invalid>
ecrivait (wrote) :

[bloc-note de Windows]

D'autant plus que le bloc-note a une fâcheuse tendance à sauvegarder
subrepticement en utf-8 AVEC BOM sans prévenir.

Et l'UTF-8 avec BOM est, dans ce cas comme dans bien d'autres, une
aberration. Ceux qui développent des sites web à l'ancienne (comprendre
à la main en écrivant des lignes de code dans des éditeurs de texte) et
se sont gauffrés à cause de ça comprendront.

J'en suis un exemple vivant, et je n'ai dû mon salut, après avoir erré
comme une âme en peine sur le ouaibe, qu'à la réponse qui me fut faite
sur fr.comp.infosystemes.www.auteurs. Comme quoi...

Sinon, je vois que c'est le retour des vieux cons sur Usenet, peut-être
que ça aidera à faire comprendre aux gens que c'est plus efficace de
poser une question ici que de se tartiner la lecture de 42 forax web
hantés par des kikoolol sans obtenir de réponse plus pertinente que « g
le mm pb aider moi » ?

Ou pas.

Mais j'ai toujours été pour la défense des causes perdues, chacun ses
hobbies :)

--
Eric

Eric Demeester <eric+usenet@galacsys.net> écrivait :

Sinon, je vois que c'est le retour des vieux cons sur Usenet, peut-être
que ça aidera à faire comprendre aux gens que c'est plus efficace de
poser une question ici que de se tartiner la lecture de 42 forax web
hantés par des kikoolol sans obtenir de réponse plus pertinente que « g
le mm pb aider moi » ?

Tu prêches un (vieux)con-verti. D'ailleurs, je suis bien content que les
forums de support "proxad" soient en NNTP Usenet.

Pour continuer « en charte », les trois fichiers précités sont
représentatifs du moteur MySQL MyISAM :
*.frm -> structure de la table
*.MYD -> données de la table
*.MYI -> index de la table

Et, pour répondre à l'autre question :

est-ce que ces fichiers sont déplaçables d'une bdd mySQL à une autre
facilement ?

Je répondrais comme toi, qu'il est cent (mille ?) fois préférable
d'exporter la ou les tables dans un fichier SQL, d'éventuellement
modifier le fichier, puis de l'importer dans l'autre bdd.
Je pratique ça très souvent avec, par exemple, modification du nom des
tables à l'aide d'un éditeur de texte (UtraEdit depuis des lustres pour
moi).
--
Il vaut mieux ignorer où l'on est, et savoir qu'on l'ignore, que de se
croire avec confiance où l'on n'est pas. Jean Dominique Cassini.
Technologie aéronautique - http://ottello.net - Les anciens de Vilgénis