안전한 접근 방식은 네이티브 덤프, 스토리지 스냅샷, 격리된 복원 리허설, 명확하게 설정된 롤백 지점을 사용하는 단계적 업그레이드를 단일 명령이 아니라 관찰 가능한 게이트의 연속으로 다루는 것입니다.
홈 서버에서 컨테이너화된 PostgreSQL 또는 MariaDB 데이터베이스를 운영할 때 실제 위험은 논리 객체나 실행 가능한 롤백 경로를 잃지 않고 자체 호스팅 데이터베이스를 업그레이드해야 한다는 데 있습니다. 현재 식별 정보와 복구 지점을 기록하고, 가장 개입이 적은 판별 단계부터 시작하며, 다른 변수를 변경하기 전에 통과 및 실패 결과를 해석하고, 스토리지가 불안정해지거나 복구 가능한 유일한 사본이 노출될 상황이 되면 중단하십시오. 아래 워크플로는 원래 워크로드가 성공하거나 증거가 에스컬레이션 경계에 도달한 후에만 종료됩니다.
백업 전에 호환성과 롤백을 정의하세요
데이터베이스 엔진과 정확한 소스 버전, 대상 버전, 애플리케이션 버전, 확장 기능 또는 플러그인, 문자 집합, 인증 규칙, 예약 작업 및 사용 가능한 중단 시간을 기록하세요. 애플리케이션의 업그레이드 참고 사항과 데이터베이스 경로를 모두 확인하세요. 애플리케이션 마이그레이션으로 인해 새 스키마와 기존 바이너리가 호환되지 않을 수 있습니다.
주요 버전 업그레이드에는 기존 데이터 디렉터리를 새 이미지에 마운트하는 대신 논리 덤프 및 복원이나 지원되는 마이그레이션 도구가 필요한 경우가 많습니다. 독립적인 Compose 데이터베이스 주요 버전 업그레이드 워크플로에서는 Compose 기반 PostgreSQL 주요 버전 업그레이드를 단계별로 설명하며, 기존 컨테이너와 볼륨을 대상과 분리해 유지해야 하는 이유를 보여줍니다.
무결성 검사 실패, 역할 또는 확장 기능 누락, 애플리케이션 오류 또는 허용할 수 없는 성능을 롤백 기한과 트리거로 지금 기록하세요. 대상에서 운영 쓰기가 시작되면 역방향 데이터 마이그레이션 계획을 테스트하지 않은 한 롤백은 더 이상 실행할 수 없습니다.
서로 독립적인 복구 지점 두 개를 만드세요
해당되는 경우 전역 객체를 포함해 엔진 네이티브 논리 백업을 실행한 다음, 명령, 버전, 종료 상태, 매니페스트 및 체크섬을 저장하세요. 하나의 데이터베이스 덤프에 모든 서버 수준 종속성이 포함되어 있다고 가정하지 말고 사용자, 권한 부여, 확장 기능, 스키마, 예약 작업 및 대형 객체가 포함되었는지 확인하세요.
데이터베이스가 지원되는 상태인지 확인한 후 데이터베이스 볼륨의 조정된 스냅샷 또는 중지된 복사본을 생성하세요. 논리 덤프는 이식성과 객체 수준 검사를 제공하고, 스토리지 복사본은 정확한 이전 버전 롤백 지점을 보존합니다. 어느 한쪽이 다른 쪽을 덮어써서는 안 됩니다.
ZimaSpace의 검증 체크리스트를 사용해 데이터베이스 백업 완전성 체크리스트를 확인하세요. 덤프를 읽을 수 있고, 스토리지 복구 지점이 식별되며, 두 항목이 모두 업그레이드할 볼륨 외부에 저장된 경우에만 백업 게이트를 통과합니다.
격리된 대상에서 마이그레이션을 리허설하세요
별도의 볼륨과 포트에서 대상 데이터베이스를 시작하고, 필요한 확장 기능을 설치한 다음, 논리 백업을 복원하고 모든 경고를 저장하세요. Percona의 논리 덤프 및 복원 업그레이드 경로 안내서는 덤프 및 복원 순서와 의도한 PostgreSQL 업그레이드 경로에 맞는 도구를 사용해야 할 필요성을 강조합니다.
복원된 데이터베이스에 일회용 애플리케이션 인스턴스를 연결하세요. 로그인, 읽기, 쓰기, 백그라운드 작업, 검색, 첨부 파일, 시간대 및 재시작을 테스트하세요. 복원 종료 코드가 성공했다는 사실에만 의존하지 말고 행 수와 핵심 집계값을 비교하세요.
확장 기능을 사용할 수 없거나, 데이터 정렬 변경이 해결되지 않았거나, 마이그레이션이 실패하거나, 복원 시간이 유지 관리 시간을 초과하면 진행하지 마세요. 리허설 문제를 해결하고 새 덤프를 생성하세요. 대상 버전 비호환성을 발견할 곳은 운영 환경이 아닙니다.
쓰기 전환을 수행하고 롤백 상태를 깨끗하게 유지하세요
유지 관리 모드로 전환하고, 애플리케이션의 쓰기 작업과 작업을 중지하며, 활성 연결이 모두 종료되었는지 확인한 다음 최종 덤프 또는 지원되는 변경분을 생성하세요. 이를 깨끗한 대상에 복원하고, 무결성 및 객체 검사를 실행하며, 애플리케이션 연결을 업데이트한 후 종속성 순서에 따라 서비스를 시작하세요.
오류율, 잠금, 작업 실행, 백업 및 실제 애플리케이션 트랜잭션을 관찰하세요. 기존 데이터베이스는 원래 볼륨과 이미지 다이제스트를 유지한 채 중지하고 읽기 전용으로 두세요. 동일한 애플리케이션 ID로 두 데이터베이스가 서로 독립적인 쓰기를 수락하도록 해서는 안 됩니다.
애플리케이션, 네이티브 백업 작업, 재시작 및 새 버전에서의 테스트 복원이 모두 통과한 후에만 성공을 선언하세요. 쓰기 경계 전에 롤백 트리거가 발생하면 앱을 보존된 기존 인스턴스로 되돌리세요. 새 쓰기가 발생한 후에는 중지하고 문서화된 조정 계획을 사용해야 하며, 단순한 재시작으로 데이터가 되돌아간다고 가장해서는 안 됩니다.
지원 및 팁
더 읽어보기

이름이 변경된 데이터 세트와 안정적인 파일 핸들을 위한 NFS 마이그레이션 체크리스트
스토리지 식별자가 변경되면 파일 핸들이 바뀔 수 있다고 가정하세요. 클라이언트를 일시 중지하고, 내보내기를 의도적으로 전환한 후 다시 마운트하고, 열린 파일과 새 파일을 확인하세요.

Windows, macOS 및 Linux용 SMB 클라이언트 문제 해결 가이드
검색, 자격 증명, 정책 및 스토리지 오류가 서로 뒤섞이지 않도록 각 클라이언트에서 동일한 서버, 계정, 공유 및 파일 작업을 사용하세요.

앱, 데이터베이스 및 백업을 위한 홈 서버 비밀 정보 교체 체크리스트
로테이션을 의존성 마이그레이션으로 간주하세요. 모든 사용처를 파악하고, 가능한 경우 자격 증명을 중복으로 적용하며, 새 값을 확인한 다음 기존 값을 폐기하고 복구 절차를 테스트하세요.

