Cuando crea una tabla utilizando el motor de almacenamiento InnoDB, los datos escritos en esa tabla se almacenan en el sistema de archivos en un archivo de datos llamado espacio de tabla. Los archivos de espacio de tabla contienen tanto los datos como los índices.

Cuando innodb_file_per_table=ON está configurado, InnoDB usa un archivo de espacio de tabla por tabla InnoDB. Estos archivos de espacio de tabla tienen la .ibd extensión. Cuando innodb_file_per_table=OFF está configurado, InnoDB almacena todas las tablas en el espacio de tabla del sistema InnoDB.

Las versiones de InnoDB en MySQL 5.7 y superiores también admiten un tipo adicional de espacio de tabla llamado espacios de tabla generales que se crean con CREATE TABLESPACE. Sin embargo, las versiones de InnoDB en MariaDB Server no admiten actualmente espacios de tabla generales o CREATE TABLESPACE.

Ubicaciones de espacio de tabla de archivo por tabla

De forma predeterminada, los espacios de tabla de archivo por tabla de InnoDB se crean en el directorio de datos del sistema, que está definido por el datadir variable de sistema. Si desea almacenar datos InnoDB separados de los datos para otros motores de almacenamiento, cambie esto configurando el innodb_data_home_dir variable de sistema.

En el caso de que tenga un espacio de tabla específico que necesite almacenar en una ruta dedicada, puede establecer la ubicación usando el DATA DIRECTORY opción de tabla al crear la tabla.

Por ejemplo,

CREATETABLE test.t1 (
   id INTPRIMARYKEYAUTO_INCREMENT,
   name VARCHAR(50))ENGINE=InnoDBDATA DIRECTORY ="/data/contact";

MariaDB luego crea un directorio de base de datos en la ruta configurada y el espacio de tabla de archivo por tabla se creará dentro de ese directorio. En sistemas operativos similares a Unix, puede ver el archivo usando el comando ls:

# ls -al /data/contact/test
drwxrwx--- 2 mysql mysql  4096 Dec 8 18:46 .
drwxr-xr-x 3 mysql mysql  4096Dec818:46..-rw-rw---- 1 mysql mysql 98304 Dec 8 20:41 t1.ibd

Tenga en cuenta que el usuario del sistema que ejecuta el proceso del servidor MariaDB (que suele ser mysql) debe tener permisos de escritura en la ruta indicada.

Copia de espacios de tabla transportables

Los espacios de tabla de archivo por tabla de InnoDB son transportables, lo que significa que puede copiar un espacio de tabla de archivo por tabla de un servidor MariaDB a otro servidor. Esto puede resultarle útil en los casos en los que necesite transportar tablas completas entre servidores y no desee utilizar herramientas de copia de seguridad como mariabackup o mysqldump. De hecho, este proceso incluso se puede utilizar con mariabackup en algunos casos, como al restaurar copias de seguridad parciales o al restaurar tablas o particiones individuales a partir de una copia de seguridad.

Copia de espacios de tabla transportables para tablas sin particiones

Puede copiar el espacio de tabla transportable de una tabla no particionada de un servidor a otro exportando el archivo de espacio de tabla del servidor original y luego importando el archivo de espacio de tabla en el nuevo servidor.

Exportación de espacios de tabla transportables para tablas sin particiones

Puede exportar una tabla no particionada bloqueando la tabla y copiando los .ibd y .cfg archivos desde la ubicación del espacio de tabla relevante para la tabla a una ubicación de respaldo. Por ejemplo, el proceso sería así:

FLUSH TABLES test.t1 FOR EXPORT;

Esto obliga al servidor a cerrar la mesa y proporciona a su conexión un bloqueo de lectura en la mesa.

  • Luego, mientras su conexión aún mantiene el candado en la mesa, copie el archivo de espacio de tabla y el archivo de metadatos a un directorio seguro: 
# cp /data/contacts/test/t1.ibd /data/saved-tablespaces/# cp /data/contacts/test/t1.cfg /data/saved-tablespaces/
  • Luego, una vez que haya copiado los archivos, puede liberar el bloqueo con UNLOCK TABLES: 
UNLOCKTABLES;

Importación de espacios de tabla transportables para tablas sin particiones

Puede importar una tabla no particionada descartando el espacio de tabla original de la tabla, copiando el .ibd y .cfg archivos desde la ubicación de la copia de seguridad a la ubicación del espacio de tabla relevante para la tabla, y luego indicando al servidor que importe el espacio de tabla. Por ejemplo, el proceso sería así:

  • Primero, en el servidor de destino, debe crear una copia de la tabla. Usa el mismo CREATE TABLE declaración que se utilizó para crear la tabla en el servidor original: 
CREATETABLE test.t1 (
   id INTPRIMARYKEYAUTO_INCREMENT,
   name VARCHAR(50))ENGINE=InnoDB;
ALTERTABLE test.t1 DISCARDTABLESPACE;
  • Luego, copie el .ibd y .cfg archivos del servidor original al directorio relevante en el servidor MariaDB de destino: 
# scp /data/tablespaces/t1.ibd target-server.com:/var/lib/mysql/test/# scp /data/tablespaces/t1.cfg target-server.com:/var/lib/mysql/test/

Los espacios de tabla de archivo por tabla se pueden importar con solo el .ibd archivo en muchos casos. Si no tiene el tablespace .cfg archivo por el motivo que sea, por lo general vale la pena intentar importar el espacio de tabla con solo el .ibd expediente.

  • Luego, una vez que los archivos estén en el directorio adecuado en el servidor de destino, use ALTER TABLE ... IMPORT TABLESPACE para importar el espacio de tabla de la nueva tabla: 
ALTERTABLE test.t1 IMPORTTABLESPACE;

Copia de espacios de tabla transportables para tablas particionadas

Actualmente, MariaDB no admite directamente el transporte de espacios de tabla desde tablas particionadas. Ver MDEV-10568 para obtener más información al respecto. Todavía es posible transportar tablas particionadas si usamos una solución alternativa. Puede copiar los espacios de tabla transportables de una tabla particionada de un servidor a otro exportando el archivo de espacio de tabla de cada partición desde el servidor original y luego importando el archivo de espacio de tabla de cada partición en el nuevo servidor.

Exportación de espacios de tabla transportables para tablas particionadas

Puede exportar una tabla particionada bloqueando la tabla y copiando el .ibd y .cfg archivos de cada partición desde la ubicación del espacio de tabla relevante para la partición a una ubicación de respaldo. Por ejemplo, el proceso sería así:

  • Primero, creemos una tabla de prueba con algunos datos en el servidor original: 
CREATETABLE test.t2 (
   employee_id INT,
   name VARCHAR(50),)ENGINE=InnoDBPARTITIONBY RANGE (employee_id)(PARTITION p0 VALUES LESS THAN (6),PARTITION p1 VALUES LESS THAN (11),PARTITION p2 VALUES LESS THAN (16),PARTITION p3 VALUES LESS THAN MAXVALUE
);INSERTINTO test.t2 (name, employee_id)VALUES('Geoff Montee',1),('Chris Calendar',6),('Kyle Joiner',11),('Will Fong',16);
  • Luego, necesitamos exportar el espacio de tabla particionado del servidor original, que sigue el mismo proceso que para exportar espacios de tabla no particionado. Eso significa que necesitamos usar el FLUSH TABLES ... FOR EXPORT declaración en la tabla de destino: 
FLUSH TABLES test.t2 FOR EXPORT;

Esto obliga al servidor a cerrar la mesa y proporciona a su conexión un bloqueo de lectura en la mesa.

  • Entonces, si grep el directorio de la base de datos en el directorio de datos para el recién creado t2 tabla, podemos ver una serie de .ibd y .cfg archivos para la mesa: 
# ls -l /var/lib/mysql/test/ | grep t2
total 428-rw-rw---- 1 mysql mysql 827 Dec 5 16:08 t2.frm-rw-rw---- 1 mysql mysql 48 Dec 5 16:08 t2.par-rw-rw---- 1 mysql mysql 579 Dec 5 18:47 t2#P#p0.cfg-rw-r----- 1 mysql mysql 98304 Dec 5 16:43 t2#P#p0.ibd-rw-rw---- 1 mysql mysql 579 Dec 5 18:47 t2#P#p1.cfg-rw-rw---- 1 mysql mysql 98304 Dec 5 16:08 t2#P#p1.ibd-rw-rw---- 1 mysql mysql 579 Dec 5 18:47 t2#P#p2.cfg-rw-rw---- 1 mysql mysql 98304 Dec 5 16:08 t2#P#p2.ibd-rw-rw---- 1 mysql mysql 579 Dec 5 18:47 t2#P#p3.cfg-rw-rw---- 1 mysql mysql 98304 Dec 5 16:08 t2#P#p3.ibd
  • Luego, mientras nuestra conexión aún mantiene el candado en la tabla, necesitamos copiar los archivos de espacio de tabla y los archivos de metadatos a un directorio seguro: 
$ mkdir /tmp/backup
$ sudo cp /var/lib/mysql/test/*.ibd /tmp/backup
$ sudo cp /var/lib/mysql/test/*.cfg /tmp/backup
  • Luego, una vez que hayamos copiado los archivos, podemos liberar el bloqueo con UNLOCK TABLES: 
UNLOCKTABLES;

Importación de espacios de tabla transportables para tablas particionadas

Puede importar una tabla particionada creando una tabla de marcador de posición, descartando el espacio de tabla original de la tabla de marcador de posición, copiando el .ibd y .cfg archivos desde la ubicación de la copia de seguridad a la ubicación del espacio de tabla relevante para la tabla de marcador de posición y, a continuación, le dice al servidor que importe el espacio de tabla. En ese momento, el servidor puede intercambiar el espacio de tabla de la tabla de marcador de posición con el de la partición. Por ejemplo, el proceso sería así:

  • Primero, necesitamos copiar los archivos de espacio de tabla guardados del servidor original al servidor de destino: 
$ scp /tmp/backup/t2*user@target-host:/tmp/backup
  • Luego, necesitamos importar los espacios de tabla particionados al servidor de destino. El proceso de importación de tablas particionadas es más complicado que el proceso de importación de tablas no particionadas. Para empezar, si aún no existe, entonces necesitamos crear una tabla particionada en el servidor de destino que coincida con la tabla particionada en el servidor original: 
CREATETABLE test.t2 (
   id INTPRIMARYKEYAUTO_INCREMENT,
   name VARCHAR(50),
   employee_id INT)ENGINE=InnoDBPARTITIONBY RANGE (employee_id)(PARTITION p0 VALUES LESS THAN (6),PARTITION p1 VALUES LESS THAN (11),PARTITION p2 VALUES LESS THAN (16),PARTITION p3 VALUES LESS THAN MAXVALUE
);
  • Luego, usando esta tabla como modelo, necesitamos crear un marcador de posición de esta tabla con la misma estructura que no usa particiones. Esto se puede hacer con un CREATE TABLE... AS SELECT declaración: 
CREATETABLE test.t2_placeholder ASSELECT*FROM test.t2 WHERENULL;

Esta declaración creará una nueva tabla llamada t2_placeholder que tiene la misma estructura de esquema que t2, pero no utiliza particiones y no contiene filas.

Para cada partición

A partir de este punto, el resto de nuestros pasos deben realizarse para cada partición individual. Para cada partición, debemos realizar el siguiente proceso:

ALTERTABLE test.t2_placeholder DISCARDTABLESPACE;
  • Luego, copie el .ibd y .cfg archivos para la siguiente partición al directorio relevante para el t2_placeholder tabla en el servidor MariaDB de destino: 
# cp /tmp/backup/t2#P#p0.cfg /var/lib/mysql/test/t2_placeholder.cfg# cp /tmp/backup/t2#P#p0.ibd /var/lib/mysql/test/t2_placeholder.ibd# chown mysql:mysql /var/lib/mysql/test/t2_placeholder*

Los espacios de tabla de archivo por tabla se pueden importar con solo el .ibd archivo en muchos casos. Si no tiene el espacio de mesa .cfg archivo por el motivo que sea, por lo general vale la pena intentar importar el espacio de tabla con solo el .ibd expediente.

  • Luego, una vez que los archivos están en el directorio apropiado en el servidor de destino, necesitamos usar ALTER TABLE ... IMPORT TABLESPACE para importar el espacio de tabla de la nueva tabla: 
ALTERTABLE test.t2_placeholder IMPORTTABLESPACE;

La tabla de marcador de posición ahora contiene datos del p0 partición en el servidor de origen.

SELECT*FROM test.t2_placeholder;+-------------+--------------+| employee_id | name         |+-------------+--------------+|1| Geoff Montee |+-------------+--------------+
  • Entonces, es el momento de transferir la partición del marcador de posición a la tabla de destino. Esto se puede hacer con un ALTER TABLE... EXCHANGE PARTITION declaración: 
ALTERTABLE test.t2 EXCHANGE PARTITION p0 WITHTABLE test.t2_placeholder;

La tabla de destino ahora contiene la primera partición de la tabla de origen.

SELECT*FROM test.t2;+-------------+--------------+| employee_id | name         |+-------------+--------------+|1| Geoff Montee |+-------------+--------------+
  • Repita este procedimiento para cada partición que desee importar. Para cada partición, debemos descartar el espacio de tabla de la tabla de marcador de posición y luego importar el espacio de tabla de la tabla particionada en la tabla de marcador de posición y luego intercambiar los espacios de tabla entre la tabla de marcador de posición y la partición de nuestra tabla de destino.

Cuando este proceso se complete para todas las particiones, la tabla de destino contendrá los datos importados:

SELECT*FROM test.t2;+-------------+----------------+| employee_id | name           |+-------------+----------------+|1| Geoff Montee   ||6| Chris Calendar ||11| Kyle Joiner    ||16| Will Fong      |+-------------+----------------+
  • Luego, podemos eliminar la tabla de marcadores de posición de la base de datos: 
DROPTABLE test.t2_placeholder;

Problemas conocidos al copiar espacios de tabla transportables

Diferentes formatos de almacenamiento para columnas temporales

MariaDB 10.1.2 agregó el mysql56_temporal_format variable de sistema, que habilita un nuevo formato de almacenamiento compatible con MySQL 5.6 para el TIME, DATETIME y TIMESTAMP tipos de datos.

Si un archivo de archivo por espacio de tabla contiene columnas que usan uno o más de estos tipos de datos temporales y si la tabla original del archivo de espacio de tabla se creó con un determinado formato de almacenamiento para estas columnas, entonces el archivo de espacio de tabla solo se puede importar en tablas que fueron también creado con el mismo formato de almacenamiento para estas columnas que la tabla original. De lo contrario, verá errores como los siguientes:

ALTERTABLE dt_test IMPORTTABLESPACE;
ERROR 1808(HY000): Schema mismatch (Column dt precise type mismatch.)

Ver MDEV-15225 para más información.

Consulte las páginas para TIME, DATETIME y TIMESTAMP tipos de datos para determinar cómo actualizar el formato de almacenamiento para columnas temporales en tablas que se crearon antes MariaDB 10.1.2 o que fueron creados con mysql56_temporal_format=OFF.

Diferentes valores de ROW_FORMAT

Los espacios de tabla de archivo por tabla de InnoDB pueden usar diferentes formatos de fila. Se puede especificar un formato de fila específico al crear una tabla, ya sea configurando el ROW_FORMAT opción de mesa o por el escenario el innodb_default_row_format variable de sistema. Consulte Establecer el formato de fila de una tabla para obtener más información sobre cómo establecer el formato de fila de una tabla InnoDB.

Si se creó un archivo de archivo por espacio de tabla con un determinado formato de fila, el archivo de espacio de tabla solo se puede importar en tablas que se crearon con el mismo formato de fila que la tabla original. De lo contrario, verá errores como los siguientes:

ALTERTABLE t0 IMPORTTABLESPACE;
ERROR 1808(HY000): Schema mismatch (Expected FSP_SPACE_FLAGS=0x21,.ibd filecontains0x0.)

El mensaje de error será un poco más descriptivo en MariaDB 10.2.17 y después:

ALTERTABLE t0 IMPORTTABLESPACE;
ERROR 1808(HY000): Schema mismatch (Table flags don't match, server table has 0x1and the meta-datafile has 0x0;.cfg file uses ROW_FORMAT=REDUNDANT)

Asegúrese de verificar el formato de fila de un espacio de tabla antes de moverlo de un servidor a otro. Tenga en cuenta que el formato de fila predeterminado puede cambiar entre las versiones principales de MySQL o MariaDB. Consulte Comprobación del formato de fila de una tabla para obtener información sobre cómo comprobar el formato de fila de una tabla InnoDB.

Ver MDEV-15049 y MDEV-16851 para más información.

Restricciones de clave externa

DISCARD en una tabla con restricciones de clave externa solo es posible después de deshabilitar Foreign_key_checks:

SETSESSION foreign_key_checks=0;ALTERTABLE t0 DISCARDTABLESPACE;

IMPORT, por otro lado, no impone restricciones de clave externa. Por lo tanto, al importar espacios de tabla, solo se puede garantizar la integridad referencial para importar todas las tablas vinculadas por la restricción de clave externa al mismo tiempo, desde una EXPORTACIÓN de esas tablas tomadas con el mismo estado transaccional.

Cifrado de espacio de tabla

MariaDB admite el cifrado de datos en reposo para el motor de almacenamiento InnoDB. Cuando está habilitado, el servidor cifra los datos antes de escribirlos en el espacio de tabla y descifra las lecturas del espacio de tabla antes de devolver los conjuntos de resultados. Esto significa que un usuario malintencionado que intente exfiltrar datos confidenciales no podrá importar el espacio de tabla a un servidor diferente como se muestra arriba sin la clave de cifrado.

Para obtener más información sobre el cifrado de datos, consulte Cifrado de datos para InnoDB.

Ver también

El contenido reproducido en este sitio es propiedad de sus respectivos dueños, y MariaDB no revisa este contenido con anticipación. Los puntos de vista, la información y las opiniones expresadas por este contenido no representan necesariamente las de MariaDB o de cualquier otra parte.