¿Avisos de tablas 'crashed', ' server has gone away' o fallos parciales en WordPress en producción? Un responsable técnico con acceso al servidor o al hosting debe minimizar pérdida de datos y tiempo de inactividad mediante un protocolo seguro de diagnóstico y recuperación que preserve AUTO_INCREMENT, claves foráneas y la replicación.
Errores / tablas corruptas: se procede así: primero realizar una copia de seguridad completa (archivos + binlogs), a continuación diagnosticar con CHECK TABLE/mysqlcheck y usar REPAIR TABLE o myisamchk para MyISAM; para InnoDB aplicar innodb_force_recovery y exportar con mysqldump antes de restaurar. Para tablas grandes o replicación, emplear binlogs/PITR y contactar al soporte si falta acceso.
Resumen del proceso
Sigue estos pasos para recuperar sin pérdidas evitables:
- Copia completa y binlogs
- Diagnosticar con CHECK TABLE/mysqlcheck
- Reparar MyISAM o usar innodb_force_recovery para InnoDB y exportar
- Restaurar con mysqldump o aplicar binlogs
Notas rápidas para ejecución:
- Haz copia de seguridad completa de archivos, base y binlogs antes de tocar nada.
- Identifica motor y tablas con CHECK TABLE o mysqlcheck para decidir la vía.
- Si es MyISAM, realiza reparación preferiblemente en snapshot o mysqld detenido.
- Si es InnoDB, sube innodb_force_recovery de forma incremental y exporta inmediatamente con mysqldump.
Paso 1: detectar y diagnosticar
Identifica qué tablas fallan y su motor. Este paso determina la vía de recuperación.
Comprobar estado rápido
Ejecuta comandos básicos para ver Engine y errores.
- mysql -u root -p -e "SHOW TABLE STATUS FROM nombre_db/G"
- mysql -u root -p -e "CHECK TABLE nombre_db.nombre_tabla EXTENDED"
- mysqlcheck -c -u root -p nombre_db nombre_tabla
Diagnóstico masivo y scripts
Para auditar toda la base usa un pequeño script por consola.
-
mysql -N -e "SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='nombre_db'" | while read db tbl eng; do mysql -u root -p -e "CHECK TABLE `$db`.`$tbl`"; done
-
Usar CHECKSUM TABLE para detectar diferencias de réplica.
1. SnapshotCopia disco y binlogs
→
2. DiagnósticoCHECK TABLE / mysqlcheck
→
3. Acciónmyisamchk o innodb_force_recovery
→
4. Exportarmysqldump --single-transaction
Paso 2: reparar MyISAM en producción
Usa REPAIR TABLE o myisamchk según si la instancia está en ejecución. La elección afecta riesgo y downtime.
Comandos y flags recomendados
Si puedes detener mysqld, usa myisamchk offline.
- service mysql stop
- cp -a /var/lib/mysql/nombre_db/.MYI /var/lib/mysql/nombre_db/.MYD /var/lib/mysql/nombre_db/*.frm /backup/ # o mejor: crear un snapshot LVM o rsync -a /var/lib/mysql /backup para garantizar que se copian índices (.MYI), datos (.MYD) y definiciones (.frm); detener mysqld o usar snapshot coherente antes de copiar.
- myisamchk --recover --safe-recover --force -v /var/lib/mysql/nombre_db/*.MYI
Si no puedes parar MySQL, usa mysqlcheck menos agresivo.
- mysqlcheck -r -u root -p nombre_db nombre_tabla
Riesgos y preservación de datos
Copia siempre .MYI y .MYD antes de intentar reparaciones.
Un caso habitual: se intenta myisamchk en caliente y la tabla queda peor. Evita ese error.
Una comparativa práctica ayuda a elegir la vía de reparación:
- REPAIR TABLE / myisamchk son herramientas diseñadas para MyISAM y suelen ser rápidas para reparaciones de índices o corrupción leve, pero pueden truncar registros, reindexar y provocar pérdida parcial si el daño es importante.
- Además, myisamchk debe ejecutarse sobre archivos consistentes (snapshot o mysqld parado). Por el contrario, mysqldump + restore es la opción más segura para InnoDB y para escenarios donde se debe preservar integridad referencial, AUTO_INCREMENT y routines: exportar desde un servidor sano y reaplicar binlogs (PITR) garantiza restaurar transacciones recientes.
- En tablas muy grandes la alternativa es dumpear por rangos o tabla por tabla y usar herramientas online (pt-online-schema-change) para minimizar downtime.
En resumen: MyISAM leve → REPAIR/myisamchk (offline preferible); daño serio o InnoDB → dump + restauración y aplicar binlogs.
Paso 3: reparar InnoDB y exportar seguro
No usar REPAIR TABLE para InnoDB. Sigue innodb_force_recovery para desbloquear SELECT y exportar.
Innodb_force_recovery niveles
Edita my.cnf y añade innodb_force_recovery=1. Reinicia MySQL.
Sube niveles secuencialmente 1→2→3→4→5→6 solo si la exportación falla. Los niveles altos permiten menos operaciones.
Lo que omiten la mayoría de guías es este punto: subir directo a 4 suele empeorar la recuperación. Empieza por 1 y sube solo si hace falta.
Exportar e importar preservando FK
Exporta con opciones que conserven rutinas y triggers.
- mysqldump --quick --skip-add-locks --routines --triggers --events -u root -p nombre_db > dump.sql # cuando uses innodb_force_recovery evita --single-transaction, ya que los niveles de recovery pueden impedir garantías transaccionales; si el volcado falla, exporta tabla por tabla con --where o usa SELECT INTO OUTFILE para tablas concretas y reconstruye en un servidor limpio.
Si mysqldump falla, exporta tabla por tabla con --where.
Al importar aplica:
- mysql -u root -p -e "SET FOREIGN_KEY_CHECKS=0;"
- mysql -u root -p nombre_db < dump.sql
- mysql -u root -p -e "SET FOREIGN_KEY_CHECKS=1;"
Comprueba AUTO_INCREMENT con SHOW TABLE STATUS LIKE 'nombre_tabla'; y ajusta con ALTER TABLE si hace falta.
La recomendación práctica: funciona bien solo si se exporta inmediatamente tras permitir SELECT. Subir niveles sin dump incrementa la probabilidad de pérdida.
Para recuperaciones avanzadas de InnoDB con innodb_force_recovery conviene seguir una secuencia reproducible:
- Primero generar un snapshot del datadir (o detener mysqld y copiar /var/lib/mysql con rsync -a) y asegurar las copias de los ibdata/ib_logfiles antes de tocar parámetros.
- Edita my.cnf añadiendo innodb_force_recovery=1, reinicia MySQL y trata de volcar con mysqldump sin --single-transaction: mysqldump --quick --skip-add-locks --routines --triggers --events -u root -p nombre_db > dump.sql
- Si falla, sube secuencialmente el valor a 2, 3, etc. No saltes directamente a 4–6: esos niveles permiten SELECT pero deshabilitan tareas internas y pueden agravar la inconsistencia.
- Si mysqldump sigue fallando, exporta tabla a tabla (--where) o usa SELECT INTO OUTFILE para tablas concretas, y conserva los archivos ibdata/ib_logfiles y el error.log para análisis. Ejemplo de snippet en my.cnf: [mysqld] innodb_force_recovery=3 # aumentar solo si es necesario
- Reinicia entre cambios de nivel y documenta cada paso.
Tras volcar, restaura en un servidor limpio y reajusta AUTO_INCREMENT y FOREIGN_KEY_CHECKS según corresponda.
Paso 4: restaurar con binlogs y replicación
Aplica binlogs sobre una copia base para recuperar hasta antes del fallo. Esto evita perder transacciones recientes.
Workflow básico PITR
Haz backup base y anota posición binlog.
- mysqldump --single-transaction -u root -p nombre_db > base.sql
- mysql -u root -p -e "SHOW MASTER STATUS;"
Aplica binlogs:
- mysqlbinlog --start-position=X --stop-position=Y binlog.00000n | mysql -u root -p
- O usar --stop-datetime="YYYY-MM-DD hh:mm:ss"
Consideraciones en réplica
Detén esclavos antes de manipular binlogs: STOP SLAVE;
Si el master está corrupto, promover un slave sano suele ser la vía más rápida.
Si trabajas con Galera o Group Replication sigue el procedimiento oficial de rejoin para evitar split-brain.
En entornos con replicación o clústeres hay que actuar con cautela:
- Antes de cualquier reparación captura SHOW MASTER STATUS y SHOW SLAVE STATUS/G en master y esclavos, y guarda los binlogs.
- Si el master está corrupto y hay slaves sanos, la vía más segura suele ser promover un slave (quitar read_only, apuntar la aplicación al slave y luego reconfigurar los demás esclavos hacia el nuevo master usando CHANGE MASTER TO con MASTER_LOG_FILE y MASTER_LOG_POS, o MASTER_AUTO_POSITION=1 si usas GTID). No uses --skip-slave-start a ciegas: documenta la posición exacta para evitar duplicados.
- En configuraciones Galera/Group Replication utiliza wsrep_recover en el nodo afectado para obtener la última seqno y decide entre IST (incremental) o SST (full state transfer) según el daño.
- Evita el rejoin manual que pueda causar split-brain y coordina SST con el proveedor del clúster.
Toda acción sobre replicación debe acompañarse de logs y binlogs para poder reproducir PITR y conservar consistencia entre AUTO_INCREMENT y claves foráneas.
Paso 5: tablas grandes y entornos sin phpMyAdmin
Para tablas enormes trabaja por rangos o replica temporal. Evita mysqldump completo en producción cuando el tamaño supera decenas de GB.
Manejo de tablas gigantes
Divide exportación por rangos de ID para reducir memoria y bloqueo.
- mysqldump --where="ID BETWEEN X AND Y" --single-transaction --skip-lock-tables -u root -p nombre_db nombre_tabla > part.sql
Usa pt-online-schema-change para cambios sin downtime cuando sea posible.
Resincro y reparación en réplica
Si la tabla corrupta está en el slave, reconstruye solo esa tabla desde el master.
- STOP SLAVE; DROP TABLE nombre; restaurar tabla desde dump del master; START SLAVE;
Si el master está corrupto y tienes slaves sanos, promover un slave reduce downtime.
Checklist, matriz y scripts
Sigue esta checklist antes de decidir la vía de reparación. Te ahorrará tiempo y pérdidas.
Checklist de emergencia
- Captura /var/log/mysql/error.log.
- Hacer snapshot LVM o copiar /var/lib/mysql y binlogs.
- Ejecutar SHOW MASTER STATUS y SHOW SLAVE STATUS/G.
- Identificar motor en information_schema.TABLES.
- CHECK TABLE y mysqlcheck.
- Si MyISAM: snapshot y myisamchk. Si InnoDB: innodb_force_recovery + dump.
- Restaurar en staging y validar collation y FK.
Matriz de decisión
| Situación | Motor | Acción | Downtime |
|---|
| Tabla marcada como crashed | MyISAM | myisamchk offline o REPAIR TABLE | Bajo-med |
| InnoDB con errores de undo | InnoDB | innodb_force_recovery + mysqldump | Medio |
| Pérdida de transacciones recientes | InnoDB | Backup base + aplicar binlogs (PITR) | Medio-alto |
Si necesita intervención inmediata por un incidente activo, solicite al hosting el volcado binlog y los logs de error para análisis y coordinación.
Preguntas frecuentes
¿Cómo reparar una tabla MySQL corrupta?
Para MyISAM usa REPAIR TABLE o myisamchk en offline. Para InnoDB no usar REPAIR.
Si la tabla es MyISAM detén mysqld y ejecuta myisamchk en copia. Si es InnoDB activa innodb_force_recovery para permitir SELECT y exporta con mysqldump. Restaurar desde backup+binlogs evita pérdida de transacciones.
¿Cómo saber si una tabla está corrupta?
Ejecuta CHECK TABLE y mysqlcheck para obtener el estado.
Revisa /var/log/mysql/error.log por entradas como "marked as crashed" o mensajes InnoDB. También usa CHECKSUM TABLE y compara con la réplica para detectar inconsistencias.
¿Se puede recuperar sin copia de seguridad?
A veces es posible, pero con riesgo alto.
MyISAM puede repararse localmente si el daño es leve. InnoDB requiere innodb_force_recovery para exportar. Sin binlogs o backups completos puede perderse información reciente.
¿Qué causa corrupción de tablas en WordPress?
Cortes de energía, discos con errores y operaciones directas en archivos.
Plugins que manipulan tablas, backups mal hechos y bugs en el motor de base de datos generan corrupción. Hosting con IO inestable incrementa el riesgo.
¿Debo usar REPAIR TABLE siempre?
No. REPAIR TABLE funciona solo en MyISAM.
Intentar REPAIR en InnoDB no corrige archivos ibdata ni tablas InnoDB. Para InnoDB sigue el flujo de innodb_force_recovery y exportación.
¿Cómo conservar AUTO_INCREMENT y claves foráneas?
Exporta con mysqldump incluyendo triggers y routines.
Usa --routines --triggers y al importar desactiva temporalmente FOREIGN_KEY_CHECKS. Verifica SHOW TABLE STATUS para ajustar AUTO_INCREMENT tras la importación.
Recursos y cumplimiento
Herramientas y referencias clave
Lista de utilidades a mano: mysqlcheck, myisamchk, mysqldump, mysqlbinlog, Percona XtraBackup, pt‑toolkit y WP-CLI.
Para documentación oficial consulta la guía de MySQL: MySQL Documentation. Percona publica guías prácticas desde hace años que ayudan en la recuperación.
Consideraciones legales y seguridad
Trata los dumps como datos personales según RGPD y LOPDGDD.
Cifra archivos en tránsito y en reposo. Registra quién accede a los dumps por auditoría ENS/PCI DSS.
⚠️ Si no controlas el acceso al servidor o no puedes obtener binlogs, no ejecutes reparaciones manuales. Contacta soporte del hosting y aporta los logs.
