Je veux 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_db1Mais il verrouille chaque table pendant qu'il fonctionne.
Est-ce que le --lock-tables=false l'option fonctionne-t-elle ?
Selon le page de manuel si vous videz des tables InnoDB, vous pouvez utiliser l'option --single-transaction option :
--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 BD innodb :
mysqldump --single-transaction=TRUE -u username -p DB
Mais vous devrait s'inquiéter du verrouillage des tables. Si plusieurs tables sont écrites pendant l'exécution de mysqldump (et que vous utilisez des clés étrangères), votre vidage peut être incohérent. Vous ne le saurez pas avant de le restaurer et d'exécuter des requêtes JOIN sur les données incohérentes. Cela peut prendre un certain temps avant que les données incohérentes ne soient découvertes parce que les JOIN sont utilisés par votre application et non par Mysql (avec les tables MyISAM) ; la restauration fonctionnera très bien, mysql ne vous avertira pas des incohérences. Donc : MyIsam -> verrouillez toujours vos tables. InnoDB -> utilisez --single-transaction .
Cela supprime les instructions LOCK TABLES et UNLOCK TABLES du fichier de vidage, cela n'affecte pas le verrouillage pendant l'exportation.
Non, ce n'est pas ce que vous cherchez ! Voir le commentaire de dabest1. Cela ne fait RIEN pour empêcher vos tables d'être verrouillées lors d'un mysqldump. Ceci n'est PAS une réponse à la question.
Honnêtement, je mettrais en place une réplication pour cela, car si vous ne verrouillez pas les tables, vous obtiendrez des données incohérentes à partir du vidage.
Si le vidage prend plus de temps, les tables qui ont déjà été vidées peuvent avoir changé en même temps qu'une table qui est seulement sur le point d'être vidée.
Donc, soit vous verrouillez les tables, soit vous utilisez la réplication.
Cette BD est presque entièrement en lecture seule, donc je ne suis pas trop inquiet de la voir changer.
Si la réplication n'est pas déjà configurée, vous devez effectuer un dump pour la mettre en place. Le problème est le même.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Une autre solution tardive : Vous pouvez également utiliser Percona XtraBackup pour vider votre base de données de production sans interruption du traitement des transactions. Il permet de faire une sauvegarde à chaud, c'est-à-dire qu'elle n'affecte pas les activités en cours. Voir ici : percona.com/software/mysql-database/percona-xtrabackup (Je n'ai aucune affiliation de quelque manière que ce soit avec Percona).