네트워크에 마운트된 Docker 볼륨에서 데이터베이스를 실행할 수 있나요?

경우에 따라 다르지만, 데이터베이스가 네트워크 파일 시스템의 의미 체계와 지연 시간을 명시적으로 지원하는 경우에만 해당합니다. 로컬의 내구성 있는 스토리지를 기본값으로 선택하는 편이 더 안전합니다.

컨테이너화된 PostgreSQL, MariaDB 또는 SQLite 워크로드를 중앙 집중식 스토리지를 쉽게 사용하기 위해 NFS나 SMB에 연결할 때 이 결정이 중요합니다. 서로 경쟁하는 두 가지 상태는 지원되는 잠금, fsync 및 장애 의미 체계와 데이터베이스의 기대를 위반하는 지연 시간, 캐시, 잠금 또는 재연결 동작입니다. 저장된 구성과 폐기 가능한 데이터로 시작하고, 한 번에 한 가지 분기만 관찰하며, 테스트로 인해 데이터 손실, 권한 또는 가용성 위험이 확대되면 중지하세요.

네트워크 스토리지에 있는 데이터베이스 파일 결정의 조건 정의

무언가를 변경하기 전에 환경을 기록하세요. 소프트웨어 및 펌웨어 버전, 장치 식별자, 마운트 또는 네트워크 경로, 여유 공간, 권한, 관찰 가능한 증상을 기록해야 합니다. 기준선에는 중앙 집중식 스토리지를 쉽게 사용하기 위해 컨테이너화된 PostgreSQL, MariaDB 또는 SQLite 워크로드가 NFS나 SMB에 연결된 상태를 재현할 수 있을 만큼 충분한 세부 정보가 포함되어야 합니다.

첫 번째 후보는 지원되는 잠금, fsync 및 장애 의미 체계입니다. 두 번째 후보는 데이터베이스의 기대를 위반하는 지연 시간, 캐시, 잠금 또는 재연결 동작입니다. 현재 NFS에서의 PostgreSQL 문서는 테스트에 사용되는 메커니즘 또는 명령 경계를 정의하지만, 이 특정 홈 서버에서 직접 관찰한 결과를 대신하지는 않습니다.

판별 테스트를 실행하기 전에 통과 조건과 중지 조건을 작성하세요. 통과는 한 분기가 예측한 증거를 변경하면서 관련 없는 서비스는 변경하지 않아야 하며, 실패 시에는 추측성 수정 작업을 연쇄적으로 실행하는 대신 시스템을 저장된 상태로 되돌려야 합니다.

원래 요구 사항을 낮추지 않고 주장을 테스트하세요

다음 판별 테스트를 사용하세요. 폐기 가능한 데이터베이스를 정확히 해당 마운트에 복원하고, 일관성 및 충돌 복구 테스트를 실행한 뒤, 짧은 네트워크 중단을 시뮬레이션합니다. 변경된 변수에 결과의 원인을 귀속할 수 있도록 워크로드, 클라이언트, 경로, 파일 집합 및 타이밍을 일정하게 유지하세요.

데이터베이스 네트워크 파일 시스템 위험을 사용해 실제로 두 분기를 구분할 수 있는 필드를 선택한 다음, 타임스탬프, 종료 상태, 오류 텍스트, 장치 또는 스냅샷 식별자, 지연 시간, 전송된 바이트, 권한 및 복구 상태를 캡처하세요. 식별자, 내구성 또는 애플리케이션 상태가 테스트 대상인 경우에는 명령이 오류 없이 종료된 것만으로는 충분하지 않습니다.

재시작, 재연결, 재마운트 또는 콜드 캐시가 원래 조건의 일부라면 해당 이벤트 이후 테스트를 한 번 반복하세요. 첫 실행이 파괴적이거나 환경을 복원할 수 없다면 중지하고 대신 폐기 가능한 복사본에서 재현하세요.

테스트: 지속적인 트랜잭션 -> 네트워크 중단 -> 재마운트 -> 데이터베이스 복구 -> 검사

통과, 실패 및 예외 결과 해석

통과: 대상 지연 시간과 마운트 옵션에서 트랜잭션이 내구성을 유지하고 손상 없이 복구됩니다. 결론이 보편적인 주장으로 변하지 않도록 통과한 정확한 버전, 식별자 및 워크로드를 기록하세요.

실패: 데이터베이스가 멈추거나 잠금 또는 fsync 오류를 보고하거나, 중단 후 일관되지 않은 상태로 돌아옵니다. 네트워크, 메모리, 권한 또는 소스 일관성이 양쪽 분기에 영향을 줄 수 있으므로 실패가 자동으로 반대 분기를 입증하는 것은 아닙니다. 확대하기 전에 이러한 공통 종속성을 분리하세요.

예외 또는 모호한 결과: 데이터베이스 파일을 로컬의 내구성 있는 스토리지로 옮기고 애플리케이션 계층에서 백업하거나 복제하세요. 복구 가능한 복사본이 존재할 때까지 로그를 보존하고 복구, 정리, 삭제, 재파티션 또는 재귀적 소유권 변경 명령을 실행하지 마세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

원래 워크로드에서 결정 확인

관찰된 분기에 맞는 조치를 적용한 다음, 축소된 대체 조건이 아니라 원래 조건을 반복하세요. 대상 지연 시간과 마운트 옵션에서 트랜잭션이 내구성을 유지하고 손상 없이 복구되며, 이를 두 번의 주기 또는 관련된 재부팅, 절전, 중단이나 부하 전환에서 확인한 경우에만 결정을 유지할 수 있습니다.

데이터베이스 덤프 워크플로를 사용해 가장 가까운 종속 워크플로를 확인하되, 원래 트리거는 변경하지 마세요. 관련 없는 데이터 세트, 공유, 컨테이너, 사용자 및 복구 지점은 이전의 접근 권한과 타이밍을 유지해야 합니다.

중지 경계는 명확합니다. 데이터베이스가 멈추거나 잠금 또는 fsync 오류를 보고하거나, 중단 후 일관되지 않은 상태로 돌아오면 마지막으로 검증된 구성으로 되돌리고 증거를 보존하세요. 해당 분기가 반복 재현될 때만 더 심층적인 플랫폼 또는 하드웨어 테스트로 확대하세요.

대상 결과가 유지된 후에는 NFS 시간 초과 동작과 비교하여 수정 사항이 인접한 서비스로 위험을 옮기지 않는지 확인하세요. 새로운 백업, 식별자, 시간 초과 또는 가용성 문제가 발생한 성공적인 대상 테스트도 여전히 실패한 변경입니다.

FAQ

네트워크 스토리지에 있는 데이터베이스 파일과 관련해 남은 검색은 대개 데이터베이스 파일에 NFS가 SMB보다 안전한지, 데이터베이스 WAL을 로컬에 두고 데이터를 원격에 둘 수 있는지, 네트워크 Docker 볼륨이 호스트 NFS 마운트와 다른지에 관한 것입니다. 아래 답변에서는 이러한 예외 사례를 주요 결정과 분리해 설명합니다.

통과 경계는 변경되지 않습니다. 대상 지연 시간과 마운트 옵션에서 트랜잭션이 내구성을 유지하고 손상 없이 복구되어야 합니다. 후속 조건에서 파일 시스템, 식별자, 네트워크 경로 또는 애플리케이션 버전이 변경되면 해당 변경의 영향을 받는 판별 테스트만 반복하세요.

데이터베이스가 멈추거나 잠금 또는 fsync 오류를 보고하거나, 중단 후 일관되지 않은 상태로 돌아오면 실험의 범위를 넓히지 마세요. 이 시점에서는 데이터베이스 파일을 로컬의 내구성 있는 스토리지로 옮기고 애플리케이션 계층에서 백업하거나 복제하세요. 플랫폼, 스토리지 또는 하드웨어 담당자에게 확대하기 전에 증거를 보존해야 합니다.

데이터베이스 파일에는 NFS가 SMB보다 안전한가요?

프로토콜 이름만으로는 충분하지 않습니다. 데이터베이스 지원 여부, 서버 구현, 마운트 의미 체계 및 지연 시간이 모두 중요합니다.

데이터베이스 WAL을 로컬에 두고 데이터는 원격에 둘 수 있나요?

일부 구성에서는 분리가 가능하지만 장애 및 복구 의미 체계가 더 복잡해지므로 테스트해야 합니다.

네트워크 Docker 볼륨은 호스트 NFS 마운트와 다른가요?

컨테이너 추상화가 기본 네트워크 파일 시스템 동작을 제거하지는 않습니다.

네트워크 스토리지에 있는 데이터베이스 파일에 대한 실용적인 답은 여전히 조건부입니다. 대상 지연 시간과 마운트 옵션에서 트랜잭션이 내구성을 유지하고 손상 없이 복구되어야 합니다. 데이터베이스가 멈추거나 잠금 또는 fsync 오류를 보고하거나, 중단 후 일관되지 않은 상태로 돌아오면 데이터베이스 파일을 로컬의 내구성 있는 스토리지로 옮기고 애플리케이션 계층에서 백업하거나 복제하세요. 원래 워크로드를 견디지 못하는 부분적인 성공은 호환성이 아닙니다.