Je souhaite copier une base de données de production en direct dans ma base de données de développement locale. Existe-t-il un moyen de le faire sans verrouiller la base de données de production?
J'utilise actuellement:
mysqldump -u root --password=xxx -h xxx my_db1 | mysql -u root --password=xxx -h localhost my_db1
Mais il verrouille chaque table pendant son fonctionnement.
Est-ce que l'option --lock-tables=false
fonctionne?
Selon la page de manuel _, si vous exportez des tables InnoDB, vous pouvez utiliser l'option --single-transaction
--lock-tables, -l
Lock all tables before dumping them. The tables are locked with READ
LOCAL to allow concurrent inserts in the case of MyISAM tables. For
transactional tables such as InnoDB and BDB, --single-transaction is
a much better option, because it does not need to lock the tables at
all.
Pour innodb DB:
mysqldump --single-transaction=TRUE -u username -p DB
C'est trop tard, mais c'est bon pour tous ceux qui recherchent le sujet. Si vous n'êtes pas innoDB et que vous ne craignez pas le verrouillage pendant le vidage, utilisez simplement l'option suivante:
--lock-tables=false
La réponse varie en fonction du moteur de stockage utilisé. Le scénario idéal est si vous utilisez InnoDB. Dans ce cas, vous pouvez utiliser l'indicateur --single-transaction
, qui vous donnera un instantané cohérent de la base de données au moment où le vidage commence.
--skip-add-locks
m'a aidé
Pour vider de grandes tables, vous devez combiner l’option --single-transaction avec --quick.
http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_single-transaction
Honnêtement, je configurerais la réplication pour cela, car si vous ne verrouillez pas les tables, vous obtiendrez des données incohérentes dans le vidage.
Si le vidage prend plus de temps, les tables qui ont déjà été vidées ont peut-être changé, de même que certaines tables sur le point d'être vidées.
Donc, verrouillez les tables ou utilisez la réplication.
Pour les tables InnoDB, utilisez --single-transaction
"il vide l'état cohérent de la base de données au moment où BEGIN a été émis sans bloquer aucune application" MySQL DOCS
http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_single-transaction
C'est à peu près aussi tard que le gars qui a dit qu'il était en retard par rapport à la réponse originale, mais dans mon cas (MySQL via WAMP sous Windows 7), je devais utiliser:
--skip-lock-tables
mysqldump -uuid -ppwd --skip-opt --single-transaction --max_allowed_packet=1G -q db | mysql -u root --password=xxx -h localhost db
En raison de https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_lock-tables :
Certaines options, telles que --opt (activée par défaut), activent automatiquement --lock-tables. Si vous souhaitez remplacer cela, utilisez --skip-lock-tables à la fin de la liste des options.
Aujourd'hui, j'ai même fait face au même problème, mais je n'avais pas accès à la ligne de commande.
LOCK TABLES `yourtable name` WRITE;
puis j'ai importé dans mon environnement de développement .Works fine . espérons qu'il aide quelqu'un
Une autre réponse tardive:
Si vous essayez de créer une copie chaude de la base de données du serveur (dans un environnement Linux) et que le moteur de base de données de toutes les tables est MyISAM, vous devriez utiliser mysqlhotcopy
.
Selon la documentation:
Il utilise FLUSH TABLES, LOCK TABLES et cp ou scp pour créer une base de données sauvegarde. C'est un moyen rapide de faire une sauvegarde de la base de données ou d'un seul tables, mais il ne peut être exécuté que sur le même ordinateur que la base de données les répertoires sont situés. mysqlhotcopy ne fonctionne que pour la sauvegarde Tables MyISAM et ARCHIVE.
La durée LOCK TABLES
dépend de la durée pendant laquelle le serveur peut copier les fichiers MySQL (cela ne crée pas de vidage).