Comment dupliquer une base de données MySQL sur le même serveur ?

Question

J'ai une grande base de données MySQL, appelons-la live_db que je veux répliquer sur la même machine afin de disposer d'un système de test pour jouer avec ( test_db ), y compris la structure des tableaux et les données. À intervalles réguliers, je veux mettre à jour le test_db avec le contenu de la live_db ; si possible incrémentielle.

Existe-t-il un mécanisme intégré dans MySQL pour faire cela ? Je pense que la réplication maître-esclave n'est pas la chose que je souhaite puisqu'il devrait être possible de modifier les données dans le fichier test_db . Ces modifications ne doivent cependant pas être préservées.

Regards,

CGD

Answer 1

El mysql acceptera un flux d'instructions SQL à partir de l'entrée standard. Vous pouvez donc acheminer la sortie de mysqldump directement dans mysql sur la ligne de commande. En effectuant cette opération en tant que tâche cron, vous remplacerez régulièrement vos données de test par des données réelles mises à jour :

mysql --user=username --password=passwd -e 'DROP DATABASE test_db;'
mysql --user=username --password=passwd -e 'CREATE DATABASE test_db;'
mysqldump --user=username --password=passwd live_db | mysql --user=username --password=passwd test_db

Notez que, comme vos données sont volumineuses, cela prendra beaucoup de temps.

Answer 2

La réponse de Michaels à propos de l'obligation fonctionne bien mais ne copie pas les événements, les procédures stockées ou les déclencheurs.

Pour les copier, quelques interrupteurs supplémentaires sont nécessaires pour mysqldump : --events --triggers --routines

Pour compléter une copie déjà réalisée :

mysqldump --user=username --password=passwd --no-data --no-create-info --no-create-db --events --triggers --routines live_db | mysql --user=username --password=passwd test_db

Answer 3

Je fais cela depuis plusieurs années dans différents contextes, avec des bases de données petites à moyennes (1 G à 100 G). Le principe de base mysqldump fonctionne pour les petits ensembles de données ; plus ils sont petits, mieux c'est.

Lorsque vous dépassez 5 à 10 Go, selon la charge de MySQL, rapide et sale ne fait plus l'affaire.

pourquoi mysqldump pourrait ne pas suffire

Le problème avec MySQLdump est que pendant qu'il effectue le dump, la base de données active est soit inutilisable, soit très difficile à utiliser, soit la sauvegarde ne sera pas cohérente. À moins que vous ne disposiez d'une fenêtre temporelle suffisamment large pour que le caractère inutilisable de la base de données en direct ne soit pas important, car la base de données ne doit pas être utilisée de toute façon (par exemple, tard dans la nuit).

Les options par défaut ( aquí une discussion sur le pourquoi) rendent la base de données presque inutilisable pendant qu'elle est vidée, sauf si l'utilisation se limite à la lecture de données et à peu de choses. Sur un site de commerce électronique très fréquenté, vous risquez d'être confronté à un carambolage de clients.

Donc, vous utilisez InnoDB et les options modernes (pas par défaut, pour autant que je sache)

--single-transaction --skip-lock-tables

qui permettent au site de fonctionner, bien que plus lentement que la normale, pendant le vidage. En fonction de l'utilisation, cela peut être visiblement plus lent.

Pendant que vous y êtes, videz également les autres données qui pourraient être importantes :

--events --triggers --routines

(...oh, et cela n'aura toujours pas vidé les permissions des utilisateurs. Pour servir de test, peut-être que ce n'était pas si important).

Il existe une solution de contournement que j'ai trouvée "conseillée" ( !) comme un "super hack", qui consiste essentiellement à désactive l'intégrité transactionnelle permettant à la base de données de fonctionner à pleine vitesse pendant qu'elle est vidée. Un peu comme si vous enleviez les freins de votre voiture pour l'alléger et la faire rouler plus vite, oui, ça marchera, mais cela aura des effets secondaires que vous ne remarquerez peut-être pas immédiatement. Vous sera Vous les remarquerez presque sûrement tôt ou tard - et comme pour les freins, ce sera au moment où vous en aurez le plus besoin, et ce ne sera pas joli.

Toutefois, pour un test base de données, ça peut toujours marcher.

Xtrabackup

Si vous avez une base de données "sérieuse", quelle est la raison de ne pas avoir une sauvegarde "sérieuse ?

Réplication esclave

Une autre possibilité si vous avez de l'espace libre - et, de nos jours, 20 Go, ce n'est pas beaucoup - est d'utiliser une base de données auxiliaire.

Vous pouvez installer une deuxième copie de MySQL Server sur le même serveur sur un port différent, et qu'il soit l'esclave (le serveur subira une baisse de performance, en termes de vitesse de stockage). Vous aurez alors deux bases de données identiques (maître vivant, esclave vivant). La première fois vous devrez toujours effectuer une vidange complète pour les synchroniser, avec tous les problèmes que cela implique.

Lorsque vous avez besoin de cloner la base de données de test, arrêtez la réplication de l'esclave - l'esclave vivant restera désormais "gelé" dans le temps - et sauvegardez l'esclave vivant sur la base de données de test, en utilisant MySQLbackup ou en copiant simplement les fichiers de données. Une fois cela fait, vous redémarrez la réplication.

L'impact sur le maître en direct est négligeable, et l'esclave peut en fait être utilisé pour des sélections non critiques pour la mise à jour.

Answer 4

Si vous préférez MySQL Migration Toolkit, vous pouvez double-cliquer sur le nom du schéma dans l'étape Data Mapping et changer le nom du schéma cible.

Answer 5

Pour tous les utilisateurs de mac, avec sequel pro, il suffit d'aller dans base de données (menu) -> Dupliquer la base de données. C'est fait !