Panel y archivosUna cuota de base de datos parece una línea arbitraria trazada en la arena hasta que un plugin la choca de verdad, y ahí deja de parecer arbitraria del todo, porque los dos límites que la forman protegen dos cosas completamente distintas.
Dos límites, dos problemas distintos
El almacenamiento y las conexiones fallan por motivos sin relación. El almacenamiento es directo: un plugin de registro que nunca poda su propio historial crece sin límite, fila a fila, hasta llegar al techo. Las conexiones van de concurrencia, no de tamaño: cada conexión abierta ocupa un hilo y unos búferes en el servidor de base de datos mientras siga abierta, y un servidor de base de datos en infraestructura compartida tiene que repartir eso entre todos los que la usan, no solo tú.
Un plugin que abre una conexión nueva por consulta en vez de reutilizar un pool puede agotar el límite de conexiones mucho antes de acercarse siquiera al de almacenamiento, y por eso «mi base es pequeña pero los plugins no pueden conectar» es un fallo real y distinto de «mi base está llena».
Leer qué límite chocaste
| Síntoma | Límite |
|---|---|
| El plugin registra un error de disco lleno o de inserción | Almacenamiento (500 MB) |
| El plugin registra un error de «demasiadas conexiones» | Conexiones (150) |
| Todo funciona y luego rechaza consultas nuevas de forma intermitente bajo carga | Conexiones — un problema de pool, no de tamaño |
Mantener un plugin de registro dentro de la cuota
- Busca el ajuste de purga o retención
Los registradores de bloques como CoreProtect existen precisamente para podarse; el ajuste suele llamarse retención, edad de purga o días de historial, y es la palanca más grande sobre el uso de almacenamiento.
- Ejecuta la purga a mano una vez antes de fiarte de la programada
Una base que lleva meses creciendo sin podar puede necesitar una pasada de purga de verdad para volver a estar dentro de la cuota; la tarea recurrente sola no va a ponerse al día al instante.
- Comprueba que el plugin no abra una conexión por consulta
Casi todos los plugins modernos usan un pool de conexiones por defecto. Uno viejo o mal mantenido que no lo haga es la causa habitual de chocar el límite de conexiones con una base que ni de lejos está llena.
A diferencia de la memoria del propio servidor de juego, dedicada a tu contenedor, el servidor de MySQL detrás sirve las bases de datos de todos los inquilinos desde una capacidad compartida. Una base sin cuota no es una comodidad para un servidor: es la forma en que un plugin mal configurado degrada la base de datos para todos los que están en la misma instancia.