¿Puedo copiar una base de datos MySQL copiando los archivos? ¿Qué contienen exactamente los archivos?

13

Estoy usando la base de datos MySQL y una máquina Ubuntu Linux.

Mi base de datos llamada db_test, noto que bajo la ruta /var/lib/mysql/db_test, hay archivos con el sufijo .frm, .MYD, .MYIcomo el siguiente:

/var/lib/mysql/db_test# ls

cars.frm 
cars.MYD 
cars.MYI

customers.frm
customers.MYD
customers.MYI

departments.frm
departments.MYD
departments.MYI

...

Parece cada uno .frm, .MYD, .MYIgrupo de archivos de mapeado con una tabla en la base de datos.

Tengo dos preguntas que hacer a continuación:

  1. ¿Qué están haciendo exactamente los tres archivos?

  2. Si creo un nuevo directorio en la ruta , por /var/lib/mysql/ejemplo db_test_2, y copio todos los archivos del db_test_1directorio db_test_2, ¿creará también una nueva base de datos db_test_2que tenga exactamente el mismo contenido (tablas) que db_test_1's?

¿Esta acción de movimiento de los archivos de la base de datos física crea el mismo resultado que las siguientes acciones de línea de comandos:

  1. volcado de la base de datos db_test_1a cabo

  2. crear una nueva base de datos db_test_2

  3. luego volcar la db_test_1base de datos en la nueva base de datos db_test_2?

Si es así, parece que mover archivos es mucho más rápido que usarlos mysqldumppara copiar bases de datos (o para importar datos de una base de datos a otra base de datos en MySQL). ¿Alguna opinión sobre esto?

mysql database Mellon
fuente

Respuestas:

5

  1. AFAIR, .frm es un archivo de descripción (donde se describe la estructura de la tabla de la base de datos), .MYD es un archivo con datos, .MYI es un archivo con índices.

  2. Sí, la copia será mucho más rápida. Pero hay un problema: no es atómico. Bajo alta carga, los archivos copiados serán inconsistentes y tal vez incluso corruptos. Especialmente si está utilizando un motor más "inteligente" como InnoDB.

Editar: ps Puede copiar estos archivos de forma segura, pero antes debe detener el servidor mysql.

rvs
fuente
4

Tiene una herramienta cmd-line que hace exactamente esto: mysqlhotcopy

Funciona bien con las tablas myisam, pero no con las tablas InnoDb.

Si configuró su servidor con lvm y colocó su / var / lib / mysql en un volumen dedicado, esta es la forma en que recomiendo hacer una copia de seguridad muy rápida y sin bloqueo de todas sus bases de datos:

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

Esto vacía todas sus tablas al disco y bloquea cualquier operación de r / w

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

Necesita adaptarse a su configuración, esto crea una instantánea del sistema de archivos de su base de datos. No toma tiempo

  > unlock tables;

Esto se hace, se reanuda la operación R / W.

¡Ahora puede montar / dev / vg_myserver / lvMysql_snap y crear un archivo tar de su base de datos!

Olivier S
fuente
Esto parece una forma rápida de hacer una copia de seguridad de la base de datos. Pero, ¿qué pasa con volver a cambiar esa instantánea para que vuelva a ser mi base de datos en vivo? Esa es la parte que realmente me preocupa. Puedo mysqldumpmi db en menos de 2 segundos. Restaurarlo es la parte lenta, que toma de 5 a 10 minutos.
Buttle Butkus
en distribuciones recientes, las instantáneas de lvm se pueden revertir al origen, pero probablemente no sea lo que desea para administrar las copias de seguridad de la base de datos.
Olivier S
Con respecto a mysqlhotcopy: "Esta utilidad está en desuso en MySQL 5.6.20 y se elimina en MySQL 5.7" De: [ dev.mysql.com/doc/refman/5.6/en/mysqlhotcopy.html]
zeusstl
0

Esto funcionará para MyISAM, pero no para InnoDB. Ver /server//a/367321/57569

De esa respuesta, sobre InnoDB:

Si está pensando en copiar el archivo .frm y .ibd, está en línea para un mundo de daños. Copiar el archivo .frm y .ibd de una tabla InnoDB solo es bueno si puede garantizar que el id del espacio de tabla del archivo .ibd coincida exactamente con la entrada de id del espacio de tabla en los metadatos del archivo ibdata1.

Peter V. Mørch
fuente