29.5. WAL 내부

WAL자동으로 활성화됨; 다음을 제외하고는 관리자의 조치가 필요하지 않습니다. 에 대한 디스크 공간 요구 사항을 확인합니다.WAL로그가 충족되었으며 필요한 모든 튜닝이 완료되었습니다(참조103PostgreSQL: 문서: 9.1: WAL 내부59).

WAL로그는 다음 위치에 저장됩니다. 예배 규칙서pg_xlog데이터 아래 디렉토리, 세그먼트 파일 세트로, 일반적으로 각 크기는 16MB입니다. (그러나 크기는 다음을 변경하여 변경할 수 있습니다.--with-wal-segsize빌드 시 옵션 구성 서버). 각 세그먼트는 일반적으로 8kB의 페이지로 나뉩니다. 각각(이 크기는 다음을 통해 변경될 수 있습니다.--with-wal-blocksize옵션 구성). 로그 레코드 헤더는 다음에 설명되어 있습니다.액세스/xlog.h; 기록 내용은 다음에 따라 달라집니다. 기록되는 이벤트 유형입니다. 세그먼트 파일이 제공됩니다. 에서 시작하여 계속 증가하는 숫자의 이름000000010000000000000000. 숫자는 그렇지 않습니다 포장하지만 소진하는 데 매우 오랜 시간이 걸립니다. 사용 가능한 재고가 있습니다.

로그가 다른 디스크에 있는 것이 유리합니다. 기본 데이터베이스 파일에서. 이는 다음을 이동하여 달성할 수 있습니다.pg_xlog디렉토리를 다른 위치로 (물론 서버가 종료되는 동안) 기본 데이터의 원래 위치에서 심볼릭 링크 디렉터리를 새 위치로 이동합니다.

목적WAL다음을 보장하는 것입니다 데이터베이스 레코드가 변경되기 전에 로그가 기록되지만 이는 거짓으로 보고하는 디스크 드라이브에 의해 전복될 수 있습니다. 실제로는 커널에 성공적으로 쓰기만 했는데도 데이터를 캐시했지만 아직 디스크에 저장하지 않았습니다. 힘 이러한 상황에서 실패하면 복구할 수 없는 데이터가 발생할 수 있습니다. 부패. 관리자는 디스크가 보유포스트그레SQL의WAL로그 파일은 그런 것을 만들지 않습니다 거짓 보고. (보다섹션 29.1.)

체크포인트가 생성되고 로그가 플러시된 후, 체크포인트 위치는 파일에 저장됩니다.pg_control. 따라서 회복 초기에는 서버가 먼저 읽습니다.pg_control그리고 그런 다음 체크포인트 기록; 그런 다음 REDO 작업을 수행합니다. 다음에 표시된 로그 위치에서 앞으로 스캔하여 체크포인트 기록. 데이터 페이지의 전체 내용이 첫 번째 페이지 수정 후 로그에 저장됨 체크포인트(가정)full_page_writes비활성화되지 않음), 체크포인트 이후 변경된 모든 페이지는 일관된 상태로 복원되었습니다.

다음 경우를 처리하기 위해pg_control부패했습니다. 우리는 다음을 지원해야 합니다. 기존 로그 세그먼트를 역순으로 스캔할 가능성 — 최신 항목부터 가장 오래된 항목까지 — 최신 체크포인트를 찾기 위해. 이것 아직 구현되지 않았습니다.pg_control충분히 작습니다(디스크 1개 미만) 페이지) 부분 쓰기 문제가 발생하지 않으며 현재로서는 이 글을 쓰는 동안 데이터베이스 오류로 인한 보고는 없었습니다. 단지 읽을 수 없다는 이유로pg_control그 자체. 따라서 이론적으로는 약점,pg_control그렇지 않은 것 같습니다 실제로 문제가 될 수 있습니다.