Sinais de que uma base de dados do Immich precisa de manutenção ou substituição

Uma base de dados do Immich que está apenas lenta pode precisar de manutenção de rotina do PostgreSQL ou de uma correção de recursos; uma base de dados que apresenta falhas repetíveis de integridade ou recuperação pode precisar de ser restaurada ou substituída a partir de uma cópia de segurança verificada.

Não use “reconstruir a base de dados” como uma solução genérica de desempenho. Primeiro, distinga o crescimento normal, a fragmentação, as estatísticas desatualizadas, a manutenção bloqueada e a latência do armazenamento da corrupção ou de um estado irrecuperável do cluster. Preserve um ponto de recuperação antes de intervenções invasivas, avalie uma alteração de manutenção de cada vez e avance para uma restauração limpa apenas quando as evidências indicarem que a base de dados atual não é fiável ou não pode ser reparada em segurança.

Distinga a Degradação do Desempenho de uma Falha de Integridade

Comece pelo sintoma exato: pesquisas lentas, consultas lentas da cronologia, base de dados de grandes dimensões, atividade elevada do disco, erros repetidos do PostgreSQL, ciclos de recuperação após falhas ou uma migração do Immich que não consegue ser concluída. Os sintomas de desempenho e os sintomas de integridade envolvem riscos diferentes e não devem ter a mesma primeira solução.

Confirme que o anfitrião continua a ter armazenamento saudável, espaço livre suficiente, utilização normal da memória e nenhum trabalho em segundo plano do Immich fora de controlo antes de culpar o PostgreSQL. Um disco saturado ou com falhas pode fazer uma base de dados saudável parecer lenta e também causar danos reais na base de dados se o armazenamento subjacente se tornar pouco fiável.

Preserve os registos, a versão da base de dados, as versões das extensões, o histórico recente de atualizações e uma cópia de segurança ou instantâneo antes de efetuar manutenção invasiva. Se a única cópia da base de dados puder estar corrompida, não execute uma limpeza destrutiva apenas para verificar se o erro desaparece; mantenha as evidências necessárias para uma decisão de restauração controlada.

Procure Sinais de Manutenção que Possam ser Medidos

A manutenção de rotina torna-se uma opção plausível quando a base de dados arranca e permanece utilizável internamente, mas o desempenho das consultas ou o espaço ocupado em disco piora ao longo do tempo. As evidências úteis incluem linhas mortas acumuladas, tabelas ou índices que crescem de forma desproporcional, o autovacuum que não consegue acompanhar o ritmo, estatísticas desatualizadas do planeador ou manutenção prolongada bloqueada por outras sessões.

Tuplos mortos, fragmentação, pressão de congelamento, VACUUM bloqueado e uma frequência de vacuum insuficiente podem afetar a manutenção e o desempenho das consultas do PostgreSQL. Utilize sinais de VACUUM ao nível da tabela ao longo do tempo, em vez de presumir que um ficheiro de base de dados grande, por si só, prova que a base de dados precisa de ser substituída.

Se as estatísticas apontarem para uma tabela ou índice específico, escolha a ação de manutenção suportada e menos invasiva para essa constatação e faça uma nova medição. Evite avançar diretamente para VACUUM FULL, operações amplas de REINDEX ou ajustes arbitrários do autovacuum em todo o cluster; essas ações podem criar bloqueios, E/S ou uma procura adicional de espaço em disco e podem não resolver o verdadeiro estrangulamento.

Confirme se a Fragmentação ou o Crescimento dos Índices Correspondem ao Percurso Lento

Compare os objetos envolvidos nas operações lentas do Immich com o tamanho das tabelas e dos índices, a alteração das linhas e o comportamento das consultas. A fragmentação é relevante quando aumenta o trabalho necessário para encontrar linhas úteis ou torna os índices menos eficazes, mas a base de dados também pode ser grande simplesmente porque a biblioteca e os metadados são grandes.

A fragmentação das tabelas e dos índices deve ser avaliada separadamente, porque uma fragmentação excessiva pode aumentar o trabalho necessário para as consultas sem implicar corrupção da base de dados. Utilize verificações medidas da fragmentação do PostgreSQL para visar um objeto observado e atualize as estatísticas do planeador quando for apropriado, em vez de tratar o tamanho total da base de dados como o diagnóstico.

Após a manutenção, repita exatamente a ação do Immich que estava lenta e compare tanto a latência visível para o utilizador como o comportamento da base de dados e do armazenamento. Se a operação não melhorar, reverta, quando possível, os ajustes anteriores e investigue o armazenamento, os padrões das consultas, os trabalhos em segundo plano ou as causas ao nível da aplicação, em vez de acumular mais alterações na base de dados.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Avance para a Restauração ou Substituição Quando a Integridade for Incerta

A substituição justifica-se por evidências de que o estado atual do PostgreSQL não é fiável ou não pode ser recuperado em segurança, e não apenas pela sua idade. Os exemplos incluem corrupção repetível de páginas ou somas de verificação, falhas de arranque ou recuperação que persistem num armazenamento saudável, um cluster danificado após um incidente de armazenamento incompleto ou um estado de migração que não pode ser reparado através do procedimento suportado.

Antes de declarar a base de dados perdida, prove que uma cópia de segurança reconhecidamente válida pode ser restaurada num ambiente PostgreSQL limpo e compatível e que o Immich a consegue ler. Se a restauração limpa funcionar enquanto o cluster atual repete a mesma falha de integridade, terá uma justificação muito mais sólida para substituir o estado da base de dados, em vez de continuar a repará-lo no local.

Repare falhas localizadas e reversíveis, preservando o estado persistente incerto; reconstrua apenas quando a origem da recuperação estiver verificada e o destino puder ser reproduzido. Aplique também à base de dados esse limite entre reparar e reconstruir o Immich. “Substituição” deve significar restaurar um estado PostgreSQL compatível a partir de uma origem reconhecidamente válida, e não mudar de base de dados porque uma consulta ficou lenta.

Valide a Base de Dados Através de Operações de Leitura, Escrita e Cópia de Segurança

Quer tenha efetuado manutenção ou restaurado uma base de dados limpa, valide o resultado através do Immich, em vez de ficar apenas por um arranque bem-sucedido do PostgreSQL. Abra álbuns e recursos antigos, faça pesquisas, carregue vídeos representativos e verifique se os utilizadores e o estado das partilhas aparecem como esperado.

Efetue uma nova escrita segura, como carregar um recurso descartável, e confirme que este continua acessível após um reinício normal do serviço. Observe os registos do PostgreSQL e do Immich para detetar erros recorrentes de integridade, migração, extensões ou permissões enquanto os percursos de leitura e escrita estiverem ativos.

Por fim, crie uma cópia de segurança nova da base de dados utilizando o seu método habitual e, quando for viável, teste a restauração num destino isolado. A decisão de manutenção ou substituição só fica concluída quando o sistema atual estiver utilizável e o próximo ponto de recuperação for comprovadamente mais saudável do que o estado que desencadeou o incidente.