WordPress “Database Needs Repair”: qué significa y cómo arreglarlo de forma segura

Qué está diciendo WordPress en realidad

WordPress muestra “database needs repair” cuando cree que una o más tablas están dañadas o inconsistentes hasta el punto de que las consultas normales están fallando. El desencadenante inmediato suele ser un error devuelto por MySQL/MariaDB durante el arranque o durante una consulta rutinaria: una tabla marcada como crashed, un índice faltante, una página corrupta, un EOF inesperado o una discrepancia entre lo que WordPress espera y lo que puede leer.

Internamente, WordPress usa una pequeña comprobación en su capa de base de datos y, si detecta ciertos fallos, sugiere un flujo de reparación
usando un script incorporado (wp-admin/maint/repair.php). Esto puede ejecutar operaciones SQL como REPAIR TABLE y
OPTIMIZE TABLE—lo cual está bien para algunos motores de almacenamiento y casi irrelevante para otros.

Aquí está la verdad operativa clave: WordPress puede detectar que la base de datos está mal, pero no puede diagnosticar si tienes
corrupción lógica (datos malos), corrupción física (páginas rotas en disco) o problemas de disponibilidad
(timeouts, disco lleno, bucles de recuperación tras crash). Debes determinar cuál de estas estás enfrentando.

Una buena frase para tener en mente durante incidentes: “La esperanza no es una estrategia.” — Vince Lombardi. Es directa, pero encaja.

Guía de diagnóstico rápido (primero/segundo/tercero)

Cuando el sitio está caído, no tienes tiempo para admirar las ruinas. Necesitas identificar el cuello de botella rápidamente: salud del motor de BD,
daño a nivel de tabla o el almacenamiento subyacente.

Primero: confirma que no es solo un problema de conectividad o credenciales

• Revisa los registros del servidor web por fallos de mysqli_real_connect, errores de autenticación, problemas de resolución DNS,
  o Too many connections.
• Confirma que DB_NAME, DB_USER, DB_PASSWORD, DB_HOST en wp-config.php
  coinciden con la realidad (y no fueron rotados sin avisar a WordPress).
• Prueba un ping simple a la BD desde el host de WordPress. Si no puedes conectar, la “reparación” ni siquiera comenzará.

Segundo: revisa los logs de la base de datos para la queja real

• Busca mensajes de recuperación tras crash, advertencias de corrupción InnoDB, “table is marked as crashed”, “page checksum mismatch” o “disk full”.
• Si InnoDB está en un bucle de recuperación tras crash, no reinicies en exceso. Puedes cavar el agujero más profundo.

Tercero: establece si el almacenamiento subyacente te está mintiendo

• Comprueba espacio en disco y agotamiento de inodos. Un “repair needed” a veces es “no pudimos escribir la última transacción”.
• Revisa los logs del kernel por errores de I/O, remounts del sistema de ficheros, degradación de RAID o un volumen en cloud con problemas.
• Si la capa de almacenamiento es inestable, reparar tablas es como repintar una casa mientras está en llamas.

Datos y contexto interesantes (lo que importa)

1. Históricamente WordPress apoyaba mucho MyISAM; las instalaciones modernas suelen correr en InnoDB por defecto en MySQL/MariaDB.
   Eso importa porque “repair” es un concepto centrado en MyISAM.
2. El script de reparación incorporado a WordPress es anterior a la era en que los hosts gestionados hicieron el acceso a BD “problema de otro” —y asume que puedes ejecutar operaciones de reparación desde la capa de aplicación.
3. InnoDB usa un redo log y recuperación tras crash; después de una pérdida de energía, a menudo se autocorrige sin reparaciones a nivel de tabla, si el disco está bien.
4. Las tablas MyISAM pueden quedar “marcadas como crashed” tras un apagado no limpio porque el motor no tiene recuperación transaccional como InnoDB.
5. OPTIMIZE TABLE puede bloquear tablas durante tiempo sustancial según el motor y la versión de MySQL/MariaDB—un “arreglo fácil” puede convertirse en multiplicador de outage.
6. Un sitio WordPress puede parecer roto por la corrupción de una sola tabla: wp_options. Esa tabla es un punto caliente para plugins
   y a menudo es la primera en mostrar problemas.
7. El mensaje de error a veces es engañoso: una consulta que falla con “incorrect string value” o “illegal mix of collations” puede surgir de maneras que parecen “corrupción”, pero en realidad es un desajuste de charset/collation tras una actualización o restauración.
8. Las advertencias de “corrupción” en InnoDB a veces provienen del almacenamiento subyacente que devuelve datos antiguos o incorrectos (cache malfuncionando, controlador o disco virtual defectuoso). Las bases de datos son buenas detectando mentiras, no corrigiéndolas.

Causas comunes y modos de fallo

1) Apagados no limpios y recuperación tras crash

Pérdida de energía, kernel panic, kills por OOM, reinicios forzados por la plataforma de hosting—las bases de datos odian las sorpresas. InnoDB está diseñado para recuperarse,
pero la recuperación necesita I/O de disco funcional y suficiente espacio libre para logs y trabajo temporal. MyISAM es más frágil; puede marcar tablas como crashed y requerir reparaciones explícitas.

2) Disco lleno (o inodos agotados) que se hace pasar por “corrupción”

Cuando el sistema de ficheros llega al 100%, las escrituras fallan. InnoDB puede quedarse atascado con operaciones parcialmente escritas o incapaz de extender su tablespace.
WordPress entonces ve fallos de consulta y sugiere reparación.

3) Corrupción real en disco

Este es el verdadero: sectores dañados, RAID roto, almacenamiento en bloque de red mal configurado o un sistema de ficheros que sufrió daño. InnoDB se quejará de checksum mismatch o “page corruption”. En ese punto, “reparar” desde WordPress es mayormente teatro. Necesitas backups, tácticas de recuperación y a veces una extracción controlada.

4) Comportamiento de plugins y filas sobredimensionadas

Algunos plugins tratan la base de datos como un cajón de trastos: enormes blobs serializados en wp_options, transients interminables o tablas de logs que crecen hasta que las consultas agotan el tiempo. Puedes ver errores que parecen que la base de datos está rota, pero en realidad se está ahogando.

5) Operaciones de “optimización” que salen mal

OPTIMIZE TABLE, cambios de esquema y borrados masivos pueden provocar I/O masivo, uso temporal de disco y locks largos.
En entornos compartidos, puedes dejar la base de datos sin recursos el tiempo suficiente como para que WordPress se descomponga y diga que necesita reparación.

Broma #1: “Database needs repair” es la manera de WordPress de decir: “Estoy bien, pero lo que dependo está teniendo un momento de construcción de carácter.”

Tareas prácticas: comandos, salida esperada y decisiones

A continuación hay tareas prácticas que puedes ejecutar en un host Linux típico con MySQL/MariaDB y WordPress. Cada tarea incluye comandos, salida de ejemplo,
qué significa la salida y la decisión que tomas a continuación. Copia/pega con cuidado; los sistemas de producción son alérgicos a las conjeturas.

Task 1: Confirmar que WordPress puede resolver y alcanzar el host de BD

cr0x@server:~$ getent hosts db.internal
10.20.30.40    db.internal

Qué significa: La resolución de nombres funciona y tienes una IP.

Decisión: Si esto falla, arregla DNS/hosts/ruteo VPC antes de tocar las herramientas de reparación de WordPress.

Task 2: Conectividad TCP básica al puerto de BD

cr0x@server:~$ nc -vz db.internal 3306
Connection to db.internal 3306 port [tcp/mysql] succeeded!

Qué significa: La ruta de red y los security groups/firewall permiten conexiones a la BD.

Decisión: Si está bloqueado, detente. Las reparaciones de tablas no ayudarán a un puerto cerrado.

Task 3: Validar credenciales de BD desde wp-config.php

cr0x@server:~$ php -r 'require "wp-config.php"; echo DB_HOST, " ", DB_NAME, " ", DB_USER, PHP_EOL;'
db.internal wordpressdb wpuser

Qué significa: Has extraído los objetivos de conexión configurados.

Decisión: Si estos no coinciden con los valores esperados (rotación de secretos reciente, BD migrada), arregla la configuración primero.

Task 4: Intentar un login MySQL simple y una consulta

cr0x@server:~$ mysql -h db.internal -u wpuser -p -e "SELECT 1;"
Enter password: 
1
1

Qué significa: La autenticación funciona y el servidor responde.

Decisión: Si obtienes “Access denied”, la reparación es irrelevante—arregla credenciales/privilegios.

Task 5: Comprobar espacio libre e inodos en el host de BD

cr0x@server:~$ df -h /var/lib/mysql
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  200G  198G  2.0G  99% /var/lib/mysql

Qué significa: Estás a una tabla temporal de un mal rato.

Decisión: Libera espacio primero (logs, backups antiguos, binlogs) antes de cualquier operación de reparación/optimizacíon.

cr0x@server:~$ df -i /var/lib/mysql
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/nvme0n1p3  13M     13M     2K   100% /var/lib/mysql

Qué significa: El agotamiento de inodos puede romper escrituras aunque el “espacio” parezca bien.

Decisión: Limpia ficheros pequeños excesivos (tmp, logs). Si la BD no puede crear archivos, las reparaciones pueden fallar a mitad de vuelo.

Task 6: Leer logs de MySQL/MariaDB para el fallo real

cr0x@server:~$ sudo tail -n 60 /var/log/mysql/error.log
2025-12-27T07:10:12.002345Z 0 [Warning] InnoDB: Database page corruption on disk or a failed file read of page [page id: space=123, page number=456]
2025-12-27T07:10:12.002400Z 0 [ERROR] InnoDB: Page checksum mismatch on read.
2025-12-27T07:10:12.002430Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Data structure corruption

Qué significa: Esto no es “ejecuta REPAIR TABLE.” Esto es territorio de integridad de almacenamiento.

Decisión: Deja de escribir. Toma un snapshot/backup. Planea recuperación/extracción desde backups o salvamento controlado.

Task 7: Comprobar si hay tablas MyISAM marcadas como crashed

cr0x@server:~$ mysql -h db.internal -u root -p -e "SELECT TABLE_SCHEMA,TABLE_NAME,ENGINE,TABLE_ROWS,CREATE_OPTIONS FROM information_schema.TABLES WHERE TABLE_SCHEMA='wordpressdb' AND ENGINE='MyISAM';"
Enter password:
+-------------+-------------------+--------+------------+----------------+
| TABLE_SCHEMA | TABLE_NAME        | ENGINE | TABLE_ROWS | CREATE_OPTIONS |
+-------------+-------------------+--------+------------+----------------+
| wordpressdb  | wp_search_cache   | MyISAM |      12034 |                |
+-------------+-------------------+--------+------------+----------------+

Qué significa: Tienes al menos una tabla MyISAM. Esas pueden requerir legítimamente REPAIR TABLE.

Decisión: Identifica si el mensaje de error referencia específicamente estas tablas. Si es así, repáralas—después de hacer backup.

Task 8: Ejecutar un chequeo de tablas para localizar corrupción (rápido, bajo riesgo)

cr0x@server:~$ mysqlcheck -h db.internal -u root -p --databases wordpressdb
Enter password:
wordpressdb.wp_posts                                 OK
wordpressdb.wp_options                               OK
wordpressdb.wp_search_cache                          error    : Table is marked as crashed and should be repaired
wordpressdb.wp_search_cache                          status   : Operation failed

Qué significa: Una tabla está explícitamente marcada como crashed.

Decisión: Repara solo la(s) tabla(s) afectada(s). No “optimices todo” por aburrimiento.

Task 9: Hacer backup antes de reparar (dump lógico)

cr0x@server:~$ mysqldump -h db.internal -u root -p --single-transaction --routines --triggers wordpressdb | gzip -1 > /tmp/wordpressdb.sql.gz
Enter password:

Qué significa: Has tomado un backup lógico consistente (mejor esfuerzo; puede fallar si las tablas son ilegibles).

Decisión: Si el dump falla en una tabla específica, anótalo. Considera volcar tabla por tabla para salvar lo que puedas.

Task 10: Reparar una tabla MyISAM directamente (dirigido)

cr0x@server:~$ mysql -h db.internal -u root -p -e "REPAIR TABLE wordpressdb.wp_search_cache;"
Enter password:
+------------------------------+--------+----------+----------+
| Table                        | Op     | Msg_type | Msg_text |
+------------------------------+--------+----------+----------+
| wordpressdb.wp_search_cache  | repair | status   | OK       |
+------------------------------+--------+----------+----------+

Qué significa: La reparación de la tabla tuvo éxito.

Decisión: Vuelve a ejecutar mysqlcheck. Si está limpia, recupera el sitio y vigila los logs por recurrencias.

Task 11: Si WordPress está disponible, usa WP-CLI para chequear/reparar (más seguro que la exposición web)

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp db check
Success: Database checked.
cr0x@server:~$ wp db repair
Success: Database repaired.

Qué significa: WP-CLI ejecutó con éxito los pasos de mantenimiento de BD que WordPress conoce.

Decisión: Si WP-CLI falla con errores SQL, vuelve a los logs de MySQL y a las comprobaciones dirigidas. No sigas reintentando a ciegas.

Task 12: Inspeccionar el tamaño y crecimiento de la tabla más problemática (a menudo wp_options)

cr0x@server:~$ mysql -h db.internal -u root -p -e "SELECT table_name, ROUND((data_length+index_length)/1024/1024,1) AS mb FROM information_schema.TABLES WHERE table_schema='wordpressdb' ORDER BY (data_length+index_length) DESC LIMIT 10;"
Enter password:
+----------------+------+
| table_name     | mb   |
+----------------+------+
| wp_options     | 512.4|
| wp_posts       | 240.7|
| wp_postmeta    | 210.3|
| wp_actionscheduler_logs | 180.9|
+----------------+------+

Qué significa: Tu tabla options es enorme, lo que suele correlacionar con consultas lentas, timeouts y síntomas de “reparación”.

Decisión: Investiga las opciones autoloaded y el comportamiento de plugins. Esto es remediación, no reparación.

Task 13: Identificar bloat de autoload en wp_options

cr0x@server:~$ mysql -h db.internal -u root -p wordpressdb -e "SELECT COUNT(*) AS autoloaded_rows, ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes';"
Enter password:
+----------------+-------------+
| autoloaded_rows| autoload_mb |
+----------------+-------------+
|          12456 |       88.40 |
+----------------+-------------+

Qué significa: WordPress carga opciones autoloaded en muchas peticiones. 88 MB no está “bien.” Es un DoS que te estás auto-infligiendo.

Decisión: Reduce las opciones autoloaded (ajustes de plugins, transients) y añade caching. No ejecutes una “reparación” y lo des por resuelto.

Task 14: Comprobar consultas de larga duración o esperas de bloqueo (los intentos de reparación pueden empeorar esto)

cr0x@server:~$ mysql -h db.internal -u root -p -e "SHOW FULL PROCESSLIST\G"
Enter password:
*************************** 1. row ***************************
     Id: 8123
   User: wpuser
   Host: 10.20.40.55:52111
     db: wordpressdb
Command: Query
   Time: 128
  State: Waiting for table metadata lock
   Info: OPTIMIZE TABLE wp_postmeta

Qué significa: Alguien está optimizando y bloqueando a los demás. Esto puede hacer que WordPress parezca “roto”.

Decisión: Para/elimínalo si procede, y luego planifica mantenimiento con ventana y plan real.

Task 15: Verificar la salud del motor InnoDB rápidamente

cr0x@server:~$ mysql -h db.internal -u root -p -e "SHOW ENGINE INNODB STATUS\G" | sed -n '1,120p'
Enter password:
------------
TRANSACTIONS
------------
Trx id counter 987654321
Purge done for trx's n:o < 987650000 undo n:o < 0 state: running but idle
History list length 12

Qué significa: InnoDB está corriendo y no parece atascado con una lista de historial enorme o rollback activo.

Decisión: Si el status muestra recuperación tras crash, corrupción repetida o “waiting for” I/O, céntrate en almacenamiento y opciones de recuperación.

Task 16: Señales básicas de error de almacenamiento (no lo omitas)

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Sat Dec 27 07:08:10 2025] blk_update_request: I/O error, dev nvme0n1, sector 123456789
[Sat Dec 27 07:08:10 2025] EXT4-fs error (device nvme0n1p3): ext4_find_entry:1463: inode #262144: comm mysqld: reading directory lblock 0

Qué significa: Tu base de datos está leyendo basura porque el disco falla o el sistema de ficheros está dañado.

Decisión: Detén las escrituras, haz snapshot si es posible, migra a almacenamiento sano y restaura desde backups. “Reparar tablas” no es la solución.

Usar WP_ALLOW_REPAIR con seguridad (y no convertirlo en barra libre)

WordPress incluye un endpoint de reparación en wp-admin/maint/repair.php. Está desactivado por defecto y puede activarse
añadiendo define('WP_ALLOW_REPAIR', true); en wp-config.php.

Lo bueno: es simple y puede reparar ciertos problemas de tablas, principalmente alrededor de MyISAM. Lo malo: es una página accesible por HTTP,
y WordPress advierte explícitamente que no requiere login cuando está habilitada. Eso significa que si la dejas activada, estás invitando a extraños
a usar tus funciones de mantenimiento de BD. Quizá no roben datos, pero sí pueden generar carga y bloquear tablas.

Patrón de uso seguro

• Prefiere WP-CLI (wp db check / wp db repair) si tienes acceso shell.
• Si debes usar la página web, habilita WP_ALLOW_REPAIR brevemente, ejecuta la reparación y elimínala inmediatamente.
• Restringe el acceso a nivel de servidor web (allowlist de IP) mientras esté habilitada.

Ejemplo: habilitar reparación temporalmente

cr0x@server:~$ sudo sed -i "s/^.*WP_ALLOW_REPAIR.*$/define('WP_ALLOW_REPAIR', true);/g" /var/www/html/wp-config.php

Qué significa: Has activado el modo de reparación (esto asume que ya existía una línea; ten cuidado con ediciones automatizadas).

Decisión: Inmediatamente añade una restricción por IP o pon el sitio detrás de una puerta de mantenimiento mientras ejecutas la reparación.

Ejemplo: bloquear el endpoint de reparación a tu IP (Nginx)

cr0x@server:~$ sudo nginx -T | sed -n '1,80p'
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Qué significa: La sintaxis de la config es válida antes de recargar.

Decisión: Añade un bloque de location para /wp-admin/maint/repair.php y restríngelo, luego recarga Nginx.

Broma #2: Dejar WP_ALLOW_REPAIR habilitado es como dejar el coche encendido fuera de la oficina—técnicamente conveniente, socialmente ambicioso.

InnoDB vs MyISAM: reparaciones muy distintas

MyISAM: REPAIR TABLE es real

Si la tabla afectada es MyISAM, REPAIR TABLE puede reconstruir índices y arreglar ciertos problemas estructurales. Aun así puede fallar si
el archivo de datos está muy dañado, pero es una respuesta legítima tras haber respaldado lo que puedas.

La corrupción MyISAM suele aparecer como “Table is marked as crashed” o “Can’t open file.” Las reparaciones pueden ser rápidas para tablas pequeñas y brutales para las grandes. Además, MyISAM usa locks a nivel de tabla; las reparaciones pueden bloquear lecturas/escrituras.

InnoDB: “reparar” a menudo significa “recuperar”

Con InnoDB, REPAIR TABLE no hace lo que la gente piensa. InnoDB se basa en recuperación tras crash, redo logs y checksums. Cuando InnoDB
reporta corrupción, tu mejor “reparación” suele ser:

• Confirmar la salud del almacenamiento (errores I/O, estado del sistema de ficheros, eventos de volumen en cloud).
• Restaurar desde un backup/snapshot conocido bueno si está disponible.
• Si debes salvar datos, usa extracción controlada: vuelca lo que se lee bien, aisla tablas dañadas y reconstruye desde el esquema + datos sobrevivientes.

No confundas “optimize” con “repair”

Muchas guías de WordPress tratan OPTIMIZE TABLE como una escoba mágica. En la práctica, puede:
bloquear tablas, reescribirlas, requerir mucho espacio temporal y picos de I/O que saquen a la luz problemas de almacenamiento latentes.
Es una operación de mantenimiento, no medicina de emergencia.

Aspectos de almacenamiento y hosting (donde suele empezar la corrupción)

Como SRE, aprendí a asumir que la aplicación es la mensajera y el almacenamiento es la escena del crimen. La corrupción de BD suele ser consecuencia
de eventos de infraestructura que no notaste: un vecino ruidoso saturando IOPS, un reboot de nodo, un sistema de ficheros remountado en modo solo lectura,
o un volumen que devolvió errores y luego fingió que no pasó nada.

Busca estos patrones de almacenamiento

• Disco lleno: fácil de confirmar, fácil de arreglar, sorprendentemente común.
• Sistema de ficheros en solo lectura: fallos súbitos en todo el stack; MySQL puede pararse o negarse a escribir.
• Errores de I/O: los logs del kernel los muestran; los logs de BD muestran checksum mismatches; WordPress muestra “repair”.
• Picos de latencia: pueden hacerse pasar por corrupción cuando las consultas hacen timeout o los clientes se desconectan a mitad de operación.

Comprobaciones prácticas de saneamiento de almacenamiento (Linux)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE
NAME         SIZE TYPE MOUNTPOINT     FSTYPE
nvme0n1      500G disk
└─nvme0n1p3  200G part /var/lib/mysql ext4

Qué significa: Confirma qué dispositivo respalda el datadir de MySQL.

Decisión: Si esto es un volumen de red o disco efímero, ajusta tus expectativas y tu postura de backups.

cr0x@server:~$ mount | grep /var/lib/mysql
/dev/nvme0n1p3 on /var/lib/mysql type ext4 (rw,relatime,errors=remount-ro)

Qué significa: El sistema de ficheros se remontará en solo lectura ante errores (configuración común).

Decisión: Si lo ves remonteado en solo lectura, no vas a reparar nada hasta arreglar el sistema de ficheros/disco.

Tres micro-historias corporativas desde el frente

Incidente #1: El outage causado por una suposición incorrecta

Una empresa mediana ejecutaba WordPress para un sitio de marketing que de pronto mostró “database needs repair.” El ingeniero on-call vio
el mensaje, recordó el endpoint de reparación de WordPress, habilitó WP_ALLOW_REPAIR, hizo clic en “Repair and Optimize” y esperó.

La base de datos se volvió más lenta. Luego dejó de estar disponible. El sitio que estaba parcialmente degradado quedó totalmente caído, y el monitoring
empezó a alertar por errores de conexión. El ingeniero asumió “está reparando, dale tiempo.” Esa suposición resultó cara.

La causa raíz no era corrupción en absoluto. El disco de la base de datos estaba al 99% de uso. El paso de optimize intentó reconstruir un par de tablas grandes,
creó archivos temporales y recibió ENOSPC a mitad de operación. MySQL empezó a fallar más consultas, y WordPress—tratando de ser útil—seguía mostrando el mismo consejo de reparación.

La solución fue aburrida: liberar espacio en disco, reiniciar MySQL limpiamente y volver a ejecutar una comprobación dirigida. No necesitaban optimización; necesitaban
gestión de capacidad. El cambio post-incidente fue igual de aburrido: una alerta al 85% de uso de disco y un runbook que decía “libera espacio antes de reparar.” No es glamuroso, pero evitó la repetición.

Incidente #2: Una optimización que salió mal

Otro equipo tenía una instalación de WordPress con años de churn de plugins. Alguien notó que la BD crecía y decidió “limpiarla”
ejecutando optimizaciones nocturnas en todas las tablas. Parecía responsable, como usar hilo dental. Las primeras noches fueron tranquilas.

Entonces el tráfico aumentó y el sitio comenzó a lanzar errores intermitentes en horas punta. Los editores se quejaban de que guardar borradores a veces colgaba.
El servidor de BD mostró alta utilización de I/O en horas impares, y la latencia diurna empeoró. La gente culpó a la plataforma de hosting, que es lo que se hace cuando los gráficos asustan.

El problema: el job de optimize reescribía tablas InnoDB grandes cada noche, generando I/O de fondo intenso, removiendo la pool de buffer y ocasionalmente
manteniendo metadata locks que chocaban con el tráfico real. En otras palabras: el “mantenimiento” competía con producción, y la producción perdió.

Pararon el optimize nocturno y luego hicieron trabajo dirigido: eliminaron un plugin que almacenaba blobs autoloaded grandes, limpiaron transients y añadieron un cache de objetos adecuado. La BD se hizo más pequeña naturalmente con el tiempo porque dejaron de alimentarla con basura. La optimización no arregló el comportamiento subyacente; solo hizo que el sistema sudara más.

Incidente #3: La práctica aburrida pero correcta que salvó el día

Una gran empresa ejecutaba múltiples propiedades WordPress. Nada especial—hasta que un parche de infraestructura provocó un reboot inesperado de una VM de BD durante un empujón de contenido. WordPress comenzó a mostrar avisos de reparación de base de datos y algunas páginas devolvían errores.

El equipo no tocó el endpoint de reparación. Siguieron su runbook: congelar escrituras (modo mantenimiento), snapshot del volumen,
tomar un dump lógico fresco y solo entonces ejecutar comprobaciones. Se sintió lento en el momento. Fue el tipo correcto de lentitud.

Las comprobaciones mostraron una pequeña tabla legacy MyISAM marcada como crashed (resto de un plugin antiguo), y todo lo demás estaba bien.
Repararon esa tabla, validaron el sitio y lo devolvieron al servicio. El snapshot significó que si la reparación hubiera empeorado las cosas, podrían revertir instantáneamente.

La heroína silenciosa fue la práctica que nadie presume en los informes de estado: siempre toma un punto recuperable antes de “arreglar” algo. Transformó una situación riesgosa en una tarea de mantenimiento controlada y evitó que el incidente se convirtiera en una saga de recuperación.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: “Database needs repair” aparece justo después de una migración

Causa raíz: Import incompleto, tablas faltantes, prefijo de tabla incorrecto o desajuste de charset/collation que hace fallar consultas.

Solución: Verifica el prefijo de tablas en wp-config.php, confirma el recuento de tablas y la presencia de tablas core, y revisa charset/collation. Reimporta limpiamente desde el dump.

2) Síntoma: La reparación corre, pero el mensaje vuelve horas después

Causa raíz: Problemas subyacentes de almacenamiento, apagados no limpios recurrentes, o una tabla MyISAM que se corrompe repetidamente por crashes.

Solución: Elimina apagados no limpios; migra tablas MyISAM legacy a InnoDB cuando sea posible; revisa logs del kernel/disco y eventos del hosting.

3) Síntoma: La página de reparación cuelga o agota tiempo

Causa raíz: Tablas grandes, metadata locks o la BD saturada (limitada por I/O o CPU). A veces el max execution time de PHP lo termina a mitad.

Solución: Prefiere herramientas por línea de comandos (mysqlcheck, WP-CLI). Repara una tabla a la vez. Programa operaciones pesadas fuera de pico.

4) Síntoma: “Error establishing a database connection” más confusión por aviso de reparación

Causa raíz: Límites de conexión, BD caída, problemas DNS/red o credenciales erróneas. No es corrupción.

Solución: Arregla conectividad y credenciales. Revisa max_connections y el comportamiento de pooling de la aplicación.

5) Síntoma: MySQL se reinicia repetidamente tras la advertencia de reparación

Causa raíz: Recuperación InnoDB fallando por corrupción, disco lleno o errores del sistema de ficheros.

Solución: Para el thrashing. Preserva el estado. Revisa logs de error y salud del disco. Restaura desde backup/snapshot o realiza salvamento controlado.

6) Síntoma: El admin carga, pero el front-end lanza 500 aleatorios y avisos de “repair”

Causa raíz: Bloat de autoload, tablas de plugins descontroladas, consultas lentas que hacen timeout o contención de locks.

Solución: Identifica las tablas más grandes, investiga opciones autoloaded, rota tablas de logs, añade caching y ajusta índices donde corresponda.

7) Síntoma: Lo arreglaste una vez y ahora está peor

Causa raíz: Ejecutaste optimize/repair sobre un disco fallando o sin espacio libre, provocando reescrituras parciales y escalando el daño.

Solución: Restaura al snapshot/backup previo a la reparación, estabiliza almacenamiento y capacidad, y luego vuelve a intentar reparaciones dirigidas con un plan de rollback.

Listas de verificación / plan paso a paso

Plan de emergencia (sitio degradado o caído)

1. Estabilizar: pon WordPress en modo mantenimiento o reduce las escrituras (deshabilita cron, pausa jobs pesados).
2. Confirmar conectividad: verifica que el host de BD sea accesible y que las credenciales sean válidas.
3. Comprobar capacidad: confirma espacio en disco e inodos en el host de BD; libera espacio si es necesario.
4. Leer logs de BD: identifica si esto es crash de MyISAM, recuperación InnoDB o errores de I/O del disco.
5. Tomar una copia recuperable: haz snapshot del volumen si está disponible; luego intenta un mysqldump.
6. Localizar tablas fallidas: ejecuta mysqlcheck o CHECK TABLE dirigido.
7. Reparar solo lo roto: usa REPAIR TABLE para MyISAM; evita optimizaciones amplias.
8. Validar: vuelve a ejecutar comprobaciones; prueba páginas clave; vigila los logs de error.
9. Quitar exposición de reparación: si habilitaste WP_ALLOW_REPAIR, elimínalo inmediatamente.
10. Monitorizar: vigila I/O de disco, log de errores de MySQL y errores de WordPress durante 24–48 horas.

Plan de estabilidad (después de recuperar)

1. Convertir tablas legacy: migra tablas MyISAM a InnoDB donde sea factible.
2. Arreglar higiene de datos de plugins: reduce autoload bloat, rota tablas de logs, elimina plugins abandonados.
3. Implementar backups restaurables: snapshots y dumps lógicos, probados regularmente.
4. Añadir guardrails: alertas de espacio en disco, logging de consultas lentas y una política de ventanas de mantenimiento para reescrituras de tablas.
5. Ensayar recuperación: realiza un drill de restauración. Una vez. Dormirás mejor para siempre.

Preguntas frecuentes

¿“Database needs repair” siempre significa corrupción?

No. Significa que WordPress encontró errores de base de datos consistentes con tablas dañadas o metadata inconsistente. Disco lleno, contención de locks,
timeouts y problemas de credenciales pueden imitar los síntomas de “necesita reparación”.

¿Es seguro hacer clic en “Repair Database” en WordPress?

A veces. Es relativamente seguro para problemas de tablas MyISAM y pequeñas inconsistencias. No sustituye a los backups y no arreglará
la corrupción de almacenamiento subyacente. Si puedes, toma un snapshot/dump primero.

¿Debería ejecutar “Repair and Optimize”?

En emergencias, por lo general no. Optimize puede ser pesado, propenso a locks y hambriento de disco. Repara las tablas específicas rotas primero; optimiza después
en una ventana con espacio libre y un plan de rollback.

¿Por qué sigue ocurriendo después de reparar?

Las reparaciones repetidas suelen apuntar a apagados no limpios recurrentes, un disco fallando o una tabla MyISAM frágil que todavía se usa.
Otra causa común es un plugin que genera escrituras abusivas y hace colapsar el sistema bajo carga.

¿WP-CLI puede arreglar esto sin habilitar WP_ALLOW_REPAIR?

Sí. wp db check y wp db repair de WP-CLI son la misma idea pero ejecutadas desde CLI, lo cual suele ser más seguro operativamente
que exponer un endpoint web.

¿Y si la base de datos no arranca en absoluto?

Entonces WordPress no puede reparar nada. Ve a la capa de base de datos: comprueba espacio en disco, salud del sistema de ficheros y logs de error de MySQL. Si InnoDB
reporta corrupción persistente, restaura desde backups/snapshots o realiza extracción de datos controlada.

¿Convertir tablas a InnoDB previene esto?

Reduce una clase de problemas (tablas MyISAM marcadas como crashed) porque InnoDB tiene recuperación tras crash. No te protege de corrupción de disco,
disco lleno, migraciones mal hechas o plugins mal comportados.

¿Puedo reparar desde phpMyAdmin?

Puedes, pero no es mi primera opción. Las herramientas web son cómodas y también se agotan a mitad de operación. Para reparaciones y comprobaciones,
las herramientas CLI (mysqlcheck, mysql, WP-CLI) son más controlables y fáciles de auditar.

¿Cuál es el backup más seguro antes de reparar?

Lo mejor es un snapshot del volumen de BD (rollback rápido) más un dump lógico (mysqldump --single-transaction) para portabilidad. Si sospechas corrupción,
espera que los dumps fallen en tablas específicas y salva lo que puedas.

¿Necesito deshabilitar el cron de WordPress durante las reparaciones?

Si el sitio es inestable, sí. Cron y tareas background pueden seguir escribiendo mientras intentas estabilizar, lo que complica la recuperación.
Pausa el ruido, arregla la base de datos y luego vuelve a habilitar los trabajos en segundo plano.

Pasos siguientes que debes tomar

Cuando WordPress dice “database needs repair”, no lo trates como un aviso de UI. Trátalo como una señal de que la capa de datos está lanzando errores y tu trabajo
es identificar qué clase es: conectividad, capacidad, recuperación a nivel de motor o corrupción real.

Tus siguientes pasos prácticos:

1. Ejecuta la guía de diagnóstico rápido: conectividad → logs de BD → salud del almacenamiento.
2. Haz backup (snapshot + dump) antes de cualquier intento de reparación.
3. Usa mysqlcheck o WP-CLI para identificar las tablas fallidas específicas.
4. Repara solo lo que está roto; evita “optimizar todo” durante un incidente.
5. Tras la recuperación, arregla la causa raíz: espacio en disco, higiene de datos de plugins, patrones de crash y backups probados.

Si haces esto bien, el mensaje de “repair” se convierte en un breve evento de mantenimiento, no en un hobby de fin de semana.