Tablas MySQL Corruptas — Recuperación con innodb_force

Cuando MySQL no arranca

Reinicias MySQL y el servicio rehúsa subir. El log de error muestra:

InnoDB: Database page corruption on disk or a failed file read of page X
InnoDB: Cannot continue operation

WordPress está muerto. Cada petición expira o muestra "Error establishing database connection." Este es el peor momento en recuperación WordPress.

La buena noticia: en la mayoría de casos, los datos son recuperables. El procedimiento es innodb_force_recovery, escalado nivel por nivel.

Etapa 1 — Confirma que la corrupción es la causa

systemctl status mysql
tail -100 /var/log/mysql/error.log

Busca mensajes InnoDB. Patrones comunes:

Database page corruption on disk — páginas están dañadas
Page lsn X but it should be Y — números de secuencia de log no coinciden
Cannot find the appropriate table to look up — inconsistencia de diccionario de datos

Estos todos indican corrupción InnoDB. Procede con innodb_force_recovery.

Los niveles de recuperación

InnoDB tiene 6 niveles de recuperación escalonados (1-6). Cada nivel subsiguiente es más invasivo pero permite que MySQL arranque en más estados rotos.

Edita /etc/mysql/my.cnf (o /etc/my.cnf según el OS):

[mysqld]
innodb_force_recovery = 1

Reinicia MySQL:

systemctl start mysql

Si MySQL arranca, puedes conectarte. Si no, sube a 2, después 3, etc., hasta 6.

Qué hace cada nivel

Nivel 1 (SRV_FORCE_IGNORE_CORRUPT): deja al servidor correr incluso si detecta página corrupta. Operaciones de solo-lectura posibles.

Nivel 2 (SRV_FORCE_NO_BACKGROUND): previene que el master thread corra. Salta operaciones de purgado.

Nivel 3 (SRV_FORCE_NO_TRX_UNDO): no corre rollback de transacciones. Estado inconsistente posible.

Nivel 4 (SRV_FORCE_NO_IBUF_MERGE): previene operaciones de merge de insert buffer.

Nivel 5 (SRV_FORCE_NO_UNDO_LOG_SCAN): no mira undo logs en absoluto. Trata transacciones incompletas como committed.

Nivel 6 (SRV_FORCE_NO_LOG_REDO): no aplica redo logs. El más destructivo — datos después del último checkpoint se pierden.

Para recuperación WordPress, casi siempre quieres el nivel MÁS BAJO que permita a MySQL arrancar. Niveles más altos = más pérdida de datos.

El procedimiento de recuperación

Paso 1 — Intenta nivel 1

innodb_force_recovery = 1

Reinicia. Si MySQL arranca, salta al Paso 4.

Paso 2 — Escala si es necesario

Si nivel 1 falla, intenta 2, después 3, después 4. Tras cada uno:

systemctl start mysql

Detente en el primer nivel que permita arrancar.

Paso 3 — En nivel 5 o 6, espera pérdida de datos

Niveles 5 y 6 significan que algunos datos recientes se pierden. Acepta esto y procede.

Paso 4 — Verifica qué datos están intactos

mysql -u root -p

USE your_wp_database;
SELECT COUNT(*) FROM wp_posts;
SELECT COUNT(*) FROM wp_users;
SELECT MAX(post_date) FROM wp_posts WHERE post_status = 'publish';

Si los conteos se ven razonables y la fecha más reciente de post es reciente, tienes la mayoría de tus datos.

Paso 5 — Exporta TODOS los datos inmediatamente

mysqldump --single-transaction --quick --lock-tables=false \
  --no-tablespaces \
  your_wp_database > /backup/recovery-dump.sql

Esto es crítico: debes exportar todo antes de hacer cualquier otra cosa. El estado MySQL actual es frágil.

Paso 6 — Detén MySQL, borra archivos de datos corruptos

systemctl stop mysql
cp -a /var/lib/mysql /var/lib/mysql.broken.$(date +%Y%m%d)
rm -rf /var/lib/mysql/your_wp_database

Paso 7 — Remueve innodb_force_recovery y reinicia

# innodb_force_recovery = 1   ← comenta esto

systemctl start mysql

MySQL debería arrancar limpiamente ahora (no más corrupción ya que el dir de datos se fue).

Paso 8 — Recrea la base de datos, importa dump

CREATE DATABASE your_wp_database;

mysql your_wp_database < /backup/recovery-dump.sql

Paso 9 — Prueba WordPress

cd /var/www/yoursite
wp option get siteurl
wp post list --posts_per_page=5

Si las queries devuelven datos, WordPress está de vuelta.

Por qué esto funciona

La corrupción está en las estructuras internas de datos InnoDB, no en tus datos crudos de fila. innodb_force_recovery te permite bypasear suficiente lógica interna para leer las filas. Dumpearlas te da un archivo SQL limpio. Importarlo a una base de datos fresca recrea todo limpiamente.

Los datos son los mismos; solo el formato de almacenamiento se reconstruye.

Qué datos pueden perderse

En niveles 1-3: típicamente nada. En nivel 4: los merges de insert buffer pueden no haber pasado. En nivel 5: las transacciones incompletas no son revertidas. En nivel 6: los cambios desde el último checkpoint se pierden — típicamente los últimos 30-60 minutos.

Para WordPress, los datos más probables de perderse son: - Últimas pocas órdenes (WooCommerce) - Comentarios posteados en la última hora - Entradas de log más recientes

Previniendo corrupción futura

Tras recuperación, configura MySQL para resiliencia:

[mysqld]
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
innodb_doublewrite = ON
innodb_file_per_table = 1
innodb_flush_method = O_DIRECT

Configura monitoreo:

# Check de integridad diario
0 3 * * * mysqlcheck --check --all-databases --silent > /var/log/mysqlcheck.log 2>&1

Y backups REALES:

Backups binarios: mariabackup o xtrabackup para recuperación point-in-time rápida
Copias fuera del sitio: rsync a un servidor separado o S3 nocturnamente
Simulacros de restauración: prueba mensual de que realmente puedes restaurar

Errores comunes durante recuperación de corrupción MySQL

Reiniciar MySQL repetidamente sin cambiar config — no ayuda; la corrupción persiste
Ir directo al nivel 6 — pierde más datos del necesario; siempre empieza en 1
No exportar antes de destruir datos — una vez borres /var/lib/mysql/<db>, esos datos se fueron si el dump falló
Remover innodb_force_recovery antes de exportar — MySQL vuelve a rehusar arrancar

Cuándo llamar a un especialista

La recuperación InnoDB es de alto riesgo. Un paso equivocado en el nivel equivocado puede perder datos permanentemente. Hemos recuperado cientos de bases de datos WordPress corruptas sin pérdida de datos.

Emergencia recuperación base de datos en horas. Para recuperación más amplia ve soporte de emergencia.