Señales de que una base de datos de Immich necesita mantenimiento o reemplazo

Una base de datos de Immich que simplemente funciona con lentitud puede necesitar mantenimiento rutinario de PostgreSQL o una corrección de recursos; una base de datos que muestra fallos repetidos de integridad o recuperación puede necesitar restaurarse o reemplazarse a partir de una copia de seguridad verificada.

No uses «reconstruir la base de datos» como solución genérica de rendimiento. Primero distingue entre crecimiento normal, bloat, estadísticas obsoletas, mantenimiento bloqueado y latencia del almacenamiento, por un lado, y corrupción o un estado irrecuperable del clúster, por otro. Conserva un punto de recuperación antes de realizar trabajos invasivos, mide un cambio de mantenimiento a la vez y recurre a una restauración limpia solo cuando las pruebas indiquen que no se puede confiar en la base de datos actual o repararla de forma segura.

Distingue el deterioro del rendimiento de los fallos de integridad

Comienza con el síntoma exacto: búsquedas lentas, consultas lentas de la línea de tiempo, tamaño excesivo de la base de datos, mucha actividad de disco, errores repetidos de PostgreSQL, bucles de recuperación tras fallos o una migración de Immich que no puede completarse. Los síntomas de rendimiento y los de integridad implican riesgos diferentes y no deberían tener la misma primera reparación.

Confirma que el host todavía tenga un almacenamiento saludable, suficiente espacio libre, un comportamiento normal de la memoria y ningún trabajo en segundo plano descontrolado de Immich antes de culpar a PostgreSQL. Un disco saturado o defectuoso puede hacer que una base de datos sana parezca lenta y también causar daños reales si el almacenamiento subyacente deja de ser fiable.

Conserva los registros, la versión de la base de datos, las versiones de las extensiones, el historial reciente de actualizaciones y una copia de seguridad o instantánea antes de realizar mantenimiento invasivo. Si la única copia de la base de datos podría estar dañada, no ejecutes una limpieza destructiva solo para comprobar si el error desaparece; conserva las pruebas necesarias para decidir una restauración controlada.

Busca señales de mantenimiento que puedas medir

El mantenimiento rutinario se convierte en una opción razonable cuando la base de datos se inicia y sigue siendo utilizable internamente, pero el rendimiento de las consultas o el espacio ocupado en disco empeora con el tiempo. Entre las pruebas útiles se incluyen filas muertas acumuladas, tablas o índices que crecen de forma desproporcionada, autovacuum incapaz de mantenerse al día, estadísticas obsoletas del planificador o tareas de mantenimiento prolongadas bloqueadas por otras sesiones.

Las tuplas muertas, el bloat, la presión por congelamiento, un VACUUM bloqueado y una frecuencia de vacuum insuficiente pueden afectar al mantenimiento y al rendimiento de las consultas de PostgreSQL. Usa las señales de VACUUM a nivel de tabla a lo largo del tiempo en lugar de asumir que un archivo grande de la base de datos demuestra por sí solo que esta debe reemplazarse.

Si las estadísticas apuntan a una tabla o un índice concretos, elige la acción de mantenimiento compatible y menos invasiva para ese hallazgo y vuelve a medir. Evita pasar directamente a VACUUM FULL, a operaciones REINDEX generales o a ajustes arbitrarios de autovacuum en todo el clúster; esas acciones pueden generar bloqueos, E/S o una demanda adicional de disco, y quizá no resuelvan el verdadero cuello de botella.

Confirma si el bloat o el crecimiento de los índices coinciden con la ruta lenta

Compara los objetos implicados en las operaciones lentas de Immich con el tamaño de las tablas y los índices, la rotación de filas y el comportamiento de las consultas. El bloat es relevante cuando aumenta el trabajo necesario para encontrar filas útiles o hace que los índices sean menos eficaces, pero la base de datos también puede ser grande simplemente porque la biblioteca y los metadatos son grandes.

El bloat de tablas y de índices debe evaluarse por separado, porque un bloat excesivo puede aumentar el trabajo necesario para las consultas sin implicar corrupción de la base de datos. Usa comprobaciones medidas del bloat de PostgreSQL para actuar sobre un objeto observado y actualizar las estadísticas del planificador cuando corresponda, en lugar de tratar el tamaño total de la base de datos como el diagnóstico.

Después del mantenimiento, vuelve a ejecutar exactamente la acción de Immich que era lenta y compara tanto la latencia visible para el usuario como el comportamiento de la base de datos y el almacenamiento. Si la operación no mejora, revierte los ajustes anteriores cuando sea posible e investiga el almacenamiento, los patrones de consulta, los trabajos en segundo plano o las causas de la aplicación, en lugar de acumular más cambios en la base de datos.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Recurre a la restauración o al reemplazo cuando la integridad sea incierta

El reemplazo se justifica por pruebas de que no se puede confiar en el estado actual de PostgreSQL o recuperarlo de forma segura, no por su antigüedad. Algunos ejemplos son la corrupción repetida de páginas o sumas de comprobación, fallos de inicio o recuperación que persisten en un almacenamiento saludable, un clúster dañado tras un incidente de almacenamiento incompleto o un estado de migración que no puede repararse mediante el procedimiento compatible.

Antes de declarar perdida la base de datos, demuestra que una copia de seguridad conocida como correcta puede restaurarse en un entorno PostgreSQL limpio y compatible, y que Immich puede leerla. Si la restauración limpia funciona mientras el clúster actual repite el mismo fallo de integridad, tendrás una base mucho más sólida para reemplazar el estado de la base de datos en lugar de continuar con la reparación local.

Repara los fallos localizados y reversibles mientras conservas el estado persistente incierto; reconstruye solo cuando la fuente de recuperación esté verificada y el destino sea reproducible. Aplica también a la base de datos ese límite entre reparar y reconstruir Immich. «Reemplazo» debe significar restaurar un estado compatible de PostgreSQL desde una fuente conocida como correcta, no cambiar de base de datos porque una consulta se volvió lenta.

Valida la base de datos mediante operaciones de lectura, escritura y copia de seguridad

Tanto si realizaste mantenimiento como si restauraste una base de datos limpia, valida el resultado mediante Immich en lugar de detenerte tras un inicio correcto de PostgreSQL. Abre álbumes y recursos antiguos, ejecuta búsquedas, carga vídeos representativos y verifica que los usuarios y el estado de uso compartido aparezcan como se espera.

Realiza una escritura nueva y segura, como subir un recurso desechable, y confirma que siga siendo accesible después de reiniciar normalmente el servicio. Observa los registros de PostgreSQL e Immich en busca de errores recurrentes de integridad, migración, extensiones o permisos mientras las rutas de lectura y escritura estén activas.

Por último, crea una copia de seguridad nueva de la base de datos mediante tu método habitual y pruébala restaurándola en un destino aislado cuando sea práctico. La decisión de mantenimiento o reemplazo solo estará completa cuando el sistema actual sea utilizable y el siguiente punto de recuperación sea demostrablemente más saludable que el estado que desencadenó el incidente.