O Immich pode utilizar uma base de dados externa sem comprometer as atualizações?

O Immich pode apontar para um serviço PostgreSQL externo, mas isso não torna as atualizações automaticamente seguras; transfere para fora da stack predefinida a responsabilidade pela versão da base de dados, extensões, privilégios, cópias de segurança e reversão.

Considere uma base de dados externa como um limite de compatibilidade avançado, não como uma simples opção de desempenho. Antes de cada atualização do Immich ou do PostgreSQL, verifique os requisitos da versão exata do Immich que pretende executar, confirme que o servidor externo pode fornecer as extensões e os privilégios necessários, faça uma cópia de segurança restaurável e altere apenas uma camada de atualização de cada vez, para saber qual componente introduziu uma falha.

Comece pelo contrato da base de dados externa

Documente o endpoint da base de dados, o nome da base de dados, a conta de serviço, o modo TLS, a versão principal do PostgreSQL, os nomes e versões das extensões instaladas e quem pode atualizar essas extensões. Mantenha este registo junto da definição da implementação do Immich, para que a recriação de um contentor não estabeleça silenciosamente ligação a outro servidor ou base de dados.

É possível utilizar um servidor PostgreSQL pré-existente, mas essa não é a configuração predefinida recomendada pelo Immich. Nas versões atuais, o caminho com uma base de dados autónoma requer pgvector e VectorChord; é sabido que o Immich funciona com PostgreSQL 14 a 19, pgvector >=0.7 e <0.9, e VectorChord >=0.3 e <2.0. Volte a confirmar estes intervalos antes de cada atualização, pois podem sofrer alterações.

Planeie os privilégios antes da migração. Normalmente, o Immich espera uma função da base de dados com permissões de superutilizador; executar sem essas permissões é um caminho avançado que pode exigir intervenção manual durante as atualizações, e as cópias de segurança automatizadas atuais da base de dados requerem permissões de superutilizador. Se o seu fornecedor externo não conseguir cumprir estes requisitos, pare antes de transferir o estado de produção.

Verifique a compatibilidade do PostgreSQL e das extensões antes de alterar qualquer coisa

Indique as versões atuais e de destino do PostgreSQL, juntamente com todas as extensões das quais o Immich depende. Uma atualização principal do PostgreSQL pode exigir binários de extensões compilados para a versão principal de destino, enquanto uma atualização do Immich pode exigir uma extensão mais recente ou um comportamento de migração diferente, mesmo que o próprio PostgreSQL continue a iniciar.

Os ficheiros dos pacotes das extensões e o estado das extensões SQL têm de ser atualizados deliberadamente com a base de dados, em vez de se presumir que acompanham uma atualização do PostgreSQL. Consulte as dependências de atualização das extensões do PostgreSQL antes de alterar a versão principal da base de dados ou os pacotes de extensões exigidos pelo Immich.

Se o seu fornecedor externo não permitir instalar ou atualizar a extensão necessária, alterar as definições de pré-carregamento partilhado quando exigido ou conceder os privilégios necessários à migração, pare antes de atualizar o Immich. Uma base de dados que aceite consultas comuns pode continuar a ser inadequada para a próxima migração da aplicação.

Mantenha as atualizações principais da base de dados separadas das atualizações do Immich

Evite combinar uma atualização principal do PostgreSQL, uma atualização de extensões e uma atualização da aplicação Immich no mesmo período de manutenção, a menos que já tenha ensaiado toda a sequência. Quando vários limites de compatibilidade mudam em simultâneo, uma falha no arranque deixa de indicar qual foi a camada responsável.

As atualizações menores do PostgreSQL e as atualizações de versões principais são eventos de manutenção diferentes, e as atualizações principais exigem que o ambiente de destino — incluindo as extensões de terceiros — seja preparado previamente. Mantenha as atualizações de versões principais do PostgreSQL separadas de uma atualização da aplicação Immich sempre que possível, para que uma falha no arranque ainda tenha uma alteração clara para investigar.

Num servidor doméstico, a sequência de menor risco costuma ser: criar cópias de segurança, verificar uma restauração, atualizar uma camada, executar a validação e só depois continuar. Se uma versão do Immich exigir uma alteração na base de dados, siga a ordem prescrita para essa versão, em vez de aplicar uma receita genérica de atualização do PostgreSQL.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Preserve um caminho de reversão que abranja a base de dados e os ficheiros multimédia

Uma base de dados externa facilita esquecer que o estado do Immich está dividido entre o PostgreSQL e a biblioteca multimédia. Faça uma cópia de segurança da base de dados através de um método consistente e preserve o estado relevante dos ficheiros multimédia e da configuração no mesmo período de recuperação, antes de uma migração que possa alterar esquemas ou metadados de recursos.

O estado da base de dados, os ficheiros da aplicação, a configuração e os carregamentos têm de estar sincronizados no momento da restauração. Use uma cópia de segurança consistente do contentor da base de dados como modelo de aceitação, e não apenas o facto de o PostgreSQL iniciar.

Não considere a reversão preparada até saber o que acontece a ambos os lados se a migração da aplicação for concluída apenas parcialmente. Mantenha a versão antiga da aplicação, a definição da implementação, a cópia de segurança da base de dados e o estado dos ficheiros multimédia disponíveis durante tempo suficiente para recuperar sem substituir o único exemplar conhecido como funcional por um estado mais recente.

Valide a atualização como uma aplicação, não apenas como uma ligação à base de dados

Após a alteração, confirme que o PostgreSQL aceita a função do Immich pretendida, que as extensões necessárias estão presentes nas versões esperadas e que a migração do Immich é concluída sem erros repetidos da base de dados. Uma ligação TCP bem-sucedida ou um `SELECT 1` prova a conectividade, não a compatibilidade com a aplicação.

Em seguida, utilize o Immich normalmente: carregue álbuns antigos, abra fotografias e vídeos representativos, pesquise, verifique os utilizadores ou a partilha quando relevante e carregue um recurso descartável. Durante estas ações, acompanhe os registos da aplicação e da base de dados à procura de extensões em falta, erros de permissões, falhas de migração ou novas tentativas repetidas.

Só depois de a aplicação passar estas verificações deverá retomar a retenção normal das cópias de segurança e remover a cópia de reversão. Se a base de dados externa fizer com que as atualizações rotineiras do Immich dependam repetidamente de trabalho manual com extensões ou privilégios que não consegue ensaiar de forma fiável, o ciclo de vida predefinido de uma base de dados dedicada será a opção operacional mais segura.