En el mundo de la administración de bases de datos, pocas cosas generan más frustración que un volcado que falla cuando parecía estar todo bajo control. Ese es el caso del temido Error 2013: Lost connection to MySQL server during query when dumping table, que aparece tanto en mysqldump como en mariadb-dump.
El mensaje suele ser lapidario:
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table XXXX at row NLenguaje del código: JavaScript (javascript)o en la variante de MariaDB:
mariadb-dump: Error 2013: Lost connection to MySQL server during query when dumping table XXXX at row NLenguaje del código: JavaScript (javascript)Detrás de esta advertencia hay un problema técnico concreto: la herramienta pierde la conexión con el servidor MySQL o MariaDB mientras intenta extraer datos de una tabla demasiado grande o con registros muy pesados. No es un error raro, y suele presentarse en entornos donde existen tablas con millones de filas, campos BLOB/TEXT voluminosos, o cuando el servidor y el cliente tienen límites demasiado restrictivos en memoria y tiempos de espera.
Lo positivo es que la comunidad ha identificado desde hace años soluciones prácticas. Este artículo reúne esas medidas en formato de guía útil, explicada con lenguaje accesible, para que cualquier profesional o responsable de sistemas pueda afrontarlo con garantías.
¿Por qué aparece el error 2013?
El código de error 2013 corresponde a una pérdida de conexión entre el cliente que ejecuta mysqldump (o mariadb-dump) y el servidor MySQL/MariaDB. Normalmente ocurre en tres escenarios:
- Filas demasiado grandes: si una consulta devuelve un registro cuyo tamaño supera el valor permitido por la variable
max_allowed_packet, la conexión se corta. - Tiempos de espera agotados: conexiones lentas o volcados muy largos pueden hacer que los timeouts de lectura o escritura expiren.
- Problemas de red o de infraestructura: firewalls, balanceadores o pérdidas de conexión en entornos distribuidos pueden interrumpir un volcado masivo.
Aunque a veces el mensaje indica la fila exacta en la que se interrumpió, no siempre significa que esa fila esté “corrupta”; lo que suele fallar es la configuración de límites de MySQL o MariaDB.
Primer paso: ajustar max_allowed_packet
El ajuste más inmediato y habitual es aumentar el tamaño máximo de los paquetes permitidos en la comunicación cliente-servidor. Por defecto, este valor puede ser demasiado bajo para operaciones que manejan datos binarios grandes o sentencias SQL extensas.
En el cliente, basta con ejecutar:
$ mysqldump --opt --max_allowed_packet=1G base_de_datos > bd.sqlEl sufijo admite valores en K, M o G, es decir, kilobytes, megabytes o gigabytes. Un valor de 1G suele ser más que suficiente en la mayoría de entornos.
Del lado del servidor, también conviene verificar el valor actual:
SHOW VARIABLES LIKE 'max_allowed_packet';Lenguaje del código: JavaScript (javascript)Y, si fuera necesario, ampliarlo temporalmente:
SET GLOBAL max_allowed_packet = 1073741824; -- 1GLenguaje del código: PHP (php)Para hacerlo persistente, habría que modificar el archivo de configuración my.cnf o my.ini:
[mysqld]
max_allowed_packet = 1GEl poder de --quick y --single-transaction
Otra medida fundamental consiste en optimizar el modo en que mysqldump gestiona las consultas. Dos opciones muy recomendadas son:
--quick: hace que las filas se lean y escriban una a una, en lugar de cargar toda la tabla en memoria.--single-transaction: inicia una transacción consistente para motores InnoDB, lo que evita bloqueos y permite obtener un snapshot fiable de la base de datos sin detener la actividad.
Ejemplo práctico:
mysqldump --single-transaction --quick --max_allowed_packet=512M nombre_bd > backup.sqlCon este simple cambio, muchos administradores logran evitar los cuelgues derivados de bases de datos con gigabytes de información.
Evitar inserciones extendidas demasiado grandes
Por defecto, mysqldump genera sentencias de inserción extendidas, donde mete muchas filas en un solo INSERT. Eso es eficiente para restaurar, pero también puede crear sentencias de cientos de megabytes que superen el límite de los paquetes.
La opción --skip-extended-insert obliga a que cada fila se escriba como un INSERT independiente. El fichero resultante será mayor y la importación algo más lenta, pero reducirá drásticamente el riesgo de superar max_allowed_packet.
Ejemplo:
mysqldump --single-transaction --quick --skip-extended-insert nombre_bd > backup.sqlLenguaje del código: CSS (css)Aumentar los tiempos de espera
Si la causa es el agotamiento de los timeouts de red, hay que revisar las variables net_read_timeout y net_write_timeout. En servidores con operaciones de gran volumen, un valor bajo puede interrumpir conexiones válidas.
Ver los valores actuales:
SHOW VARIABLES LIKE 'net_read_timeout';
SHOW VARIABLES LIKE 'net_write_timeout';Lenguaje del código: JavaScript (javascript)Aumentarlos en caliente:
SET GLOBAL net_read_timeout = 600;
SET GLOBAL net_write_timeout = 600;Lenguaje del código: PHP (php)Eso da un margen de 10 minutos a operaciones que antes podían interrumpirse en apenas 30 segundos.
Volcar tablas grandes en partes
Cuando el error se produce siempre en la misma tabla, lo más práctico es dividir el volcado por rangos de filas, usando la opción --where. Esto exige que la tabla tenga una clave primaria o un campo de referencia claro.
Ejemplo:
mysqldump nombre_bd tabla_grande --where="id BETWEEN 1 AND 100000" > parte1.sql
mysqldump nombre_bd tabla_grande --where="id BETWEEN 100001 AND 200000" >> parte1.sqlLenguaje del código: JavaScript (javascript)De esta forma, se evita que una sola sentencia intente procesar millones de registros de golpe.
Usar mysqlpump o paralelismo en MariaDB
Para quienes trabajen con MySQL en versiones más recientes, existe la herramienta mysqlpump, que soporta paralelismo y compresión nativa, además de mejorar la gestión de paquetes grandes. En MariaDB, el propio mariadb-dump incluye la opción --parallel para procesar varias tablas a la vez.
Ejemplo con MySQL:
mysqlpump --default-parallelism=4 --compress-output=GZIP nombre_bd > backup.sql.gzLenguaje del código: JavaScript (javascript)Ejemplo con MariaDB:
mariadb-dump --single-transaction --quick --parallel=4 nombre_bd > backup.sqlBuenas prácticas para prevenir el error
Más allá de los parámetros técnicos, existen rutinas que pueden ayudar a minimizar la aparición del error 2013:
- Hacer pruebas en staging: antes de volcar una base de datos de producción, probar en entornos de prueba.
- Monitorizar recursos: revisar consumo de memoria y CPU durante los volcados para detectar cuellos de botella.
- Comprimir al vuelo: usar
gzipoxzpara reducir el tamaño de salida y evitar escrituras excesivas en disco. - Evitar horas punta: planificar los backups en horarios de menor carga reduce la probabilidad de conflictos.
Conclusión
El error 2013 en mysqldump y mariadb-dump es un viejo conocido de los administradores de bases de datos. Aunque su aparición genera nerviosismo, la buena noticia es que se trata de un problema documentado y con múltiples soluciones al alcance.
Desde ampliar max_allowed_packet, pasando por ajustar --quick y --single-transaction, hasta dividir las tablas más problemáticas o recurrir a herramientas más modernas como mysqlpump, las alternativas son variadas. Lo esencial es diagnosticar si la causa está en el tamaño de los registros, en los límites de memoria o en los timeouts de conexión.
En un momento en el que las bases de datos son el corazón de los servicios digitales, disponer de copias de seguridad fiables no es opcional: es un requisito crítico para garantizar la continuidad de negocio. Y conocer cómo sortear errores como este convierte a cualquier administrador en un recurso invaluable dentro de su organización.
Preguntas frecuentes (FAQ)
1. ¿Qué significa exactamente el error 2013 en MySQL?
Es un error que indica que el cliente perdió la conexión con el servidor durante la ejecución de una consulta, en este caso durante un volcado de base de datos con mysqldump o mariadb-dump.
2. ¿Cuál es el valor recomendado para max_allowed_packet?
Depende del tamaño de las filas de tu base de datos. Para entornos estándar, 256M suele ser suficiente. En casos con BLOBs o tablas masivas, puede ser necesario aumentar hasta 512M o incluso 1G.
3. ¿Puedo hacer un volcado completo sin bloquear las tablas?
Sí, usando la opción --single-transaction en bases de datos con motor InnoDB, lo que permite un snapshot consistente sin necesidad de bloquear las tablas.
4. ¿Qué hacer si el error se repite siempre en la misma tabla?
Conviene dividir el volcado de esa tabla en partes usando la opción --where, para evitar que se procesen millones de filas en una sola operación.
