SLOG가 손실된 경우 ZFS를 ZIL SLOG와 일관성 있게 만드는 방법은 무엇입니까?

SLOG가 손실된 경우 ZFS를 ZIL SLOG와 일관성 있게 만드는 방법은 무엇입니까?

HDD에는 ZFS가 있고 SSD에는 ZIL SLOG가 있습니다.

관련이 있는 경우 SSD에 LARC 캐시도 있습니다.

write()SSD 장애로 인해 데이터 불일치가 발생하지 않도록( 단일 스레드에서 두 작업의 내용을 혼합하여 하나씩 실행하는 것과 같은 POSIX 파일 시스템 호출 결과 규칙을 준수하지 않음) 보장하려면 어떻게 재구성해야 합니까 ?

SSD를 복원하지 않고 HDD의 백업 스냅샷을 복원하는 경우 ZFS의 PosgreSQL DB가 일관성이 없는지 확인하고 싶습니다. (저는 PostgreSQL을 동기화하기 위한 조치를 취했습니다(Postgre에 버그가 없다고 가정). POSIX에 맞는 파일 시스템은 데이터베이스가 불일치하지 않도록 보장합니다.)

답변1

ZIL은 안정적인 디스크에 대한 단기 커밋되지 않은 쓰기만 포함하는 것으로 가정됩니다. 정전과 SSD 오류가 동시에 발생하면 문제가 될 수 있습니다. 그러나 정상적인 SSD에 오류가 발생하면 zfs는 raid 쓰기 저장과 동등한 모드에서 raid write-through 모드로 전환해야 합니다. 성능이 저하될 수 있지만 즉시 손상되는 것은 없습니다.

ZIL의 핵심은 변경 사항을 비휘발성 스토리지에 신속하게 기록하여 애플리케이션이 계속 진행하도록 신속하게 지시할 수 있도록 하는 것입니다. 이러한 데이터가 안정적인 저장소(디스크)에 기록되기 전에 전원이 끊기면 다음에 전원이 공급된 후 zfs 볼륨이 마운트될 때 ZIL에서 안정적인 저장소로 복사됩니다.

파일 시스템 스냅샷의 요점은 현재 작성되지 않는 파일 시스템의 안정적인 버전을 복사할 수 있다는 것입니다. 스냅샷은 쓰기 가능하지 않아야 하므로 ZIL에는 ​​보류 중인 쓰기가 없으므로 이는 ZIL과 관련이 없습니다.

그렇지만 postgreSQL은 파일 시스템 스냅샷을 복원하는 것을 좋아하지 않을 수도 있습니다. ZFS 스냅샷 이전에 postgreSQL에 스냅샷을 찍거나 일시 중지하라는 지시가 없으면 zfs 스냅샷에 일부 부분적인 postgreSQL 쓰기가 포함될 수 있으며 이는 문제가 될 수 있습니다. postgreSQL 데이터베이스를 올바르게 백업하는 방법에 대해 별도의 질문을 하고 싶을 수도 있습니다. (...다른 사람이 여기서 이 내용을 다루고 싶어하지 않는 한.)

답변2

SLOG는 데이터 세트 독립적인 것으로 간주될 수 있습니다. 즉, pg 데이터가 디스크에 플러시되면 데이터 세트를 스냅샷으로 만들고 백업할 수 있으며 로그 장치 유무에 관계없이 스냅샷을 동일한 풀 및/또는 다른 풀로 복원할 수 있습니다.

log풀에서 (SLOG) 또는 (L2ARC) 장치를 물리적으로 제거하려는 경우 cache먼저 논리적으로 제거해야 합니다.

zpool remove [poolname] [logdevice|cachedevice]

(바라보다 man zpool-remove)

SLOG가 올바르게 제거되지 않으면 다음 재부팅 시 풀을 가져오지 못할 수 있습니다. 이로부터의 복구는 상당히 쉬울 수도 있고(SLOG에 플러시되지 않은 데이터가 없는 경우) 데이터 손상을 허용하지 않으면 어렵거나 불가능할 수도 있습니다. 일반적으로 두 개의 SLOG 장치를 미러 쌍으로 추가하는 것이 권장되는 이유가 있습니다. 이는 이 문제를 방지하기 위한 것입니다. 즉, 풀을 손상시킬 수 있는 단일 오류 지점을 방지하기 위한 것입니다.


나는 텍스트 덤프가 바이너리 파일보다 더 안정적이라고 생각하기 때문에 (자체 스냅샷 및 백업 일정이 있는 다른 데이터 세트로) 정기적인 pg_dump백업을 수행합니다. 특히 postgresql 서버가 계속 실행되는 동안 바이너리 스냅샷이 생성된 경우( 서버가능한스냅샷을 찍을 때 메모리의 모든 내용은 아직 디스크에 기록되지 않았습니다. 그러나 서버를 종료하면 동일한 상태에서 다시 시작하는 데 필요한 모든 내용이 기록됩니다. 또한 중요한 데이터의 경우 백업이 많을수록 좋습니다.

그런데 저는 몇 년 전에 모든 것을 덤프하고 pg 전역 변수(역할 등), 각 데이터베이스와 테이블의 스키마, 데이터(예: COPY . .. FROM)를 덤프하는 간단한 postgresql 백업 스크립트를 작성했습니다. 데이터가 다시 열로 삽입됩니다. 나는 약 20년 동안 그 변형을 사용해 왔습니다. ServerFault에 해당 버전을 게시했습니다.PostgreSQL 데이터베이스를 자동으로 백업하는 가장 좋은 방법은 무엇입니까?2009년으로 돌아갑니다.

이 버전에는 약간의 조정이 필요할 수 있습니다(특히 DBS=( $($PSQL --list --tuples-only ...) )데이터베이스 목록을 가져오는 행). 백업 디렉터리가 자체 스냅샷 일정이 있는 zfs 데이터 세트인 경우 YMD 하위 디렉터리가 필요하지 않거나 find ... -mtime +30 ...삭제할 필요도 없습니다. 파이프를 연결하거나 pg_dump내보내 pg_dumpall려면 gzip백업 데이터 세트에 압축을 사용하면 됩니다.

관련 정보