Varför bearbetar Home Assistant befintliga data igen efter en uppgradering?

Home Assistant kan bearbeta befintliga data igen efter en uppgradering eftersom ny kod måste anpassa lagrade scheman, index, cacheminnen, statistik och integrationstillstånd till ändrade förväntningar.

De ursprungliga sensoravläsningarna samlas inte nödvändigtvis in igen. I stället kan det uppgraderade systemet omvandla tabeller, bygga om härledda strukturer, läsa in konfigurationsposter på nytt eller beräkna sammanfattningar igen, så att det gamla tillståndet förblir användbart i den nya versionen. Tidsåtgången beror på datamängden, lagringens svarstid, tillgängligt temporärt utrymme, antalet integrationer, databasmotorn och den exakta versionsvägen.

En uppgradering ändrar hur befintligt tillstånd tolkas

Home Assistant sparar mer än konfigurationstext. Recorder-tabeller, entitetsregister, enhetsmetadata, integrationsposter, statistik och cacheminnen innehåller alla antaganden som gjordes av den version som skrev dem. När den nya koden ändrar dessa antaganden måste den antingen översätta det befintliga tillståndet eller skapa en kompatibel representation på nytt innan normal användning kan återupptas.

Detta är det allmänna syftet med en kontrollerad programvarumigrering: att flytta data och beteende från en gammal representation till en ny utan att förlora det avsedda resultatet. The Pragmatic Engineers översikt över migreringssteg för programvara skiljer mellan förberedelse, genomförande, arbete efter migreringen och den långvariga efterfasen, vilket förklarar varför processen fortsätter efter att den nya koden har installerats.

Omarbetning är därför en kompatibilitetsåtgärd, inte ett bevis på att Home Assistant har glömt källdatan. De viktiga frågorna är vilken lagrad representation som ändrades, om arbetet går framåt och vilka funktioner som fortfarande är tillgängliga. Olika versioner kan beröra inget, ett eller flera av dessa lager.

Schemamigreringar kan läsa och skriva om stora tabeller

Ett databasschema definierar tabeller, kolumner, datatyper, index och begränsningar. En uppgradering kan lägga till en kolumn, utöka en identifierare, bygga om ett index eller omvandla rader till en ny layout. Åtgärder som verkar små i versionsinformationen kan skanna eller kopiera en stor Recorder-databas och skapa betydande mängder temporär I/O.

En observerad migrering av Home Assistant Recorder loggade borttagning och återskapande av index i en databas på flera gigabyte, inklusive en varning om att indexskapandet kunde ta flera minuter i stora databaser eller på långsammare hårdvara.

Arbetet skalas efter antalet berörda rader och lagringens beteende, inte bara efter CPU-belastningen. En migrering kan vara I/O-bunden, låsningsbunden eller begränsad av databasmotorn medan processoranvändningen ser låg ut. Om du avbryter den upprepade gånger kan arbetet behöva startas om eller systemet behöva valideras, så framsteg och loggar är viktigare än en godtycklig uppskattning av förfluten tid.

Härledda index och cacheminnen måste stämma med den nya koden

Index, cacheminnen, kompilerade resurser och uppslagsstrukturer härleds från auktoritativa data. Om de återanvänds efter att deras format eller regler för ogiltigförklaring har ändrats kan de ge inaktuella entiteter, felaktiga frågor eller inkompatibla resurser i gränssnittet. Att kasta bort och bygga om dem byter tillfälligt mer arbete mot ett konsekvent resultat i den nya versionen.

Cachekonsistens beror på att poster vars källantaganden har ändrats tas bort. Metas tekniska redogörelse för ogiltigförklaring och konsistens i cacheminnen förklarar att ett cacheminne inte är sanningskällan och kan förbli inkonsekvent på obestämd tid när ogiltigförklaringen hanteras fel.

Detta förklarar varför den första starten eller den första laddningen av en instrumentpanel kan vara långsammare än senare. När ett kompatibelt härlett tillstånd finns kan senare åtkomst återanvända det. Om samma dyra ombyggnad upprepas vid varje omstart bör du undersöka varför resultatet inte sparas eller känns igen, i stället för att acceptera det som normal uppvärmning.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Integrationer synkroniserar enheter, entiteter och sessioner

Varje integration måste återställa autentiseringsuppgifter, upprätta sessioner, upptäcka enheter, koppla identifierare och uppdatera entiteternas tillgänglighet. En uppgradering kan ändra konfigurationslogik, entitetsmodeller, biblioteksversioner eller migreringshanterare. Den befintliga konfigurationen läses då in på nytt genom den nya koden, så att integrationen kan skapa ett tillstånd som stämmer med den aktuella körmiljön.

Integrationernas omladdningsbeteende gör denna livscykel synlig. En förklaring i communityt av omladdning av Home Assistants konfigurationsposter beskriver åtgärden som kopplar bort en integration och konfigurerar den igen, vilket är samma övergripande synkroniseringsgräns som används under starten.

Ett moln-API, en vilande batteridriven enhet eller en otillgänglig gateway kan förlänga synkroniseringen oberoende av databasarbete. Saknade entiteter under den tidiga starten kan vara tillfälliga, men upprepade autentiseringsfel eller identifierare som hela tiden ändras är inte tecken på hälsosamma framsteg. Separera integrationsförsök från Recorder-migreringsloggar innan du fastställer orsaken.

Statistik kan byggas om från sparad historik

Home Assistant sparar rå eller kortlivad tillståndshistorik tillsammans med härledd statistik som används i vyer över längre tid. När en beräkningsregel, metadatarelation eller sammanfattningsstruktur ändras kan sparade rader behöva läsas igen för att reparera eller skapa den härledda serien på nytt. Det skapar ytterligare läsningar och skrivningar utan att ändra de ursprungliga mätningarna från enheten.

Skillnaden mellan entitetshistorik och långtidsstatistik är viktig i drift. En detaljerad guide i communityt om återställning av Home Assistant-statistik behandlar sammanfattad statistik som ett separat datalager som kan återskapas eller flyttas oberoende av den kortlivade historiken.

En ombyggd sammanfattning bör närma sig stabila värden och normal skrivvolym. Håll utkik efter luckor, dubbletter, metadataidentifierare som ändras eller ett jobb som startar om från samma punkt. Sådana mönster tyder på ett kompatibilitets- eller integritetsproblem snarare än en ändlig genomgång av sparade data.

Normala framsteg ser annorlunda ut än fel

Förväntat arbete efter en uppgradering har en namngiven uppgift, ökande framsteg eller ändrade milstolpar i loggen, begränsad resursanvändning och ett slut. Fel visar sig genom att samma fel upprepas, diskutrymme tar slut, migreringen startar om, Recorder förblir otillgänglig under obegränsad tid eller nya varningar om korruption uppstår. Tiden ensam kan inte pålitligt skilja dem åt eftersom databaser och hårdvara skiljer sig åt.

En misslyckad migrering ger konkreta motbevis mot tanken att det alltid är säkert att vänta. I ett fall med misslyckad databasuppgradering i Home Assistant fyllde migreringen det tillgängliga lagringsutrymmet på den virtuella maskinen och kunde fortsätta först efter att kapaciteten ökats. Det visar att upprepade fel kan bero på en resursgräns snarare än brist på tålamod.

Ta inte bort en databas bara för att starten är långsammare än vanligt. Bevara säkerhetskopian före uppgraderingen, notera det exakta versionsparet och övervaka ledigt utrymme, databasaktivitet och loggar. Eskalera när samma fel återkommer, framstegen upphör under flera observationsintervall eller nödvändiga tjänster överskrider det planerade avbrottsfönstret.

Använd ett stegvis protokoll för observation efter uppgraderingen

Före uppgraderingen bör du notera databasens storlek, ledigt utrymme, normal starttid, antal integrationer och identifieraren för en känd fungerande säkerhetskopia. När den nya versionen har startat kontrollerar du migreringsmeddelanden, förändringar i lagringsutrymmet, Recorders tillgänglighet, återställningen av entiteter och statistikens konsistens med fasta intervall. Undvik överlappande säkerhetskopieringar eller skanningar som skulle förvränga belastningen vid den första starten.

Det är lättare att tolka migreringsförloppet när återställningsartefakter och versionsstatus dokumenteras i förväg. En användares redogörelse för en Home Assistant-migrering visar hur säkerhetskopior, återställningsbeteende och förändringar i miljön blir en del av den verkliga övergången i stället för en sista eftertanke.

Förklara inte migreringen som lyckad förrän loggarna har slutat rapportera migreringsarbete, Recorder tar emot nya händelser, historik och statistik svarar på kontroller, integrationerna har stabiliserats och en andra omstart återgår till ungefär den förväntade grundnivån. Ha ZimaSpace-återställningsvägen för en känd fungerande databassäkerhetskopia tillgänglig, men använd den först när det observerade felet har passerat återställningströskeln.