La arquitectura de InnoDB exige el uso de cuatro tipos básicos de páginas de información
- Páginas de datos de tabla
- Páginas de índice de tabla
- Tabla MetaData
- Datos MVCC (para soportar el aislamiento de transacciones y el cumplimiento de ACID )
- Segmentos de reversión
- Deshacer espacio
- Memoria intermedia de doble escritura (escritura en segundo plano para evitar la dependencia del almacenamiento en caché del sistema operativo)
- Insert Buffer (gestión de cambios en índices secundarios no únicos)
Vea la representación pictórica de ibdata1
Por defecto, innodb_file_per_table está deshabilitado. Esto hace que los cuatro tipos de páginas de información obtengan un solo archivo llamado ibdata1. Muchas personas intentan distribuir los datos creando múltiples archivos ibdata. Esto podría conducir a la fragmentación de datos y páginas de índice.
Es por eso que a menudo recomiendo limpiar la infraestructura de InnoDB, usando el archivo ibdata1 predeterminado y nada más .
Copiar es muy peligroso debido a la infraestructura bajo la cual trabaja InnoDB. Hay dos infraestructuras básicas.
- innodb_file_per_table deshabilitado
- innodb_file_per_table habilitado
Con innodb_file_per_table deshabilitado, todos estos tipos de información de InnoDB viven dentro de ibdata1. La única manifestación de cualquier tabla InnoDB fuera de ibdata1 es el archivo .frm de la tabla InnoDB. Copiar todos los datos de InnoDB a la vez requiere copiar todos / var / lib / mysql.
Copiar una tabla InnoDB individual es totalmente imposible. Debe volcar MySQL para extraer un volcado de la tabla como una representación lógica de los datos y sus definiciones de índice correspondientes. Luego cargaría ese volcado en otra base de datos en el mismo servidor u otro servidor.
Con innodb_file_per_table habilitado, los datos de la tabla y sus índices viven en la carpeta de la base de datos al lado del archivo .frm. Por ejemplo, para la tabla db1.mytable, la manifestación de esa tabla InnoDB fuera de ibdata1 sería:
/var/lib/mysql/db1/mytable.frm/var/lib/mysql/db1/mytable.ibd
Sistema de tablas ibdata1
Todos los metadatos para db1.mytable todavía residen en ibdata1 y no hay absolutamente nada de eso . Los registros de rehacer y los datos de MVCC también viven con ibdata1.
Cuando se trata de la fragmentación de la tabla, esto es lo que le sucede a ibdata1:
- innodb_file_per_table habilitado : puede reducir db1.mytables con
ALTER TABLE db1.mytable ENGINE=InnoDB;oOPTIMIZE TABLE db1.mytable;. Esto hace que /var/lib/mysql/db1/mytable.ibd sea físicamente más pequeño sin fragmentación.
- innodb_file_per_table deshabilitado : no puede reducir db1.mytables con
ALTER TABLE db1.mytable ENGINE=InnoDB;oOPTIMIZE TABLE db1.mytable;porque reside con ibdata1. Al ejecutar cualquiera de los comandos, haga que la tabla sea contigua y más rápida para leer y escribir. Desafortunadamente, eso ocurre al final de ibdata1. Esto hace que ibdata1 crezca rápidamente. Esto se aborda completamente en mi publicación de limpieza de InnoDB .
Si está pensando en copiar el archivo .frm y .ibd, está en línea para el mundo de los daños. Copiar el archivo .frm y .ibd de una tabla InnoDB solo es bueno si y solo 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 .
Escribí dos publicaciones en DBA StackExchange sobre este concepto de id de espacio de tabla
Aquí hay un excelente enlace sobre cómo volver a conectar cualquier archivo .ibd a ibdata1 en caso de id. De espacio de tabla no coincidentes: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . Después de leer esto, debe darse cuenta de inmediato de que copiar archivos .ibd es simplemente una locura.
Para InnoDB, solo necesita algo para moverse
CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
hacer una copia de una tabla InnoDB.
Si lo está migrando a otro servidor de base de datos, use mysqldump.
Con respecto a mezclar todas las tablas de InnoDB de todas las bases de datos, puedo ver la sabiduría al hacerlo. En la empresa de alojamiento web / DB de mi empleador, tengo un cliente MySQL que tiene una tabla en una base de datos cuyas restricciones se asignan a otra tabla en otra base de datos dentro de la misma instancia de MySQL. Con un repositorio de metadatos común, hace posible el soporte transaccional y la operatividad MVCC en múltiples bases de datos.
Puede alternar InnoDB para almacenar tablas por archivo agregando innodb-file-per-table a su cnf.
Innodb realmente se preocupa por las páginas de datos en un nivel básico. De hecho, puede configurar InnoDB para usar solo un dispositivo de bloque sin formato sin ningún sistema de archivos. http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html
Hay conveniencias para almacenar tablas para archivos, como poder recuperar más fácilmente el espacio utilizado a través de optimizar.
Incluso con archivos por tabla, no puede copiar los archivos ibd tan fácilmente, ya que InnoDB es transaccional y almacena información sobre su estado en los archivos ibdata / log compartidos globalmente.
Eso no quiere decir que no se puede hacer. Si la tabla está fuera de línea, puede descartar / importar los espacios de tabla y copiar los .idbs en http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html
fuente
Este es el comportamiento predeterminado pero no obligatorio. Desde documentos de MySQL, usando espacios de tabla por tabla :
En cuanto a por qué, la razón es probablemente las diferentes arquitecturas de los dos motores (MyISAM e InnoDB). Por ejemplo, en InnoDB, no puede simplemente copiar el archivo .ibd a otra base de datos o instalación. Explicación (de la misma página):
fuente