Immich 데이터베이스에 유지 관리 또는 교체가 필요하다는 징후

단순히 느려진 Immich 데이터베이스에는 일반적인 PostgreSQL 유지 관리나 리소스 문제 해결이 필요할 수 있지만, 반복적으로 무결성 또는 복구 실패가 발생하는 데이터베이스는 검증된 백업에서 복원하거나 교체해야 할 수 있습니다.

“데이터베이스 재구축”을 일반적인 성능 개선 방법으로 사용하지 마세요. 먼저 정상적인 데이터 증가, 블로트, 오래된 통계, 유지 관리 차단, 스토리지 지연을 손상 또는 복구할 수 없는 클러스터 상태와 구분해야 합니다. 침습적인 작업을 수행하기 전에 복구 지점을 보존하고, 한 번에 하나의 유지 관리 변경 사항만 측정하며, 현재 데이터베이스를 신뢰할 수 없거나 안전하게 복구할 수 없다는 증거가 있을 때만 깨끗한 백업 복원으로 넘어가세요.

성능 저하와 무결성 장애를 구분하세요

정확한 증상부터 확인하세요. 검색 지연, 타임라인 쿼리 지연, 큰 데이터베이스 크기, 높은 디스크 활동, 반복되는 PostgreSQL 오류, 충돌 복구 루프 또는 완료되지 않는 Immich 마이그레이션 등이 해당합니다. 성능 증상과 무결성 증상은 위험도가 다르므로 같은 방식으로 처음 복구해서는 안 됩니다.

PostgreSQL을 원인으로 지목하기 전에 호스트의 스토리지가 여전히 정상인지, 여유 공간이 충분한지, 메모리 사용 상태가 정상인지, 폭주하는 Immich 백그라운드 작업이 없는지 확인하세요. 포화 상태이거나 고장 난 디스크는 정상적인 데이터베이스도 느려 보이게 할 수 있으며, 기반 스토리지가 불안정해지면 실제 데이터베이스 손상을 일으킬 수도 있습니다.

침습적인 유지 관리 전에 로그, 데이터베이스 버전, 확장 프로그램 버전, 최근 업그레이드 이력, 백업 또는 스냅샷을 보존하세요. 데이터베이스의 유일한 사본이 손상되었을 가능성이 있다면 오류가 사라지는지 확인하기 위해 파괴적인 정리를 실행하지 마세요. 통제된 복원 여부를 결정하는 데 필요한 증거를 보존해야 합니다.

측정 가능한 유지 관리 신호를 확인하세요

데이터베이스가 시작되고 내부적으로 계속 사용할 수 있지만 시간이 지날수록 쿼리 성능이나 디스크 사용량이 악화된다면 일반적인 유지 관리가 적절한 경로일 수 있습니다. 유용한 증거로는 증가하는 사망 행, 불균형하게 커지는 테이블이나 인덱스, 따라가지 못하는 autovacuum, 오래된 플래너 통계 또는 다른 세션 때문에 장시간 차단된 유지 관리 작업 등이 있습니다.

사망 튜플, 블로트, 동결 압박, 차단된 VACUUM, 부족한 vacuum 빈도는 모두 PostgreSQL 유지 관리와 쿼리 성능에 영향을 줄 수 있습니다. 데이터베이스 파일이 크다는 사실만으로 교체가 필요하다고 가정하지 말고, 시간에 따른 테이블 수준 VACUUM 신호를 활용하세요.

통계가 특정 테이블이나 인덱스를 가리킨다면 해당 발견 사항에 맞는, 지원되는 가장 비침습적인 유지 관리 작업을 선택한 뒤 다시 측정하세요. 곧바로 VACUUM FULL, 광범위한 REINDEX 작업 또는 클러스터 전체에 임의의 autovacuum 설정을 적용하지 마세요. 이러한 작업은 잠금, I/O 또는 추가 디스크 수요를 발생시킬 수 있으며 실제 병목을 해결하지 못할 수도 있습니다.

블로트 또는 인덱스 증가가 느린 경로와 일치하는지 확인하세요

느린 Immich 작업에 관여하는 객체를 테이블 및 인덱스 크기, 행 변경량, 쿼리 동작과 비교하세요. 블로트는 유용한 행을 찾는 데 필요한 작업량을 늘리거나 인덱스의 효율을 떨어뜨릴 때 문제가 되지만, 라이브러리와 메타데이터가 크기 때문에 데이터베이스가 클 수도 있습니다.

과도한 블로트는 쿼리에 필요한 작업량을 늘릴 수 있지만 데이터베이스 손상을 의미하지는 않으므로 테이블 블로트와 인덱스 블로트는 별도로 평가해야 합니다. 전체 데이터베이스 크기를 진단 결과로 취급하지 말고, 관찰된 객체를 대상으로 측정된 PostgreSQL 블로트 점검을 수행하고 필요한 경우 플래너 통계를 갱신하세요.

유지 관리 후 느렸던 정확한 Immich 작업을 다시 실행하고, 사용자가 체감하는 지연 시간과 데이터베이스 및 스토리지 동작을 모두 비교하세요. 작업이 개선되지 않는다면 가능한 경우 이전 튜닝을 되돌리고, 데이터베이스 변경 사항을 계속 추가하기보다 스토리지, 쿼리 패턴, 백그라운드 작업 또는 애플리케이션 수준의 원인을 조사하세요.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

무결성이 불확실하면 복원 또는 교체로 전환하세요

교체는 데이터베이스가 오래되었다는 이유가 아니라 현재 PostgreSQL 상태를 신뢰할 수 없거나 안전하게 복구할 수 없다는 증거가 있을 때 정당화됩니다. 예를 들면 반복적으로 재현되는 페이지 또는 체크섬 손상, 정상적인 스토리지에서도 지속되는 시작 또는 복구 실패, 불완전한 스토리지 장애 이후 손상된 클러스터, 지원되는 경로로 복구할 수 없는 마이그레이션 상태 등이 있습니다.

데이터베이스를 잃었다고 선언하기 전에 정상으로 알려진 백업을 깨끗하고 호환되는 PostgreSQL 환경에 복원할 수 있는지, 그리고 Immich가 이를 읽을 수 있는지 확인하세요. 깨끗한 복원은 정상 작동하지만 현재 클러스터에서 동일한 무결성 오류가 반복된다면, 현재 위치에서 계속 복구하기보다 데이터베이스 상태를 교체해야 한다는 훨씬 강력한 근거가 됩니다.

불확실한 영구 상태를 보존하면서 국소적이고 되돌릴 수 있는 문제는 복구하고, 복구 원본이 검증되었으며 대상 환경을 재현할 수 있을 때만 재구축하세요. 이 Immich 복구와 재구축의 경계를 데이터베이스에도 적용하세요. “교체”란 쿼리가 느려졌다는 이유로 데이터베이스를 바꾸는 것이 아니라, 정상으로 알려진 원본에서 호환되는 PostgreSQL 상태를 복원하는 것을 의미해야 합니다.

읽기, 쓰기, 백업 작업으로 데이터베이스를 검증하세요

유지 관리를 수행했든 깨끗한 데이터베이스를 복원했든, PostgreSQL이 성공적으로 시작되었다는 사실에서 멈추지 말고 Immich를 통해 결과를 검증하세요. 기존 앨범과 에셋을 열고, 검색을 실행하고, 대표적인 동영상을 불러오며, 사용자와 공유 상태가 예상대로 표시되는지 확인하세요.

삭제해도 되는 에셋을 업로드하는 것처럼 안전한 새 쓰기 작업을 한 번 수행하고, 정상적인 서비스 재시작 후에도 해당 에셋에 접근할 수 있는지 확인하세요. 읽기 및 쓰기 경로가 활성화된 동안 PostgreSQL과 Immich 로그에서 반복되는 무결성, 마이그레이션, 확장 프로그램 또는 권한 오류를 확인하세요.

마지막으로 일반적인 방법으로 새로운 데이터베이스 백업을 생성하고, 가능하다면 격리된 대상 환경에서 복원 테스트를 수행하세요. 현재 시스템을 사용할 수 있고 다음 복구 지점이 장애를 일으킨 상태보다 확실히 더 건강하다는 사실이 입증되었을 때에만 유지 관리 또는 교체 결정이 완료됩니다.