Home Assistant 업데이트 동작: 스키마와 캐시 변경이 시작에 영향을 미치는 이유

Home Assistant는 업데이트 후 스키마 마이그레이션, 캐시 재구축, 통합 구성 요소 재초기화로 인해 정상 작동 전에 일회성 작업이 추가되면서 시작이 느려질 수 있습니다.

일반적인 재시작은 대부분 익숙한 구성을 다시 읽고 기존 데이터를 여는 정도지만, 버전이 변경되면 이러한 전제가 달라질 수 있습니다. 코어는 Recorder 스키마를 업그레이드하거나, 생성된 아티팩트를 무효화하거나, 변경된 종속성을 로드하거나, 통합 구성 요소가 내부 상태를 다시 구축하도록 만들 수 있습니다. 지연은 대개 일시적이지만, 마이그레이션 중단, 느린 디스크 또는 호환되지 않는 통합 구성 요소로 인해 예상된 첫 시작 작업이 실제 서비스 중단으로 이어질 수 있습니다.

업데이트로 영구 데이터 계약이 변경될 수 있습니다

Home Assistant 버전이 저장된 데이터를 항상 동일한 방식으로 해석하는 것은 아닙니다. Recorder 테이블, 인덱스, 레지스트리 또는 통합 구성 요소의 저장 형식이 변경되면, 모든 소비자가 새 형식을 안전하게 사용할 수 있도록 시작 과정에서 이전 표현을 변환해야 합니다.

운영자들은 업그레이드 후 데이터베이스 변환이 장시간 계속된 사례를 보고했으며, 이는 스키마 변환 작업이 관련 없는 백그라운드 작업이 아니라 시작 과정의 일부임을 보여 줍니다.

영향을 받는 데이터의 양과 다시 작성해야 하는 인덱스 수가 많을수록 비용이 증가합니다. 버전 변경이 없는 재시작에서는 이 변환을 건너뛰므로, 이를 업데이트 후 첫 부팅과 비교하면 달라진 작업량을 놓치게 됩니다.

캐시 무효화로 인해 재시작 때는 재사용하는 작업이 반복됩니다

캐시는 코드, 프런트엔드 번들, 종속성 및 이전에 가져온 데이터에 대한 전제를 담고 있습니다. 업데이트로 인해 이러한 아티팩트가 의도적으로 무효화되면 서버, 브라우저, 프록시 또는 통합 구성 요소가 이를 다시 다운로드하거나 구문 분석하거나 컴파일하거나 디코딩해야 할 수 있습니다.

데이터를 로드하는 동안 멈춘 것처럼 보였던 업데이트 후 사례는 업데이트 후 초기화가 통합 구성 요소 초기화와 겹치면서 프로세스가 시작된 뒤 실제로 사용할 수 있는 화면이 늦게 나타날 수 있음을 보여 줍니다.

다음 시작이 더 빨라 보이는 것은 재구축된 아티팩트와 파일 시스템 페이지가 캐시에 올라와 있기 때문일 수 있습니다. 이러한 개선은 반복 가능한 작업을 피했다는 것만 보여 줄 뿐, 새 버전이 지속적인 부하에서 더 적은 리소스를 필요로 한다는 의미는 아닙니다.

스토리지 지연은 마이그레이션 및 재구축 시간을 배가시킵니다

스키마 변경과 캐시 생성에는 많은 읽기, 쓰기, 동기화 및 메타데이터 작업이 필요합니다. 정상적인 SSD에서는 빠르게 완료될 수 있지만, SD 카드, 거의 가득 찬 디스크, 사용량이 많은 가상 볼륨 또는 원격 데이터베이스에서는 동일한 논리적 작업이 수분에 걸쳐 진행될 수 있습니다.

한 업그레이드 실패 보고서는 눈에 보이는 시작 문제의 원인을 데이터베이스 마이그레이션으로 추적했으며, 이는 마이그레이션 실패 증거를 시작 화면만 보고 판단하지 말고 데이터베이스 및 스토리지 로그와 함께 분석해야 함을 보여 줍니다.

스토리지 큐 깊이가 증가하는 동안 CPU 사용량은 낮게 유지될 수 있습니다. 데이터베이스에 마이그레이션이 없고 디스크도 정상적으로 응답한다면 스토리지 증폭은 원인이 아닐 가능성이 높으며, 통합 구성 요소 설정이나 네트워크 시간 초과가 더 유력한 후보가 됩니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

진행이 멈추거나 데이터가 안전하지 않을 때 예상된 지연이 끝납니다

로그에 이름이 지정된 마이그레이션이 진행 중으로 표시되고 여유 공간도 안정적으로 유지된다면 첫 시작이 오래 걸리는 것은 정상일 수 있습니다. 반복적인 충돌, 변하지 않는 마이그레이션 단계, 데이터베이스 손상 메시지 또는 가득 찬 볼륨은 다른 상황입니다. 더 기다려도 불확실성이 줄어들지 않기 때문입니다.

Recorder 마이그레이션 실패 사례는 반복되는 마이그레이션 실패가 손상된 저장소에 재시작을 반복해 쓰기 작업을 더하는 대신 유효한 백업에서 복구해야 할 수 있음을 보여 줍니다.

이것이 실패의 경계입니다. 측정 가능한 진행 상황은 모니터링하되, 오류가 반복되거나 용량이 소진되거나 문서화된 업그레이드 경로가 실패하면 프로세스를 중단하십시오. 복구를 시도하기 전에 데이터베이스와 로그를 보존하십시오.

첫 시작과 안정 상태를 별도로 측정하십시오

업데이트 전에 데이터베이스 크기, 여유 공간, 버전, 종료 시간 및 일반적인 재시작 기준 시간을 기록하십시오. 업데이트 중에는 프로세스 시작, 마이그레이션 메시지, 통합 구성 요소 완료, 첫 대시보드 응답 및 안정적인 제어 가능 시점의 타임스탬프를 수집하십시오.

관련된 업그레이드 후 재처리 글은 기존 데이터가 다시 처리될 수 있는 이유를 설명하므로, 전체 시간을 막연한 부팅 시간으로 취급하지 않고 각 타임스탬프를 구체적인 메커니즘과 연결할 수 있습니다.

일회성 단계가 완료되고, 두 번째 재시작이 기준 시간에 가까워지며, 기록을 읽을 수 있고, 간단한 로컬 작업이 정상적으로 수행되면 업데이트를 유지하십시오. 진행이 멈추거나 무결성 검사가 실패한 경우에만 롤백하거나 복원하십시오. 진행 중인 첫 시작이 느리다는 이유만으로 롤백하지 마십시오.