När bör Home Assistant använda en separat databas- eller lagringsvärd?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

When Should Home Assistant Use a Separate Database or Storage Host? - Zima Store Online

Home Assistant bör endast använda en separat databas- eller lagringsvärd när den separationen löser ett uppmätt problem med kapacitet, lagringstid, säkerhetskopiering eller feldomän. Att flytta tillståndet från styrenheten är inte automatiskt en uppgradering.

För många hem är en lokal SQLite Recorder-databas på tillförlitlig SSD-lagring den enklaste lösningen, eftersom det eliminerar beroenden av nätverk, autentisering, DNS och uppstart av databasservern. Innan du skapar en till värd bör du först fastställa om det verkliga problemet är för många Recorder-skrivningar, lång lagringstid, långsamma historikfrågor, begränsad lokal kapacitet eller behovet av att återställa en tjänst oberoende av andra.

Finjustera Recorder innan du lägger till en databasserver

Recorder-tillväxten styrs av vilka entiteter och händelser som lagras, hur ofta de ändras och hur länge historiken sparas. Om brusiga sensorer eller onödiga domäner står för merparten av skrivningarna flyttar du bara problemet till en större databasserver i stället för att lösa det.

Ett aktuellt arbetsflöde för finjustering av Recorder visar hur lagringstid, inkluderings- och exkluderingsregler samt commit-beteende påverkar skrivbelastningen innan en databasflytt övervägs. Mät databasens storlek, tiden för historikfrågor, lagringsfördröjningen och skrivaktiviteten efter finjusteringen.

Behåll databasen lokal när den finjusterade belastningen förblir responsiv, säkerhetskopieringar slutförs inom underhållsfönstret och det tillgängliga SSD-utrymmet förblir tillräckligt. Separation bör följa ett krav som inte uppfylls, inte en generell uppfattning om att klient-server-databaser alltid är snabbare.

Använd en extern databas när dess driftsfördelar är verkliga

En separat MariaDB-, MySQL- eller PostgreSQL-värd kan vara rimlig när Home Assistant delar en redan välskött databasplattform, när lång lagringstid skapar ett ihållande frågetryck, när styrenheten måste förbli resurssnål eller utbytbar eller när säkerhetskopiering och övervakning av databasen behöver en oberoende livscykel.

Ett exempel på migrering från SQLite till MariaDB visar vilka nya delar detta val innebär: databastjänst, autentiseringsuppgifter, nätverksadress, initiering av schema, migreringsprocedur, validering och återställning. Ett större verkligt fall med migrering av en Home Assistant-databas visar varför lång historik och stora datamängder kan motivera den extra administrationen.

ZimaSpace-artikeln om tillförlitlighet vid uppgraderingar med extern databas beskriver motsvarande underhållsgräns: databasen måste säkerhetskopieras, uppgraderas och återställas som en egen tjänst i stället för att behandlas som osynlig infrastruktur.

Lägg inte som standard en aktiv SQLite-databas på en nätverksresurs

En fjärrdatabasserver och en databasfil som lagras på SMB eller NFS är olika arkitekturer. En klient-server-databas hanterar låsning och transaktioner i själva databastjänsten och skickar förfrågningar över nätverket. SQLite hanterar låsning av databasfilen via filsystemet, så nätverksfilsystemets semantik, monteringsstatus, fördröjning och låsbeteende blir en del av varje transaktion.

Den bredare analysen av SQLite-låsning förklarar varför nätverksfilsystem kan ge ett låsbeteende som skiljer sig från en lokal disk. Ett fall med fel på en nätverksresurs i Home Assistant visar den praktiska risken när den aktiva Recorder-databasen är beroende av en fjärrmontering.

Använd gärna en NAS för säkerhetskopior, exporter, media och andra data som är avsedda för nätverkslagring. Om det aktiva Recorder-tillståndet måste ligga på en annan maskin bör du föredra en klient-server-databas som stöds, i stället för att flytta SQLite-filen till en delad resurs.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Separera bulkdata från Home Assistants aktiva tillstånd

Inte alla växande Home Assistant-kataloger hör hemma på samma lagringsnivå. Konfiguration, integrationstillstånd, den aktiva Recorder-databasen, media, kameraklipp, exporter och säkerhetskopior har olika krav på fördröjning och återställning. Behåll små, ofta uppdaterade tillstånd på lokal lagring med låg fördröjning, om inte en separat tjänst uttryckligen hanterar dem.

Flytta större mängder media eller säkerhetskopior till NAS-kapacitet via stabila monteringspunkter. Dokumentera om Home Assistant får starta utan den monteringen. Ett saknat fotoarkiv bör inte hindra belysningsautomatiseringar från att starta, medan en saknad aktiv databas bör skapa ett tydligt försämrat läge i stället för en tyst reservlösning som ingen märker.

Dat roll	Standardplacering	Skäl att separera
Konfiguration och aktivt tillstånd	Lokal SSD	Låg fördröjning och enkel återställning
Recorder SQLite	Lokal SSD	Undvik beroenden av låsning i nätverksfilsystem
Extern SQL-databas	Lokal eller separat databashost	Oberoende skalning, lagringstid, säkerhetskopiering och administration
Media och exporter	Lokal eller NAS	Kapacitet är ofta viktigare än fördröjning
Säkerhetskopior	Minst en kopia utanför värden	Överlev förlusten av den aktiva värden

Verifiera uppstart, fel och återställning innan du gör uppdelningen permanent

Testa den nya databas- eller lagringsrollen utan att ta bort den gamla återställningsvägen. Starta om databashosten före Home Assistant, starta om Home Assistant innan databasen är klar, avbryt nätverket, rotera autentiseringsuppgifter, fyll målfilsystemet tills det närmar sig reservtröskeln och återställ databasen till en ren instans.

Mät p95-tiden för historikfrågor, automatiseringarnas fördröjning under tung Recorder-aktivitet, omstartstiden, säkerhetskopieringens längd och återställningstiden efter ett avbrott på databashosten. Om uppdelningen förbättrar ett mått men förvandlar en trettio sekunder lång omstart av styrenheten till en återställningsrutin för flera tjänster ska du räkna med den driftskostnaden i beslutet.

Behåll lokal lagring när den redan uppfyller målet. Använd en separat databashost när klient-server-databasens funktioner och oberoende återställning ger verkliga fördelar. Använd en separat lagringshost för bulkdata och säkerhetskopior, men låt inte kritisk lokal styrning vara beroende av ett fjärrfilsystem utan ett testat skäl.