Mantén la base de datos de Plex cuando los errores o la ralentización del estado de la aplicación puedan solucionarse; reemplázala solo después de que la reparación y las copias de seguridad verificadas no logren producir un estado estable.
Las bases de datos saludables pueden ser grandes, y una navegación ocasionalmente lenta no justifica reconstruirlas. Las señales de advertencia más importantes son los errores de integridad, un crecimiento rápido e inexplicable, fallos de escritura recurrentes, metadatos lentos mientras la reproducción sigue funcionando correctamente o una corrupción que reaparece después de la reparación. Conserva primero la base de datos actual, determina si el problema está en el almacenamiento, los índices o los daños estructurales, y pasa del mantenimiento al reemplazo solo cuando las pruebas lo exijan.
Trata los errores repetidos de la base de datos como una señal de estado
Los mensajes de corrupción, los errores de base de datos con formato incorrecto, los fallos de escritura o las recuperaciones repetidas desde copias de seguridad son razones importantes para detener el mantenimiento habitual y proteger el estado actual. No sigas escaneando, optimizando ni reiniciando una base de datos que está informando activamente de problemas de integridad.
Cuando los registros muestren síntomas de corrupción de la base de datos, conserva una copia y detén el servidor antes de repararla para que el mantenimiento habitual no sobrescriba las pruebas.
Registra el error exacto y la fecha y hora de la base de datos, y luego copia el directorio de la base de datos antes de intentar repararla. Si existe una copia de seguridad verificada, compara su antigüedad con la cantidad de estado que perderías. No elimines la base de datos activa hasta haber elegido una ruta de recuperación.
El crecimiento rápido e inexplicable merece una investigación
Una biblioteca de Plex que crece hace que su base de datos también aumente de forma natural, pero una base de datos que se expande mucho más rápido que la biblioteca mientras las consultas se ralentizan o aparece corrupción representa un patrón diferente. La señal útil es un crecimiento sin una explicación de carga de trabajo equivalente, no un tamaño de archivo concreto.
El crecimiento rápido resulta más preocupante cuando aparece junto con consultas lentas y corrupción. Esa combinación requiere comprobaciones de integridad y revisar los registros, en lugar de simplemente añadir más espacio en disco.
Registra el tamaño de la base de datos a lo largo del tiempo junto con las nuevas incorporaciones a la biblioteca y las ventanas de mantenimiento. Si el crecimiento sigue la expansión legítima del contenido multimedia y el rendimiento es estable, continúa supervisándolo. Si se acelera de forma independiente, captura los registros antes de que la optimización o la limpieza alteren las pruebas.
La navegación lenta con una reproducción saludable puede indicar problemas en el estado de la aplicación
Las cuadrículas de pósteres, las búsquedas, los filtros de biblioteca y las páginas de metadatos utilizan la base de datos y muchos archivos pequeños de la aplicación. Si se vuelven lentos mientras una película que ya ha comenzado se reproduce mediante Direct Play sin problemas, es más probable que el síntoma se encuentre en la ruta del estado de la aplicación que en el rendimiento bruto del contenido multimedia.
La carga lenta de los pósteres con una reproducción saludable es una razón para medir por separado la capacidad de respuesta del estado de la aplicación y la transmisión multimedia; una matriz de almacenamiento rápida no demuestra que la ruta de la base de datos funcione correctamente.
Mide la latencia del almacenamiento de la base de datos y la respuesta de la biblioteca antes de reconstruir nada. Si mover una copia a un almacenamiento saludable y de baja latencia o reparar los índices cambia el síntoma, mantén el diagnóstico en ese ámbito. Si la base de datos responde correctamente, investiga el comportamiento de la red o de la interfaz del cliente.
Pasa de la reparación al reemplazo solo después de fallos repetidos
Usa la reparación de la base de datos antes del reemplazo cuando el daño esté aislado, exista una copia de seguridad verificada y la integridad pueda volver a comprobarse en una copia. La cuestión es si las lecturas y escrituras normales vuelven a funcionar, no si un único comando de reparación termina correctamente.
Después de la reparación, navega por varias bibliotecas, realiza búsquedas, actualiza un elemento de metadatos, añade un archivo controlado y reinicia Plex. Si los errores de integridad o los fallos de escritura reaparecen de inmediato, deja de repetir el mismo proceso de reparación.
Una reconstrucción limpia de la base de datos solo está justificada cuando las copias reparadas vuelven a dañarse o las copias de seguridad verificadas reproducen el mismo problema estructural. No modifiques el contenido multimedia y reconstruye la base de datos en una nueva ubicación de datos de la aplicación para mantener la posibilidad de volver atrás.
Cuando todavía exista una copia de seguridad utilizable, la recuperación de la base de datos desde una copia verificada debe preceder a una reconstrucción limpia; protege por separado el estado de reproducción, las colecciones y otros datos del usuario que aún puedan recuperarse de la copia defectuosa.
Soporte y Consejos
Más para leer

¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...

Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...

Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...

