30.5. WAL 인터널

WAL은 자동으로 활성화된다. WAL 로그에 대한 디스크 공간 요구사항을 맞춰야 할 때 및 필수 튜닝이 완료되었을 때 외에는 관리자의 개입이 불필요하다(30.4절 참조).

WAL 로그는 각각의 크기가 보통 16 MB인 세그먼트 파일 집합으로, 데이터 디렉토리 하위인 pg_xlog 디렉토리에 저장된다(서버 빌드 시 --with-wal-segsize 환경 설정 옵션을 변경하면 크기를 바꿀 수 있다). 각 세그먼트는 일반적으로 각각 8 kB의 페이지로 분할된다(이 크기는 --with-wal-blocksize 환경 설정 옵션을 통해 변경할 수 있다). 로그 레코드 헤더는 access/xlogrecord.h에 설명되어 있다. 레코드 내용은 로깅된 이벤트 유형에 따라 다르다. 세그먼트 파일 이름은 000000010000000000000000에서 시작되며 숫자가 계속 증가한다. 숫자는 랩(wrap)되지 않지만 가용 숫자 재고가 소진되려면 아주 오래 걸린다.

로그가 메인 데이터베이스 파일이 아닌 다른 디스크에 위치한 경우에 이것은 장점이 된다. 서버가 종료된 상태에서 pg_xlog 디렉토리를 다른 위치로 옮기고, 메인 데이터 디렉토리의 원래 위치로부터 새 위치로 심볼릭 링크를 생성하면 된다.

WAL의 목적은 데이터베이스 레코드가 변경되기 전에 로그가 기록되도록 하는 것이지만, 사실은 데이터를 캐싱만하고 디스크에 미처 저장하지 못한 경우 디스크 드라이브가 커널에 쓰기를 성공했단 내용을 잘못 리포트해 엉망이 될 수 있다. 이러한 상황에서 정전이 발생하면 복구 불가능한 데이터 손상이 발생하게 된다. 관리자는 PostgreSQL의 WAL 로그 파일이 저장되는 디스크가 이런 잘못된 리포트를 하지 않도록 해야 한다. (30.1절 참조.)

checkpoint가 설정되고 로그가 쓰기된 후 checkpoint의 위치는 pg_control 파일에 저장된다. 그러므로, 복구 시작 시 서버는 먼저 pg_control을 읽은 다음, checkpoint 레코드를 읽는다. 그러고 나서 chekcpoint 레코드에 표시된 로그 위치에서 순방향으로 스캔하여 REDO 명령을 수행한다. 데이터 페이지의 전체 내용은 checkpoint 이후의 첫 번째 페이지 수정에 대한 로그에 저장되므로 (full_page_writes는 비활성화되었다고 가정) checkpoint 이후의 모든 페이지 변경은 일관된 상태로 복원된다.

pg_control가 손상된 경우를 처리하려면 최신 checkpoint를 찾기 위해 역순(가장 최신- 가장 과거 순)으로 기존 로그 세그먼트를 스캐닝 해봐야 한다. 이는 아직 구현되지 않았다. pg_control은 충분히 작아서(디스크 페이지 1개 미만) partial-write 문제에 해당되지 않으며, 현재까지, pg_control 자체가 읽지 못하는 것만으로 데이터베이스 오류가 난 적은 없었다. 따라서, 이론적으론 고쳐야 할 부분이지만 pg_control이 실제로 문제가 되는 것은 아니다.