업그레이드 후 Home Assistant가 기존 데이터를 다시 처리하는 이유는 무엇인가요?

Home Assistant는 새 코드가 저장된 스키마, 인덱스, 캐시, 통계 및 통합 상태를 변경된 요구 사항에 맞춰 조정해야 하므로 업그레이드 후 기존 데이터를 다시 처리할 수 있습니다.

기존 센서 측정값을 반드시 다시 수집하는 것은 아닙니다. 대신 업그레이드된 시스템은 이전 상태를 새 버전에서도 사용할 수 있도록 테이블을 변환하고, 파생 구조를 다시 구축하며, 구성 항목을 다시 불러오거나 요약 정보를 재계산할 수 있습니다. 소요 시간은 데이터 양, 저장 장치 지연 시간, 사용 가능한 임시 공간, 통합 수, 데이터베이스 엔진 및 정확한 릴리스 경로에 따라 달라집니다.

업그레이드하면 기존 상태를 해석하는 방식이 바뀝니다

Home Assistant는 구성 텍스트보다 많은 정보를 영구 저장합니다. Recorder 테이블, 엔터티 레지스트리, 장치 메타데이터, 통합 항목, 통계 및 캐시는 해당 정보를 기록한 버전의 가정을 반영합니다. 새 코드에서 이러한 가정이 바뀌면 정상적으로 사용하기 전에 기존 상태를 변환하거나 호환되는 표현으로 다시 생성해야 합니다.

이는 통제된 소프트웨어 마이그레이션의 일반적인 목적입니다. 즉, 의도한 결과를 잃지 않고 데이터와 동작을 이전 표현에서 새로운 표현으로 옮기는 것입니다. The Pragmatic Engineer의 소프트웨어 마이그레이션 단계 개요는 준비, 실행, 마이그레이션 후 작업 및 장기 후속 작업을 구분하며, 새 코드를 설치하는 것만으로 완료되지 않는 이유를 설명합니다.

따라서 재처리는 호환성을 위한 작업이며, Home Assistant가 원본 데이터를 잊었다는 증거가 아닙니다. 중요한 질문은 어떤 저장 표현이 바뀌었는지, 작업이 계속 진행되는지, 어떤 기능을 사용할 수 있는지입니다. 릴리스에 따라 이러한 계층 중 어느 것도, 하나만 또는 여러 계층이 영향을 받을 수 있습니다.

스키마 마이그레이션은 대규모 테이블을 읽고 다시 쓸 수 있습니다

데이터베이스 스키마는 테이블, 열, 형식, 인덱스 및 제약 조건을 정의합니다. 업그레이드 과정에서 열을 추가하거나, 식별자의 폭을 넓히거나, 인덱스를 다시 구축하거나, 행을 새로운 레이아웃으로 변환할 수 있습니다. 릴리스 노트에서 작아 보이는 작업도 대규모 Recorder 데이터베이스를 검색하거나 복사하고 상당한 임시 I/O를 발생시킬 수 있습니다.

관찰된 Home Assistant Recorder 마이그레이션 사례에서는 수 기가바이트 규모의 데이터베이스에서 인덱스를 제거하고 다시 생성하는 작업이 기록되었으며, 대규모 데이터베이스나 느린 하드웨어에서는 인덱스 생성에 몇 분이 걸릴 수 있다는 경고도 포함되었습니다.

작업량은 CPU 사용률뿐 아니라 영향을 받는 행 수와 저장 장치의 동작에 따라 증가합니다. 프로세서 사용률이 낮아 보여도 마이그레이션이 I/O, 잠금 또는 데이터베이스 엔진의 제약을 받을 수 있습니다. 반복적으로 중단하면 작업이 다시 시작되거나 시스템에 검증이 필요해질 수 있으므로, 임의의 경과 시간보다 진행 상황과 로그가 더 중요합니다.

파생 인덱스와 캐시는 새 코드와 일치해야 합니다

인덱스, 캐시, 컴파일된 자산 및 조회 구조는 신뢰할 수 있는 원본 데이터에서 파생됩니다. 형식이나 무효화 규칙이 변경된 후 이를 재사용하면 오래된 엔터티, 잘못된 쿼리 또는 일치하지 않는 프런트엔드 리소스가 반환될 수 있습니다. 이를 폐기하고 다시 구축하면 일시적인 작업량이 늘어나지만 새 버전에서 일관된 결과를 얻을 수 있습니다.

캐시 일관성을 유지하려면 원본에 대한 가정이 바뀐 항목을 제거해야 합니다. Meta의 엔지니어링 글인 캐시 무효화와 일관성은 캐시가 진실의 원천이 아니며 무효화가 잘못 처리되면 영구적으로 일관성이 깨진 상태로 남을 수 있다고 설명합니다.

이 메커니즘은 첫 시작이나 첫 대시보드 로드가 이후보다 느릴 수 있는 이유를 설명합니다. 호환되는 파생 상태가 생성되면 이후 접근에서는 이를 재사용합니다. 같은 비용이 큰 재구축이 재시작할 때마다 반복된다면 이를 정상적인 준비 과정으로 받아들이기보다 결과가 저장되거나 인식되지 않는 이유를 조사해야 합니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

통합은 장치, 엔터티 및 세션을 다시 조정합니다

각 통합은 자격 증명을 복원하고, 세션을 설정하며, 장치를 검색하고, 식별자를 매핑하고, 엔터티 가용성을 업데이트해야 합니다. 업그레이드로 설정 로직, 엔터티 모델, 라이브러리 버전 또는 마이그레이션 처리기가 변경될 수 있습니다. 그러면 기존 구성이 새 코드를 통해 다시 로드되어 현재 런타임과 일치하는 상태를 통합이 생성할 수 있게 됩니다.

통합 다시 로드 동작을 통해 이 수명 주기를 확인할 수 있습니다. 커뮤니티의 Home Assistant 구성 항목 다시 로드 설명에서는 통합을 언로드한 뒤 다시 설정하는 다시 로드 작업을 소개하며, 이는 시작 시 수행되는 광범위한 조정 과정과 같은 경계를 이룹니다.

클라우드 API, 절전 상태의 배터리 장치 또는 사용할 수 없는 게이트웨이는 데이터베이스 작업과 별개로 조정 시간을 늘릴 수 있습니다. 초기 시작 중 엔터티가 사라지는 현상은 일시적일 수 있지만, 반복되는 인증 실패나 식별자 변경은 정상적으로 진행되고 있다는 증거가 아닙니다. 원인을 판단하기 전에 통합 재시도와 Recorder 마이그레이션 로그를 분리해서 확인해야 합니다.

통계는 보존된 기록에서 다시 구축될 수 있습니다

Home Assistant는 장기 보기에서 사용하는 파생 통계와 함께 원시 또는 단기 상태 기록을 보관합니다. 계산 규칙, 메타데이터 관계 또는 요약 구조가 변경되면 보존된 행을 다시 읽어 파생 시계열을 복구하거나 재생성해야 할 수 있습니다. 이 경우 원본 장치 측정값을 변경하지 않고도 추가 읽기 및 쓰기가 발생합니다.

엔터티 기록과 장기 통계의 차이는 운영상 중요합니다. 커뮤니티의 상세한 Home Assistant 통계 복구 가이드는 요약 통계를 일시적인 기록과 별도로 재구성하거나 이동할 수 있는 별도의 데이터 계층으로 다룹니다.

다시 구축된 요약 정보는 안정적인 값과 정상적인 쓰기량으로 수렴해야 합니다. 누락, 중복, 변경되는 메타데이터 식별자 또는 같은 지점부터 다시 시작하는 작업이 있는지 확인하세요. 이러한 패턴은 보존된 데이터를 한 번 처리하는 유한한 작업이 아니라 호환성 또는 무결성 문제를 나타냅니다.

정상적인 진행과 실패는 서로 다른 양상을 보입니다

업그레이드 후 예상되는 작업에는 이름이 지정된 작업, 증가하는 진행 상황이나 변경되는 로그 단계, 제한된 리소스 사용량 및 최종 완료가 있습니다. 실패는 같은 오류를 반복하거나, 디스크 공간을 모두 사용하거나, 마이그레이션을 다시 시작하거나, Recorder를 계속 사용할 수 없게 하거나, 새로운 손상 경고를 생성합니다. 데이터베이스와 하드웨어가 서로 다르므로 시간만으로 두 상황을 안정적으로 구분할 수는 없습니다.

마이그레이션 실패는 기다리는 것이 항상 안전하다는 생각에 대한 구체적인 반례를 제공합니다. 한 Home Assistant 데이터베이스 업그레이드 실패 사례에서는 마이그레이션으로 VM의 사용 가능한 저장 공간이 모두 소진되었고, 용량을 늘린 뒤에야 진행되었습니다. 이는 반복되는 실패가 인내심의 문제가 아니라 리소스 한계 때문일 수 있음을 보여줍니다.

시작 시간이 평소보다 길다는 이유만으로 데이터베이스를 삭제하지 마세요. 업그레이드 전 백업을 보존하고, 정확한 버전 조합을 기록하며, 여유 공간, 데이터베이스 활동 및 로그를 관찰하세요. 같은 오류가 반복되거나 여러 관찰 구간 동안 진행이 멈추거나 필수 서비스가 계획한 중단 시간을 초과하면 문제를 상위 단계로 escalate해야 합니다.

단계적인 업그레이드 후 관찰 절차를 사용하세요

업그레이드 전에 데이터베이스 크기, 여유 공간, 정상적인 시작 시간, 통합 수 및 정상 작동이 확인된 백업 식별자를 기록하세요. 새 버전이 시작된 후에는 일정한 간격으로 마이그레이션 메시지, 저장 공간 증가, Recorder 가용성, 엔터티 복구 및 통계 일관성을 확인하세요. 첫 시작 작업량을 왜곡할 수 있는 백업이나 검사를 동시에 실행하지 마세요.

복구 산출물과 버전 상태를 미리 문서화하면 마이그레이션 경험을 더 쉽게 해석할 수 있습니다. 한 운영자의 Home Assistant 마이그레이션 기록은 백업, 복원 동작 및 환경 변경이 마지막에 덧붙이는 작업이 아니라 실제 전환 과정의 일부가 되는 방식을 보여줍니다.

로그에서 마이그레이션 작업 보고가 중단되고, Recorder가 새 이벤트를 수락하며, 기록과 통계 확인이 정상적으로 응답하고, 통합이 안정화되며, 두 번째 재시작이 예상 기준선에 가까운 상태로 돌아왔을 때만 성공으로 판단하세요. 정상 작동이 확인된 데이터베이스 백업을 위한 ZimaSpace 복구 경로를 준비해 두되, 관찰된 실패가 복구 기준을 넘은 경우에만 사용하세요.