Immich는 업그레이드를 중단하지 않고 외부 데이터베이스를 사용할 수 있나요?

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Immich는 외부 PostgreSQL 서비스에 연결할 수 있지만, 그렇다고 업그레이드가 자동으로 안전해지는 것은 아닙니다. 데이터베이스 버전, 확장 기능, 권한, 백업 및 롤백에 대한 책임이 기본 스택 외부로 이동할 뿐입니다.

외부 데이터베이스를 성능 설정이 아니라 고급 호환성 경계로 취급하세요. 각 Immich 또는 PostgreSQL 업그레이드 전에 실행하려는 정확한 Immich 릴리스의 요구 사항을 확인하고, 외부 서버가 필요한 확장 기능과 권한을 제공할 수 있는지 검증하며, 복원 가능한 백업을 생성하세요. 또한 한 번에 하나의 업그레이드 계층만 변경하여 어떤 구성 요소에서 문제가 발생했는지 파악할 수 있도록 하세요.

외부 데이터베이스 계약부터 시작하기

데이터베이스 엔드포인트, 데이터베이스 이름, 서비스 계정, TLS 모드, PostgreSQL 메이저 버전, 설치된 확장 기능의 이름과 버전, 해당 확장 기능을 업그레이드할 수 있는 담당자를 문서화하세요. 이 기록을 Immich 배포 정의와 함께 보관하여 컨테이너를 다시 생성할 때 다른 서버나 데이터베이스에 조용히 재연결되지 않도록 하세요.

기존 PostgreSQL 서버를 사용하는 것은 가능하지만 Immich의 기본 권장 설정은 아닙니다. 현재 릴리스에서 독립 데이터베이스 경로를 사용하려면 pgvector와 VectorChord가 필요합니다. Immich는 PostgreSQL 14~19, pgvector >=0.7 및 <0.9, VectorChord >=0.3 및 <2.0에서 작동하는 것으로 알려져 있습니다. 이러한 범위는 변경될 수 있으므로 업그레이드할 때마다 다시 확인하세요.

전환 전에 권한을 계획하세요. Immich는 일반적으로 슈퍼유저 권한이 있는 데이터베이스 역할을 요구합니다. 슈퍼유저 권한 없이 실행하는 것은 업데이트 중 수동 개입이 필요할 수 있는 고급 경로이며, 현재 자동 데이터베이스 백업에도 슈퍼유저 권한이 필요합니다. 외부 제공업체가 이러한 요구 사항을 충족할 수 없다면 프로덕션 상태를 이전하기 전에 중단하세요.

변경하기 전에 PostgreSQL 및 확장 기능 호환성 확인하기

현재 PostgreSQL 버전과 목표 PostgreSQL 버전을 Immich가 의존하는 모든 확장 기능과 함께 정리하세요. PostgreSQL 메이저 업그레이드에는 목표 메이저 버전에 맞게 빌드된 확장 기능 바이너리가 필요할 수 있습니다. 또한 PostgreSQL 자체가 계속 시작되더라도 Immich 업그레이드에서 더 새로운 확장 기능이나 다른 마이그레이션 동작을 요구할 수 있습니다.

확장 기능 패키지 파일과 SQL 확장 기능 상태는 PostgreSQL 업그레이드에 따라 자동으로 따라온다고 가정하지 말고 데이터베이스와 함께 신중하게 이전해야 합니다. 데이터베이스 메이저 버전이나 Immich에 필요한 확장 기능 패키지를 변경하기 전에 PostgreSQL 확장 기능 업그레이드 종속성을 검토하세요.

외부 제공업체가 필요한 확장 기능을 설치하거나 업그레이드하도록 허용하지 않거나, 필요한 경우 공유 preload 설정을 변경할 수 없거나, 마이그레이션에 필요한 권한을 부여할 수 없다면 Immich를 업데이트하기 전에 중단하세요. 일반 쿼리를 처리하는 데이터베이스라도 다음 애플리케이션 마이그레이션에는 적합하지 않을 수 있습니다.

데이터베이스 메이저 업그레이드와 Immich 업그레이드를 분리하기

전체 순서를 미리 연습해 보지 않았다면 PostgreSQL 메이저 업그레이드, 확장 기능 업그레이드 및 Immich 애플리케이션 업그레이드를 하나의 유지 관리 작업으로 묶지 마세요. 여러 호환성 경계가 동시에 변경되면 시작 실패만으로는 어느 계층에서 문제가 발생했는지 알 수 없습니다.

PostgreSQL 마이너 업데이트와 메이저 버전 업그레이드는 서로 다른 유지 관리 작업이며, 메이저 업그레이드에서는 타사 확장 기능을 포함한 목표 환경을 먼저 준비해야 합니다. 가능하면 PostgreSQL 메이저 버전 업그레이드를 Immich 애플리케이션 업그레이드와 분리하세요. 그러면 시작 실패가 발생해도 조사해야 할 변경 사항이 하나로 명확해집니다.

홈 서버에서는 일반적으로 다음과 같은 순서가 가장 위험이 낮습니다. 백업 생성, 복원 확인, 한 계층 업데이트, 검증 실행, 이후 계속 진행입니다. Immich 릴리스에서 데이터베이스 변경을 요구한다면 일반적인 PostgreSQL 업그레이드 절차를 적용하지 말고 해당 릴리스에서 지정한 순서를 따르세요.

데이터베이스와 미디어를 모두 포함하는 롤백 경로 유지하기

외부 데이터베이스를 사용하면 Immich 상태가 PostgreSQL과 미디어 라이브러리에 나뉘어 있다는 사실을 잊기 쉽습니다. 스키마나 자산 메타데이터를 변경할 수 있는 마이그레이션 전에 데이터베이스와 일관된 방식으로 데이터베이스를 백업하고, 동일한 복구 시점의 관련 미디어 및 구성 상태도 보존하세요.

복원 시점에는 데이터베이스 상태, 애플리케이션 파일, 구성 및 업로드 데이터가 서로 일치해야 합니다. PostgreSQL이 시작되는지만 확인하지 말고 일관된 데이터베이스 컨테이너 백업을 수용 기준으로 사용하세요.

애플리케이션 마이그레이션이 부분적으로 성공했을 때 양쪽에서 어떤 일이 발생하는지 알기 전까지는 롤백 준비가 완료되었다고 판단하지 마세요. 유일하게 정상 작동하는 사본 위에 최신 상태를 덮어쓰지 않고 복구할 수 있도록 이전 애플리케이션 버전, 배포 정의, 데이터베이스 백업 및 미디어 상태를 충분히 오래 보관하세요.

데이터베이스 연결이 아니라 애플리케이션으로 업그레이드 검증하기

변경 후에는 PostgreSQL이 의도한 Immich 역할을 허용하는지, 필요한 확장 기능이 예상 버전으로 설치되어 있는지, Immich 마이그레이션이 반복적인 데이터베이스 오류 없이 완료되는지 확인하세요. TCP 연결 성공이나 `SELECT 1` 실행은 연결성을 입증할 뿐 애플리케이션 호환성을 입증하지는 않습니다.

그런 다음 Immich를 평소처럼 사용하세요. 기존 앨범을 불러오고, 대표적인 사진과 동영상을 열고, 검색을 실행하고, 필요한 경우 사용자 또는 공유 기능을 확인하며, 테스트용으로 버려도 되는 자산 하나를 업로드하세요. 이러한 작업 중 애플리케이션 및 데이터베이스 로그에서 누락된 확장 기능, 권한 오류, 마이그레이션 실패 또는 반복적인 재시도 여부를 확인하세요.

애플리케이션이 이러한 검사를 통과한 후에만 정상적인 백업 보존 정책을 재개하고 롤백 사본을 삭제하세요. 외부 데이터베이스로 인해 일반적인 Immich 업그레이드에도 수동 확장 기능 또는 권한 작업이 반복적으로 필요하고 이를 안정적으로 사전 연습할 수 없다면, 기본 전용 데이터베이스 수명 주기를 사용하는 편이 운영상 더 안전합니다.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.