¿Por qué innoDB almacena todas las bases de datos en un archivo?

Question

Era conveniente que Myisam solía almacenar cada tabla en un archivo correspondiente. Innodb ha avanzado en muchos aspectos, pero me pregunto por qué innoDB almacena todas las bases de datos en un archivo (ibdata1 por defecto).

Entiendo que inNODB asignará la ubicación de los datos en el archivo por archivos de índice individuales para tablas, pero no entiendo por qué mezcla todos los datos en un archivo. Y lo que es más importante, ¿por qué mezclar los datos de todas las bases de datos en el servidor?

Una característica interesante de Myisam es que se puede copiar/pegar una carpeta de base de datos a otra máquina y luego usar la base de datos (sin volcado).

Answer 1

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
• Metadatos de mesa
• MVCC Datos (para apoyar el aislamiento de la transacción y Cumplimiento ácido)
  • Segmentos de reversión
  • Deshacer espacio
  • Búfer de redacción doble (escritura de antecedentes para evitar la dependencia del almacenamiento en caché del sistema operativo)
  • Insertar búfer (gestionar los cambios en índices secundarios no únicos)

Vea la representación pictórica de IBDATA1

Por defecto, innodb_file_per_table está desactivado. Esto hace que los cuatro tipos de página de información consigan un solo archivo llamado IBDATA1. Muchas personas intentan difundir los datos haciendo múltiples archivos IBData. Esto podría conducir a la fragmentación de datos y páginas de índice.

Por eso a menudo Recomendar limpiar la infraestructura innoDB, utilizando el archivo IBData1 predeterminado y nada más.

La copia es muy peligrosa debido a la infraestructura bajo la cual trabaja InnoDB. Hay dos infraestructuras básicas

• innodb_file_per_table deshabilitado
• innodb_file_per_table habilitado

Innodb (innodb_file_per_table desactivado)

Con innodb_file_per_table Desactivado, todos estos tipos de información 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 innoDB a la vez requiere copiar todos los/var/lib/mysql.

Copiar una mesa individual de innoDB es totalmente imposible. Debe ver volcar 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 a otra base de datos en el mismo servidor u otro servidor.

Innodb (innodb_file_per_table activado)

Con innodb_file_per_table Habilitados, datos de tabla y sus índices viven en la carpeta de la base de datos junto al archivo .FRM. Por ejemplo, para la tabla DB1. Mytable, la manifestación de esa mesa innodb fuera de IBDATA1 sería:

• /var/lib/mysql/db1/mytable.frm
• /var/lib/mysql/db1/mytable.ibd

Espacio de tabla ibdata1

Todos los metadatos para DB1. La mija todavía reside en IBDATA1 y No hay absolutamente ninguna forma de evitar eso. Los registros de rehacer y los datos de MVCC también viven con IBDATA1.

Cuando se trata de fragmentación de la mesa, esto es lo que le sucede a IBDATA1:

• innodb_file_per_table activado: puedes encoger db1.mytables con ALTER TABLE db1.mytable ENGINE=InnoDB; o OPTIMIZE TABLE db1.mytable;. Esto da como resultado /var/lib/mysql/db1/mytable.ibd que es físicamente más pequeño sin fragmentación.
• innodb_file_per_table desactivado: no puedes encoger db1.mytables con ALTER TABLE db1.mytable ENGINE=InnoDB; o OPTIMIZE TABLE db1.mytable; Porque reside con IBDATA1. Ejecutando cualquier comando en realidad, 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 está completamente abordado en mi publicación de limpieza innodb.

Advertencia (o peligro como El robot diría en Lost in Space)

Si está pensando en copiar el archivo .FRM y .IBD, está en línea para el mundo del dolor. Copiar el archivo .frm y .ibd de una tabla innodb solo es bueno Si y solo si puede garantizar que la ID de espacio de tabla del archivo .ibd coincida exactamente con la entrada de ID de espacio de tabla en los metadatos del archivo IBDATA1.

Escribí dos publicaciones en DBA stackexchange sobre este concepto de identificación de espacio de tabla

• Compresión de mesa en innodb? (Bajo el encabezado 'Restauración de bases de datos')
• Cómo recuperar una mesa innodb cuyos archivos se movieron

Aquí hay un excelente enlace sobre cómo volver a colocar 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 llegar a la comprensión inmediata de que copiar los archivos .IBD es simplemente una locura.

Para innodb, solo necesitas algo que esto se mueva

CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;

Para hacer una copia de una tabla innodb.

Si lo está migrando a otro servidor DB, use MySQLDUMP.

Con respecto a mezclar todas las tablas innoDB de todas las bases de datos, puedo ver la sabiduría al hacerlo. En la empresa de alojamiento DB/web 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 operabilidad de MVCC en múltiples bases de datos.

Answer 2

Puede alternar innoDB para almacenar tablas por archivo agregando innodb-archivo por mesa 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 procesar sin sistema de archivos! http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html

Hay comodidades para almacenar tablas para archivos, como poder recuperar más fácilmente el espacio usado a través de la optimización.

Incluso con archivos por tabla, no puede simplemente copiar los archivos IBD tan fácilmente ya que innoDB es transaccional y almacena información sobre su estado en los archivos IBData/registro compartidos a nivel mundial.

Eso no quiere decir que no se pueda hacer. Si la tabla está fuera de línea, puede descartar/importar los espacios de tabla y copiar los .idbs alrededor http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html

Answer 3

Este es el comportamiento predeterminado pero no obligatorio. De MySQL Docs, usando espacios de tabla por mesa:

Por defecto, todas las tablas e índices innoDB se almacenan en el espacio de tabla del sistema. Como alternativa, puedes almacenar Cada tabla innodb y sus índices en su propio archivo. Esta característica se llama "múltiples espacios de tabla" porque cada tabla que se crea cuando esta configuración está en efecto tiene su propio espacio de 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):

Consideraciones de portabilidad para archivos .ibd

No puede mover libremente los archivos .ibd entre los directorios de bases de datos como puede con los archivos de la tabla Myisam. La definición de tabla almacenada en el espacio de tabla compartido innoDB incluye el nombre de la base de datos. Los ID de transacción y los números de secuencia de registro almacenados en los archivos de espacio de tabla también difieren entre las bases de datos.