mysqldump bloquea las tablas por defecto para que el volcado sea coherente. En una base pequeña tarda un segundo. En una grande el sitio se congela durante minutos, y la copia nocturna se convierte en una caída nocturna.

La opción

mysqldump --single-transaction --quick --routines --triggers \
          --default-character-set=utf8mb4 shop | gzip > shop.sql.gz

--single-transaction toma una instantánea coherente usando el versionado propio de InnoDB: lectores y escritores siguen adelante y el volcado ve igualmente un único instante.

Sus dos condiciones

  • Solo InnoDB. Una tabla MyISAM en la misma base se vuelca sin esa garantía. Conviértelas: ALTER TABLE t ENGINE=InnoDB;
  • Nada de cambios de esquema durante el volcado. Un ALTER TABLE mientras corre puede romperlo: no ejecutes migraciones y copias a la vez.

Si la base es grande

# dump from a replica instead of production
mysqldump --single-transaction -h replica.internal shop | gzip > shop.sql.gz

# or use a physical tool
xtrabackup --backup --target-dir=/srv/backup/full

Una réplica quita del todo la carga a la base en producción. Las herramientas físicas copian los archivos en vez de generar SQL, lo que se restaura mucho más rápido a partir de unas decenas de gigabytes.

Vigila lo que cuesta mientras corre

mysql -e "SHOW PROCESSLIST" | head -20
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -A5 "TRANSACTIONS"
Un volcado largo con --single-transaction obliga a InnoDB a conservar versiones antiguas de las filas durante toda su duración, así que el registro de deshacer crece. Está bien durante minutos y es un problema durante horas, y ese es el punto en que la respuesta es una réplica o una copia física.

Qué comprobar en el archivo terminado está en Volcados que sí se restauran.