Tengo una base de datos instalada, que me gustaría hacer una copia de seguridad en mysql. El problema mysqldumpfalla al exportar la tabla 'maia_mail'

# mysqldump -u root -p maia > maia.sql
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `maia_mail` at row: 15

Se ejecuta durante menos de 30 segundos y obtiene el error como se indicó anteriormente.

El tamaño total de la base de datos es de 1.3GB con la tabla maia_mail de 1.0GB

En my.cnftengo este conjunto:

[mysqld]
max_allowed_packet      = 1300M
[mysqldump]
max_allowed_packet      = 1300M

¿Asesorar o dar alguna orientación sobre cómo volcar la base de datos?

Podría sugerir fácilmente cambiar la configuración de InnoDB, que podría ser un poco difícil para que un mysqldump funcione. Es posible que no le guste lo que soy sobre la sugerencia, pero creo que es su mejor (única) opción. Aquí va:

SUGERENCIA # 1: Deshabilitar insertos extendidos

La configuración predeterminada para mysqldump incluiría agrupar cientos o miles de filas en un solo INSERT. Esto se conoce como INSERTAR extendido. Está causando un desbordamiento más allá de max_allowed_packet .

Respondí una publicación nuevamente Sep 01, 2011(el servidor MySQL se ha ido obstruyendo la importación de volcados grandes ) donde discutí hacer lo mismo para importar un mysqldump grande. Creo que deshabilitar INSERT extendido también ayudaría a crear un mysqldump problemático.

mysqldump -u root --skip-extended-insert -p maia > maia.sql

Malas noticias: lo que esto hace al crear un comando INSERT para cada fila. Esto definitivamente aumentará el tiempo que lleva realizar mysqldump. En consecuencia, también aumentará el tiempo que se tarda en recargar (probablemente por un factor de 10-100.

He discutido skip-extended-insertantes

• Aug 12, 2011: ¿Por qué el archivo mysqldump es tan grande?
• Aug 09, 2013: Copia de seguridad / Exportar datos de la tabla de archivos adjuntos de MySQL 5.5 sigue fallando.
• Nov 16, 2014: ¿Cómo agrupar varias instrucciones de inserción para el volcado de la base de datos con MySQL?

SUGERENCIA # 2: volcar datos binarios como hexadecimales (OPCIONAL)

Para hacer que los datos binarios de mysqldump sean más portátiles, descargue dichos datos en hexadecimal

mysqldump -u root --skip-extended-insert --hex-blob -p maia > maia.sql

Malas noticias: hinchará un poco más el mysqldump

DARLE UNA OPORTUNIDAD !!!

Nota al margen : el tamaño máximo de max_allowed_packet es 1G

También recibí el mismo error al intentar volcar la base de datos de 12 GB. Hice los siguientes cambios para que funcione.

1. configurado max_allowed_packet a 1024M
2. configurado net_read_timeout a 7200
3. configuró net_write_timeout a 7200

Nota: Sé que los valores de tiempo de espera son demasiado altos (7200 segundos, es decir, 20 horas). Pero lo hice de manera iterativa solo para descartar cualquier posibilidad. Estoy en el proceso de encontrar un valor de tiempo de espera óptimo.

Simplemente incluya lo siguiente en su archivo de configuración my.ini (Windows) o my.cnf (Linux).

[mysqld]
max_allowed_packet=1024M 

[mysqldump]
max_allowed_packet=1024M 
net_read_timeout=3600 
net_write_timeout=3600

Asegúrese de tener suficiente memoria para realizar el volcado. Siga revisando la memoria mientras realiza el volcado, por ejemplo, utilizando un comando como este:

free -mt

Si se agota la memoria mientras se descarga, obtendrá

mysqldump: Error 2013: Conexión perdida

Encontré:

--max-allowed-packet=1G --net-buffer-length=32704

... lo hace funcionar donde no lo hacía (de manera confiable) anteriormente, a pesar de los cambios de tiempo de espera de lectura / escritura neta, TCP keepalives, etc.

La max_allowed_packetconfiguración por sí sola no lo hizo funcionar, por lo que puede no ser necesario si net_buffer_lengthse usa. - ralph-bolton

Modifica max-allowed-packety net-buffer-lengthparece mucho mejor que deshabilitar insertos extendidos - kristofer

Vea también ¿Qué max_allowed_packet es lo suficientemente grande y por qué necesito cambiarlo?