Recupera WP segura: soluciona errores MySQL y tablas dañadas

¿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:

1. Copia completa y binlogs
2. Diagnosticar con CHECK TABLE/mysqlcheck
3. Reparar MyISAM o usar innodb_force_recovery para InnoDB y exportar
4. Restaurar con mysqldump o aplicar binlogs

Notas rápidas para ejecución:

1. Haz copia de seguridad completa de archivos, base y binlogs antes de tocar nada.
2. Identifica motor y tablas con CHECK TABLE o mysqlcheck para decidir la vía.
3. Si es MyISAM, realiza reparación preferiblemente en snapshot o mysqld detenido.
4. 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.

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

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.

• Recupera WordPress tras actualizaciones fallidas de plugins
• Asegura backups PCI-DSS y pasa auditorías

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.