Perte de socket Mysql [Résolu]

[nyko_kliko]

Bonjour,
après moulte et moulte recherches sur le net, je ne trouve pas exactement mon pb. Il est surement special.
J'explique
J'ai des fichiers de type mysql dans dossier A = /home/test/dw/mysql/stage/
Je désire les copier dans le dossier de base de données B = /home/test/dw/mysql/db/
B est configuré dans /etc/my.cnf.
[mysqld]
datadir = "/home/test/dw/mysql/db/"

Au moment où je désire copier les fichiers de A. J'arrête le service mysql.
/usr/share/mysql/mysql.server stop ==> ok
je vide le dossier B
rm -rf /home/test/dw/mysql/db/*

ensuite je recopie A dans B,
cp -rf /home/test/dw/mysql/stage/* /home/test/dw/mysql/db/

j'affecte les droit pour le user mysql
chown -R mysql.mysql /home/test/dw/mysql/db/

puis je désire relancer mysql
/usr/share/mysql/mysql.server stop ==> failed

Par la suite, la socket est couper entre le client mysql et le server.
Je suis obligé de réinstaller mysql pour retrouver la socket.

Je ne comprend pas. Je suppose que le lien se coupe suite à la commande de vidage du dossier B (rm -rf B).

Voila je commence à peter un ca... ca fait une journée je tente de comprendre.
Si qq1 peut m'aider. please
Merci d'avance.

[Roy Miro]

Bonjour,
Si j'ai bien compris, tu as 2 BD: A et B.
Pour quoi ne pas tenter la commande mysqldump?
Si tu préfère que A soit automatiquement sauvegarder dans B, tu peux essayer la fonction réplication de MySQL (chose que n'ai pas encore eu à utiliser) donc je ne sais pas si ça te conviendras.

[nyko_kliko]

Tout d'abord A n'est pas une base de données mais un dossier de fichiers de bases de données provenant d'un serveur externe. B est la base de données sur le site local.
La transmission entre le SGBD distant et A s'effectue via rsync.(logiciel de transfert de données incrémental)
Au sujet de la replication, elle fut déjà proposée et testée, cela fonctionne pas trop mal. Cependant la hierarchie ne veut pas de cette solution et préfère faire de la façon ci-dessus.
La réplication était simple à mettre en place mais l'administrateur résidant ne le voit pas de cet oeil.

Merci à toi.

[Roy Miro]

J'ai Mysql sous Windows et pas sous linux (mais peu importe), je supposes que B est le repertoire où le serveur doit trouver les bases de données (sous forme de .sql).

D'abord tu vides totalement le repertoire B (option -r) puis tu copies les fichiers type mysql. Alors si ces fichiers mysql correspondent à des BD type InnoDB, ça ne risque pas de marcher (même si je ne m'explique pas la perte du socket qui entraine la réinstallation du serveur Mysql).
En effet, tu ne peux pas charger un .sql par simple copie de ce dernier dans le repertoire B. (En revanche il paraît que c'est possible si c'est des BD MyIsam).

A mon avis, la seule façon de faire une copie propre est d'utiliser mysqldump.

Au passage, y avait t-il pas un repertoire "data" dans /home/test/dw/mysql/db/ qui a p-e été effacé? Car sous Windows, ce repertoire contient justement ces .sql, p-e en est-il de même sous linux?

[nyko_kliko]

Au passage, y avait t-il pas un repertoire "data" dans /home/test/dw/mysql/db/ qui a p-e été effacé? Car sous Windows, ce repertoire contient justement ces .sql, p-e en est-il de même sous linux.

Le répertoire data (sous Windows) n'existe pas avec Linux.
Le chemin /home/test/dw/mysql/db/ est spécifié dans /etc/my.cnf. Il s'agit de l'endroit où mysql va chercher les données.
Pour les tables de type InnoDB, j'ai décommenté la ligne skip-innodb. C-a-d, que le serveur évitera le traitement de ce type.
Le système utilise des tables de type MyIsam.

MyISAM est une évolution de ISAM, capable de fonctionner avec de larges données et très rapide pour les SELECT à rallonge. Ces tables prennent moins de places que leurs confrères, reconnaît les index full-text et les tables compressées.

Solution temporaire:
Dans le script de copy, je n'exécute plus la ligne rm -rf <cible> car j'effectue une copie cp -rf <source> <cible>.
Mais le hic est que si jamais dans l'autre dossier il y a des tables supprimées, elles existeront toujours dans ma base pseudo repliquée.

Je ne suis pas contre le msqldump mais quand il s'agit de serveurs distants utilisant de la bande passante et en plus qu'il s'agit de tables de plusieurs Giga. Il faut parfois prendre d'autres décisions.