Bonjour,

J'aimerais faire une copie d'une db (enfin via un script).
Y a-t-il une meilleure solution que de faire un mysqldump | mysql pour dupliquer une base ?
J'ai un peu regardé mysqlhotcopy, mais je ne suis pas sûr qu'il soit adapté, ils n'indiquent pas si la copie permet de sauvegarder les fichiers dans le même dossier avec simplement un nom de base différent. Ils destinent plutôt son utilisation à du backup.
Les tables sont des MyISAM.

Merci

J'aimerais faire une copie d'une db (enfin via un script).
Y a-t-il une meilleure solution que de faire un mysqldump | mysql pour dupliquer une base ?

En fait j'ai du mal à comprendre en quoi ça ne te convient pas... Sur quels critères penses-tu trouver mieux ?

<mode type="delation">Hé m'sieur, je l'ai vu, il a uppé son sujet ! </mode>

Il faudrait définir "meilleure". Si tu coupes ton serveur tu peux faire une copie des fichiers avec `cp -pR` (MyISAM uniquement).

Sinon, il y a aussi mysqlpdump, ou mk-parallel-dump (Maatkit).

Merci de vos interventions.

En fait, elle est tout de même assez violente, c'est en cela que je la trouvais mauvaise, à savoir que devoir générer les requètes, et ensuite les réexécuter juste après, ce n'est pas vraiment malin, alors que pouvoir copier les données binaires me paraissait plus judicieux.

Le dump multithreadé que tu proposes Hubert, augmenterait virtuellement la performance, la sauvegarde serait plus rapide puisque mutualisée sur tous les coeurs, mais cela demande en définitive autant de temps processeur.

Après mon but n'est pas d'optimiser à fond, mais juste que cela m'étonne grandement que mysql n'aie pas un outil pour faire un duplicatat de ses bases (hormi mysqlhotcopy) qui éviterait de repasser inutilement au format SQL (il faut avouer que c'est tout de même dommage de passer par SQL pour faire une simple copie de fichier…). C'était essentiellement cette inutilité qui me troublait.

Sinon, pour le cp, comme tu dis il faut couper le serveur, et cela me dérange un peu puisque ce n'est pas qu'un serveur de test et de dev, c'est aussi un serveur de production :-/

Tu peux toujours faire des cp sans couper le serveur si tu vérouilles la table sans oublier de faire un FLUSH TABLE, mais c'est à ma connaissance le fonctionnement de mysqlhotcopy, donc autant utiliser ça.

Pour faire un backup qui ne bloque pas le serveur, il faut utiliser les dumpers dont on parlait. D'ailleurs "non-bloquant" c'est de l'abus de langage, puisque tu es sous MyISAM les requêtes non-SELECT seront verrouillées pendant la durée du backup. Et selon la configuration du serveur il se pourraient que les requêtes SELECT aussi.

Si c'est une opération ponctuelle, utiliser mysqlhotcopy. Si tu dois faire ça toutes les semaines, regarde peut-être du côté de la réplication.

En fait, je vais expliquer tout de même le but, c'est pour transférer une version de dev vers une version de test, via un script. Donc ce sont deux bases de nom différent sur le même serveur, mais la copie s'effectue de manière discrète, c'est à dire que ce sont les développeurs qui, quand ils sentent que la version de développement est stable, lancent le script pour mettre à jour la version de test (accessible publiquement).
Donc ce n'est pas non plus de la réplication parce que les deux bases doivent être indépendantes et sur le même serveur (la réplication c'est bien les histoires de serveurs slave et master ? ).
Et sinon tu as déjà utilisé mysqlhotcopy, parce que justement si j'avais des doutes sur ca pertinence, c'est essentiellement que je n'ai pas l'impression qu'il soit capable simplement de copier une base vers le même serveur de base de données. A la vue du man, ils parlaient essentiellement de backup, mais je dois avouer que je ne me suis pas intéressé plus précisément au principe de ce script ni à la structure des dossiers data de mysql. Je voulais savoir auparavant s'il y avait un outil ou une commande dédié, ou bien si mes doutes se confirmaient…

Sinon, pour l'histoire du blocage, ça ne bloquera que la base de développement donc cela ne pose aucun problème. La seule chose qui m'importe, c'est que les sites en production ne soient pas affectés.

Jamais utilisé mysqlhotcopy. Pour que le serveur prenne en compte les nouvelles tables, le mieux serait de le relancer avec un simple /etc/init.d/mysql restart

Sinon, puisqu'il s'agit d'une duplication sur un même serveur, ne te casse pas la tête : pour chaque table, ...suivi d'un gros ALTER TABLE qui rajoute les index sur la nouvelle table. Tu peux aussi le faire dans l'autre sens avec Note : DISABLE KEYS désactive la mise à jour des index non-UNIQUE.

Merci, je ne connaissais pas cette option de CREATE TABLE.

Je vais étudier la "meilleure" solution (en gros le compromis entre facilité de mise en œuvre et pragmatisme de la solution…)

Bon, j'ai implémenté ta technique Hubert, je dois dire que ça marche super bien

Voici le script si ça intéresse quelqu'un
Merci à vous Calimero et Hubert