Cuando el volumen de la base no tiene bloques libres, MySQL puede rechazar inserciones y actualizaciones, fallar al crear tablas temporales o detenerse. WordPress quizá siga sirviendo páginas en caché mientras fallan guardados, accesos, cron y formularios.
Detén inmediatamente escrituras no esenciales y copias. Borrar archivos desconocidos de MySQL es peligroso: los datos y registros InnoDB no son caché desechable.
Confirma qué sistema de archivos está lleno
Revisa los sistemas de datos, temporales, logs y copias de MySQL, además de los inodos. Que la raíz tenga espacio no ayuda si /var/lib/mysql o la cuota del alojamiento está llena.
Registra:
sistema de archivos o cuota
bytes e inodos libres
directorios más grandes
hora del error MySQL
crecimiento reciente de copias, importaciones o logsEn hosting gestionado pide pruebas al proveedor, sin usar órdenes no compatibles.
Contén la actividad de escritura
Pausa importaciones, copias, escaneos, colas de correo y ediciones masivas mediante sus controles. Considera un mantenimiento que impida nuevas escrituras y muestre un mensaje claro.
No reinicies MySQL repetidamente ni envíes formularios. Las escrituras fallidas pueden crear operaciones parciales y más registros.
Conserva el acceso de administrador y SSH antes de cambiar servicios.
Identifica espacio recuperable
Busca copias locales antiguas, archivos temporales, cachés y logs rotados con una política de conservación aprobada. Mueve fuera del servidor las copias importantes antes de borrar.
No elimines manualmente archivos activos como ibdata, redo o undo logs, binlogs o archivos de tablas. La purga de binlogs debe respetar replicación y recuperación a un punto temporal.
Deja la limpieza gestionada por el motor al proveedor o administrador.
Reserva espacio temporal
MySQL necesita espacio adicional para ordenación, tablas temporales, reconstrucción de índices, recuperación y binlogs. Dejar unos megabytes tras la limpieza puede hacer fallar la siguiente consulta normal.
Mide la importación, copia o ALTER TABLE mayor esperada y fija un umbral operativo más alto. Si la cuota no permite margen, amplía o migra el almacenamiento antes del mantenimiento. No optimices tablas solo para ganar espacio: puede requerir una segunda copia temporal.
Revisa registros MySQL y binarios
Un bucle de errores puede hacer crecer muy rápido los logs de MySQL, PHP o web. Conserva un fragmento limitado de la incidencia y rota o trunca solo mediante controles compatibles.
Los binlogs pueden crecer mucho tras importaciones. Confirma posiciones de réplica y política de copias antes de una purga autorizada.
No desactives todo el registro permanentemente; la recaída sería invisible.
Recupera el servicio con cautela
Cuando exista margen seguro, inicia o recupera MySQL desde el panel o gestor y lee su registro. La recuperación InnoDB puede necesitar todavía más espacio temporal.
No abras escrituras públicas hasta que termine. Confirma primero conexión de WordPress y lecturas.
Si aparece corrupción, toma snapshots y aplica una recuperación acorde al motor, no reparaciones genéricas.
Encuentra el origen del crecimiento
Mide tablas y directorios. Son causas habituales los logs de tareas programadas, sesiones, seguridad, revisiones, tablas de caché, importaciones fallidas y copias locales acumuladas.
Restaura limpiezas compatibles y corrige cron. No elimines pedidos, formularios ni auditoría solo por el tamaño.
El tráfico bot puede generar sesiones y logs; limita únicamente las rutas abusivas.
Planifica capacidad duradera
Configura alertas mucho antes de llegar a cero y reserva margen para temporales, actualizaciones y restauraciones. Base de datos y copias necesitan almacenamiento planificado.
La política debe indicar qué se conserva, dónde y cuánto tiempo. Una copia externa protege si el disco falla por completo.
Calcula crecimiento durante campañas e importaciones, no solo en días normales.
Verifica escrituras e integridad
Tras recuperar, guarda un borrador u opción controlados, ejecuta tareas y revisa registros MySQL y PHP. Prueba una copia hacia almacenamiento externo y una restauración de muestra.
Vigila el espacio durante varios ciclos. El mantenimiento recurrente debe alertar por bytes, inodos y crecimiento anormal; la recuperación termina cuando WordPress escribe con fiabilidad y el disco conserva margen sostenible.