MySqldump incompleto

Estoy tratando de ejecutar mysqldump para crear una instantánea de la base de datos, y descubro que se detendrá aleatoriamente a mitad de camino, sin informar ningún error. Mi base de datos es relativamente pequeña (aproximadamente 100 MB) y está usando InnoDB.

Lo estoy ejecutando como:

mysqldump --force --single-transaction --quick --user myuser --password=mypass -h mydatabasehost mydb > /tmp/snapshot.sql

La comprobación del código de salida informa 0.

Mi versión es: mysqldump Ver 10.13 Distrib 5.1.52, para redhat-linux-gnu (i386)

He visto algunas publicaciones similares e incluso un informe oficial de error , pero ninguna de las soluciones parece aplicarse.

¿Cómo obtengo mysqldump para tomar una instantánea completa de la base de datos?

EDITAR: Mi base de datos actualmente reside en el RDS de Amazon.

Es posible que haya sido un problema al max_allowed_packetno estar lo suficientemente alto tanto en el cliente (es decir, mysqldump) como en el servidor (es decir, Amazon RDS). Configuré esto en 500M en ambos y eso parece haber solucionado el problema.

Dado que las tablas de esquema de información de InnoDB solo dan estimaciones de recuento de filas, es difícil saber si mi instantánea realmente incluye todo, desde RDS. Todas las tablas están ahí, pero los recuentos de filas difieren. Actualizaré con una respuesta más definitiva cuando tenga tiempo para escribir un análisis más completo.

¿Has probado?

mysqldump --compress --add-drop-table data --routines --events  --comments --extended-insert -h {host} -u {user} -p {database} > dbdump.sql

Esto es simple como siempre lo hago sin ningún problema. Básicamente, haciendo el volcado de esta manera obtienes todo lo que tienes (datos, objetos y, a veces, comentarios valiosos) en un momento determinado, ignorando las transacciones no confirmadas.

Por lo que yo entiendo, los documentos mysql: una sola transacción fallará si se realiza una lectura en la tabla mientras está volcando. ¿Cuál es el resultado cuando se ejecuta sin "--force --single-transaction --quick"?

Es completamente posible que la tabla esté corrupta. No quiero decir que los datos y / o páginas de índice estén dañados. Podría haber algo muy simple que está roto.

Recientemente tuve un problema con una secuencia de comandos de respaldo en un servidor esclavo cuando comparé varias bases de datos en paralelo. Ejecutar mysqldump en una de las bases de datos resultó en un mysqldump muy pequeño. El DB tenía más de 80 mesas. Sin embargo, mysqldump se detuvo en la quinta tabla en el DB. Cuando corrí SHOW CREATE TABLE tblname\Gsobre la mesa del Esclavo, recibí el error "Tabla no encontrada". Cuando ejecuté SHOW CREATE TABLE tblname\Gel Master, la descripción de la tabla se mostró como se esperaba.

Lo que sucedió fue un poco loco: un cliente solicitó una restauración de la tabla y un ingeniero restauró el archivo .ibd de la tabla InnoDB desde una copia de seguridad del disco. El id. De espacio de tabla del archivo .ibd (que era 25) no coincidía con el id. De espacio de tabla registrado en ibdata1 (que era 28).

Solucioné el problema mangueando el esclavo, mysqldumping el maestro y configurando la replicación desde cero. Afortunadamente, los datos y el índice spave totalizaron 7GB. Por lo tanto, el proceso rstore no fue un gran problema.

MORALEJA DE LA HISTORIA

El problema básico es que mysqldump no informa un error en un InnoDB cuando la identificación del tablespace es incorrecta. Cuando un mysqldump finaliza y no volca todas las tablas en orden alfabético, eso indica que terminó por un error y lo hizo sin imprimir un mensaje de error.

Verifique para asegurarse

• puede mostrar la estructura de la tabla usando SHOW CREATE TABLE
• puede consultar todo sobre una tabla desde INFORMATION_SCHEMA.TABLES

Lo siguiente es solo una lluvia de ideas sobre mysqldump e InnoDB:

Piense en el comportamiento de mysqldump contra una tabla InnoDB. Si hay páginas sucias en el InnoDB Buffer Pool que pertenecen a una tabla que está volcando, las páginas sucias de esa tabla deben vaciarse en el disco antes de SELECT /* SQL_NO_CACHE */poder ejecutarse contra ella.

Como está utilizando Amazon RDS, mi intuición es que su base de datos se encuentra en una infraestructura de múltiples inquilinos (no dude en corregir esta declaración si estoy simplificando demasiado). Otras bases de datos pueden estar usando un InnoDB Buffer Pool compartido, un archivo de metadatos compartido (ibdata1) y un espacio de tabla compartido (ibdata1 si innodb_file_per_table está deshabilitado).

También puede haber cierta redundancia de la base de datos en curso, lo que podría afectar MVCC contra la base de datos, a pesar de que es un conjunto de datos pequeño.

Es posible que desee aumentar innodb_lock_wait_timeout (por defecto 50 segundos) en su sesión de mysqldump para ver si esto tiene algún efecto en Amazon RDS (o hacer que Amazon aumente este límite). Además, intente experimentar con el volcado de tablas individuales.

ACTUALIZACIÓN 2011-11-14 17:58 EDT

Intente ejecutar esto dentro de su sesión de base de datos (lo establece en dos minutos):

SET innodb_lock_wait_timeout = 120;