Puis-je copier une base de données MySQL en copiant les fichiers? Que contiennent exactement les fichiers?

13

J'utilise la base de données MySQL et j'utilise une machine Ubuntu Linux.

Ma base de données nommée db_test, je remarque que sous chemin /var/lib/mysql/db_test, il y a des fichiers suffixe avec .frm, .MYD, .MYIcomme suit:

/var/lib/mysql/db_test# ls

cars.frm 
cars.MYD 
cars.MYI

customers.frm
customers.MYD
customers.MYI

departments.frm
departments.MYD
departments.MYI

...

Semble chacun .frm, .MYD, .MYIgroupe de fichiers mis en correspondance avec une table dans la base de données.

J'ai deux questions à poser:

  1. Que font exactement les trois fichiers?

  2. Si je crée un nouveau répertoire sous path /var/lib/mysql/say db_test_2, et que je copie chaque fichier du db_test_1répertoire dans db_test_2, cela créera-t-il également une nouvelle base de données db_test_2qui a exactement le même contenu (tables) que db_test_1le sien?

Cette action de déplacement de fichiers de base de données physique crée-t-elle le même résultat que les actions de ligne de commande suivantes:

  1. vider la base de données db_test_1sur

  2. créer une nouvelle base de données db_test_2

  3. puis vider la db_test_1base de données dans la nouvelle base de données db_test_2?

Si c'est le cas, il semble que le déplacement de fichiers soit beaucoup plus rapide que celui utilisé mysqldumppour copier des bases de données (ou pour importer des données d'une base de données vers une autre base de données dans MySQL). Des opinions à ce sujet?

mysql database Mellon
la source

Réponses:

5

  1. AFAIR, .frm est un fichier de description (où la structure de la table de base de données est décrite), .MYD est un fichier avec des données, .MYI est un fichier avec des index.

  2. Oui, la copie sera beaucoup plus rapide. Mais il y a un problème: ce n'est pas atomique. Sous une charge élevée, les fichiers copiés seront incohérents et peut-être même corrompus. Surtout si vous utilisez un moteur plus «intelligent» comme InnoDB.

Edit: ps Vous pouvez copier ces fichiers en toute sécurité, mais avant d'arrêter le serveur mysql.

rvs
la source
4

Vous disposez d'un outil de ligne cmd qui fait exactement cela: mysqlhotcopy

Cela fonctionne bien avec les tables myisam, mais pas avec les tables InnoDb.

Si vous avez configuré votre serveur avec lvm, et placez votre / var / lib / mysql sur un volume dédié voici la façon dont je recommande de sauvegarder très rapidement et de manière non bloquante toutes vos bases de données:

mysql -U root -p
  > flush tables with read lock;

Cela vide toutes vos tables sur le disque et bloque toute opération r / w

  > system "lvcreate -s -L 1G -n lvMysql_snap /dev/vg_myserver/lv_mysql" ;

Doit être adapté à votre configuration, cela crée un instantané du système de fichiers de votre base de données. Ça ne prend pas de temps

  > unlock tables;

Ceci est fait, le fonctionnement R / W reprend.

Vous pouvez maintenant monter / dev / vg_myserver / lvMysql_snap et créer une archive tar de votre base de données!

Olivier S
la source
Cela semble être un moyen rapide de sauvegarder la base de données. Mais qu'en est-il du retour de cet instantané pour qu'il redevienne ma base de données en direct? C'est la partie qui m'inquiète vraiment. Je peux mysqldumpmon db en moins de 2 secondes. La restauration est la partie lente, qui prend 5 à 10 minutes.
Buttle Butkus
sur les distributions récentes, les instantanés lvm peuvent être restaurés à l'origine, mais ce n'est probablement pas ce que vous voulez pour gérer les sauvegardes de la base de données.
Olivier S
Concernant mysqlhotcopy: "Cet utilitaire est déconseillé dans MySQL 5.6.20 et supprimé dans MySQL 5.7" De: [ dev.mysql.com/doc/refman/5.6/en/mysqlhotcopy.html]
zeusstl
0

Cela fonctionnera pour MyISAM, mais pas pour InnoDB. Voir /server//a/367321/57569

De cette réponse, à propos d'InnoDB:

Si vous songez à copier simplement le fichier .frm et .ibd, vous êtes en ligne pour le monde de mal. La copie des fichiers .frm et .ibd d'une table InnoDB n'est bonne que si vous pouvez garantir que l'ID d'espace disque logique du fichier .ibd correspond exactement à l'entrée d'ID d'espace disque logique dans les métdonnées du fichier ibdata1.

Peter V. Mørch
la source