Porque é que o Home Assistant reprocessa os dados existentes depois de uma atualização?

O Home Assistant pode voltar a processar dados existentes após uma atualização porque o novo código tem de reconciliar esquemas armazenados, índices, caches, estatísticas e o estado das integrações com as novas expectativas.

As leituras originais dos sensores não estão necessariamente a ser recolhidas novamente. Em vez disso, o sistema atualizado pode transformar tabelas, reconstruir estruturas derivadas, recarregar entradas de configuração ou recalcular resumos para que o estado antigo continue utilizável na nova versão. A duração depende do volume de dados, da latência do armazenamento, do espaço temporário disponível, do número de integrações, do motor da base de dados e do caminho exato de atualização.

Uma atualização altera a forma como o estado existente é interpretado

O Home Assistant conserva mais do que texto de configuração. As tabelas do Recorder, os registos de entidades, os metadados dos dispositivos, as entradas das integrações, as estatísticas e as caches incorporam pressupostos da versão que os gravou. Quando o novo código altera esses pressupostos, tem de traduzir o estado existente ou gerar novamente uma representação compatível antes da utilização normal.

Este é o objetivo geral de uma migração de software controlada: transferir dados e comportamento de uma representação antiga para uma nova sem perder o resultado pretendido. A visão geral do The Pragmatic Engineer sobre fases de migração de software separa a preparação, a execução, o trabalho pós-migração e a fase prolongada posterior, explicando por que motivo a conclusão se estende para além da instalação do novo código.

O reprocessamento é, portanto, uma operação de compatibilidade, não uma prova de que o Home Assistant se esqueceu dos dados de origem. As questões importantes são que representação armazenada mudou, se o trabalho está a avançar e que funções continuam disponíveis. Versões diferentes podem não tocar em nenhuma, numa ou em várias destas camadas.

As migrações de esquema podem ler e reescrever tabelas grandes

Um esquema de base de dados define tabelas, colunas, tipos, índices e restrições. Uma atualização pode adicionar uma coluna, alargar um identificador, reconstruir um índice ou transformar linhas num novo formato. Operações que parecem pequenas nas notas de lançamento podem analisar ou copiar uma base de dados grande do Recorder e gerar uma quantidade significativa de E/S temporária.

Uma migração do Recorder do Home Assistant observada registou a remoção e recriação de índices numa base de dados de vários gigabytes, incluindo um aviso de que a criação de índices poderia demorar vários minutos em bases de dados grandes ou em hardware mais lento.

O trabalho depende do número de linhas afetadas e do comportamento do armazenamento, não apenas da percentagem de CPU. Uma migração pode estar limitada pelas E/S, por bloqueios ou pelo motor da base de dados, enquanto a utilização do processador parece baixa. Interrompê-la repetidamente pode reiniciar o trabalho ou deixar o sistema a exigir validação, pelo que o progresso e os registos são mais importantes do que uma estimativa arbitrária baseada no tempo decorrido.

Os índices derivados e as caches têm de corresponder ao novo código

Os índices, as caches, os recursos compilados e as estruturas de pesquisa são derivados dos dados autoritativos. Reutilizá-los depois de alterado o seu formato ou as regras de invalidação poderia devolver entidades obsoletas, consultas incorretas ou recursos incompatíveis da interface. Eliminá-los e reconstruí-los troca trabalho temporário por um resultado consistente na nova versão.

A consistência da cache depende da remoção das entradas cujos pressupostos de origem foram alterados. O relato técnico da Meta sobre invalidação e consistência de caches explica que uma cache não é a fonte de verdade e pode permanecer indefinidamente inconsistente quando a invalidação é tratada de forma incorreta.

Este mecanismo explica por que motivo o primeiro arranque ou o primeiro carregamento do painel pode ser mais lento do que os seguintes. Assim que existir um estado derivado compatível, os acessos posteriores reutilizam-no. Se a mesma reconstrução dispendiosa se repetir em todos os reinícios, investigue por que razão o resultado não está a ser confirmado ou reconhecido, em vez de o aceitar como um aquecimento normal.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

As integrações reconciliam dispositivos, entidades e sessões

Cada integração tem de restaurar credenciais, estabelecer sessões, detetar dispositivos, associar identificadores e atualizar a disponibilidade das entidades. Uma atualização pode alterar a lógica de configuração, os modelos de entidades, as versões das bibliotecas ou os processadores de migração. A configuração existente é então recarregada através do novo código para que a integração produza um estado consistente com o ambiente de execução atual.

O comportamento de recarregamento das integrações torna este ciclo visível. Uma explicação da comunidade sobre recarregamentos das entradas de configuração do Home Assistant identifica a ação de recarregamento que descarrega e configura novamente uma integração, o mesmo limite geral de reconciliação exercido durante o arranque.

Uma API na cloud, um dispositivo com bateria em suspensão ou um gateway indisponível podem prolongar a reconciliação independentemente do trabalho da base de dados. A ausência de entidades durante o arranque inicial pode ser temporária, mas falhas de autenticação repetidas ou alterações contínuas de identificadores não são sinais de progresso saudável. Separe as novas tentativas das integrações dos registos de migração do Recorder antes de atribuir a causa.

As estatísticas podem ser reconstruídas a partir do histórico retido

O Home Assistant mantém o histórico de estados bruto ou de curta duração juntamente com estatísticas derivadas utilizadas nas vistas de longo prazo. Quando uma regra de cálculo, uma relação de metadados ou uma estrutura de resumo é alterada, pode ser necessário reler as linhas retidas para reparar ou gerar novamente a série derivada. Isto cria leituras e escritas adicionais sem alterar as medições dos dispositivos de origem.

A distinção entre o histórico das entidades e as estatísticas de longo prazo é importante do ponto de vista operacional. Um guia detalhado da comunidade sobre recuperação de estatísticas do Home Assistant trata as estatísticas resumidas como uma camada de dados separada, que pode ser reconstruída ou movida independentemente do histórico efémero.

Um resumo reconstruído deverá convergir para valores estáveis e um volume normal de escritas. Esteja atento a lacunas, duplicados, identificadores de metadados que mudam ou a uma tarefa que reinicia sempre no mesmo ponto. Esses padrões sugerem um problema de compatibilidade ou integridade, e não uma passagem finita pelos dados retidos.

O progresso normal tem um padrão diferente do de uma falha

O trabalho pós-atualização esperado tem uma tarefa identificada, progresso crescente ou marcos diferentes nos registos, utilização de recursos limitada e conclusão posterior. Uma falha repete o mesmo erro, esgota o espaço em disco, reinicia a migração, deixa o Recorder indisponível indefinidamente ou produz novos avisos de corrupção. O tempo, por si só, não permite distingui-los de forma fiável, porque as bases de dados e o hardware variam.

Uma migração falhada apresenta uma prova concreta contra a ideia de que esperar é sempre seguro. Numa falha de atualização da base de dados do Home Assistant, a migração ocupou todo o armazenamento disponível da máquina virtual e só avançou depois de aumentada a capacidade, demonstrando que uma falha repetida pode ter um limite de recursos, e não um limite de paciência.

Não elimine uma base de dados apenas porque o arranque está mais lento do que o habitual. Preserve a cópia de segurança anterior à atualização, registe o par exato de versões e observe o espaço livre, a atividade da base de dados e os registos. Escale o problema quando o mesmo erro se repetir, o progresso parar durante vários intervalos de observação ou os serviços necessários ultrapassarem a janela de indisponibilidade prevista.

Utilize um protocolo de observação pós-atualização faseado

Antes de atualizar, registe o tamanho da base de dados, o espaço livre, o tempo normal de arranque, o número de integrações e o identificador de uma cópia de segurança conhecida como válida. Depois de a nova versão arrancar, verifique as mensagens de migração, o crescimento do armazenamento, a disponibilidade do Recorder, a recuperação das entidades e a consistência das estatísticas em intervalos fixos. Evite cópias de segurança ou análises simultâneas que distorçam a carga do primeiro arranque.

A experiência de migração é mais fácil de interpretar quando os artefactos de recuperação e o estado das versões são documentados antecipadamente. O relato de migração do Home Assistant de um operador ilustra como as cópias de segurança, o comportamento do restauro e as alterações do ambiente passam a fazer parte da transição real, e não de uma reflexão final.

Declare o sucesso apenas quando os registos deixarem de indicar trabalho de migração, o Recorder aceitar novos eventos, o histórico e as estatísticas responderem às verificações, as integrações estabilizarem e um segundo reinício regressar a um valor próximo da linha de base esperada. Mantenha disponível o caminho de recuperação da ZimaSpace para uma cópia de segurança conhecida como válida da base de dados, mas utilize-o apenas depois de a falha observada ultrapassar o limiar de recuperação.