error de mysqldump 2013

18

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?

Garfink
fuente
170GB de espacio libre. También es lo mismo si volcado a la máquina db está
activado
copias de correo electrónico, por lo que los datos varchar principalmente
garfink
el 1300M fue un cambio reciente, el problema existía cuando también se configuró en el predeterminado 16M. El servidor también se reinició después del cambio a 1300M.
garfink
Volví al valor predeterminado de 16M. resultados de volcado en el mismo error 2013 en la fila 15
garfink

Respuestas:

13

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

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

RolandoMySQLDBA
fuente
5

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.

gadha real
fuente
2
Para otros usuarios: estos se configuran en el servidor, no en el archivo de configuración mysqldump. Además, 7200 segundos son 2 horas, no 20.
Marque el
establecer global net_read_timeout = 120; establecer global net_write_timeout = 900; funcionó para mí
kasi
2

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
Jesus Uzcanga
fuente
2
Las secciones deben ser al revés.
OrangeDog
1

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

Ranjeet Ranjan
fuente
1

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?

usuario126897
fuente