HECHOS
Dijiste que estás usando ext4. El límite de tamaño del archivo es de 16 TB. Por lo tanto, Sample.ibdno debe estar lleno.
Dijiste tu innodb_data_file_pathes ibdata1:10M:autoextend. Por lo tanto, el archivo ibdata1 en sí mismo no tiene límite para su tamaño, excepto del sistema operativo.
¿Por qué viene este mensaje? Observe que el mensaje es "La tabla ... está llena", no "El disco ... está lleno". Esta condición de tabla completa es desde un punto de vista lógico . Piensa en InnoDB. ¿Qué interacciones están sucediendo?
Supongo que InnoDB está intentando cargar 93GB de datos como una sola transacción. ¿De dónde Table is Fullemanaría el mensaje? Vería el ibdata1, no en términos de su tamaño físico (que ya descartó), sino en términos de qué límites de transacción se están alcanzando.
¿Qué hay dentro de ibdata1 cuando innodb_file_per_table está habilitado y carga nuevos datos en MySQL?
- Diccionario de datos
- Buffer de doble escritura
- Red de seguridad para prevenir la corrupción de datos
- Ayuda a evitar el sistema operativo para el almacenamiento en caché
- Insertar memoria intermedia (racionaliza los cambios en los índices secundarios)
- Segmentos de reversión
- Deshacer registros
- Haga clic aquí para ver una representación pictórica de
ibdata1
Mis sospechas me dicen que los registros de deshacer y / o los registros de rehacer son los culpables.
¿Qué son estos registros? De acuerdo con el libro
Capítulo 10: "Motores de almacenamiento" Página 203 Los párrafos 3,4 dicen lo siguiente:
El motor InnoDB mantiene dos tipos de registros: un registro de deshacer y un registro de rehacer. El propósito de un registro de deshacer es revertir las transacciones, así como mostrar las versiones anteriores de los datos para consultas que se ejecutan en el nivel de aislamiento de transacciones que lo requiere. El código que maneja el registro de deshacer se puede encontrar en storage / innobase / buf / log / log0log.c .
El propósito del registro de rehacer es almacenar la información que se utilizará en la recuperación de fallas. Permite que el proceso de recuperación vuelva a ejecutar las transacciones que pueden haberse completado o no antes del bloqueo. Después de volver a ejecutar esas transacciones, la base de datos se lleva a un estado coherente. El código que trata con el registro de rehacer se puede encontrar en storage / innobase / log / log0recv.c .
ANÁLISIS
Hay 1023 registros de deshacer dentro de ibdata1 (consulte Segmentos de reversión y espacio de deshacer) . Como los registros de deshacer guardan copias de los datos tal como aparecieron antes de la recarga, todos los registros de deshacer de 1023 han alcanzado su límite. Desde otra perspectiva, todos los registros de deshacer 1023 pueden estar dedicados a la única transacción que carga la Sampletabla.
PERO ESPERA...
Probablemente esté diciendo "Estoy cargando una Samplemesa vacía ". ¿Cómo están involucrados los registros de deshacer? Antes de Samplecargar la tabla con 93 GB de datos, estaba vacía. La representación de cada fila que no existía debe ocupar un espacio de limpieza en los registros de deshacer. Llenar 1023 Deshacer registros parece trivial dada la cantidad de datos que se vierte ibdata1. No soy la primera persona en sospechar esto:
De la documentación de MySQL 4.1, tenga en cuenta Posted by Chris Calender on September 4 2009 4:25pm:
Tenga en cuenta que en 5.0 (anterior a 5.0.85) y en 5.1 (anterior a 5.1.38), podría recibir el error "tabla está llena" para una tabla InnoDB si InnoDB se queda sin ranuras de deshacer (error # 18828).
Aquí está el informe de errores para MySQL 5.0: http://bugs.mysql.com/bug.php?id=18828
SUGERENCIAS
Cuando cree el mysqldump de la Sampletabla, use --no-autocommit
mysqldump --no-autocommit ... mydb Sample > Sample.sql
Esto pondrá un explícito COMMIT;después de cada INSERT. Luego, vuelva a cargar la mesa.
Si esto no funciona ( no te va a gustar esto ), haz esto
mysqldump --no-autocommit --skip-extended-insert ... mydb Sample > Sample.sql
Esto hará que cada INSERT tenga solo una fila. Mysqldump será mucho más grande (más de 10 veces más grande) y su recarga podría tardar entre 10 y 100 veces más.
En cualquier caso, esto evitará que los registros de deshacer se inunden.
Darle una oportunidad !!!
ACTUALIZACIÓN 2013-06-03 13:05 EDT
SUGERENCIA ADICIONAL
Si la tabla del sistema InnoDB (también conocida como ibdata1) alcanza un límite de tamaño de archivo y no se pueden usar los registros de deshacer, puede agregar otro espacio de tabla del sistema (ibdata2).
Acabo de encontrarme con esta situación hace solo dos días. Actualicé mi publicación anterior con lo que hice: consulte Diseño de base de datos: creación de varias bases de datos para evitar el dolor de cabeza del límite en el tamaño de la tabla
En esencia, debe cambiar innodb_data_file_path para acomodar un nuevo archivo de espacio de tabla del sistema. Déjame explicarte cómo:
GUIÓN
En el disco (ext3), el servidor de mi cliente tenía lo siguiente:
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 2 00:15 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 2 00:15 ibdata2
El escenario fue
innodb_data_file_path=ibdata1:346M;ibdata2:500M:autoextend:max:10240000M
Tenga en cuenta que ibdata2creció a 2196875759616 que es 2145386484M.
Tuve que incrustar el tamaño del archivo ibdata2en innodb_data_file_path y agregaribdata3
innodb_data_file_path=ibdata1:346M;ibdata2:2196875759616;ibdata3:10M:autoextend
Cuando reinicié mysqld, funcionó:
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 3 17:02 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 3 17:02 ibdata2
-rw-rw---- 1 s-em7-mysql s-em7-mysql 32315015168 Jun 3 17:02 ibdata3
En 40 horas, ibdata3creció a 31G. MySQL estaba nuevamente trabajando.