| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 27. 신뢰성과 로그 선행 기입 | Fast Forward | Next |
WAL는 자동적으로 유효하게 됩니다. WAL로그가 필요로 하는 디스크 용량을 확보하는 것, 그리고 필요시 튜닝하는 것을 제외하고는(Section 27.3를 참조), 관리자는 아무 일도 할 필요는 없습니다.
WAL로그는, 데이터 디렉토리 이하의 pg_xlog디렉토리에, 일반적으로 16 메가바이트의 사이즈를 가지는 세그멘트 파일의 집합으로서 저장되고 있습니다. 각 세그멘트는 통상 8킬로바이트의 페이지에 분할됩니다. 로그 레코드용의 헤더는 access/xlog.h에 기술되고 있습니다. 레코드의 내용은, 로그의 대상이 되는 이벤트의 종류에 따라서 다릅니다. 세그멘트 파일은 000000010000000000000000으로부터 시작되는, 항상 증가하는 수가 이름으로 주어지고 있습니다. 현재, 숫자는 순회합니다만, 이용 가능한 숫자가 쓰이려면 매우 긴 시간이 걸릴 것입니다.
주요한 데이터베이스 파일이 놓여져 있는 디스크와는 다른 디스크에 로그를 두면, 이점이 있습니다. 이것은 pg_xlog디렉토리를 다른 장소에(물론 서버를 종료하고) 이동해, 주데이터 디렉토리의 원래의 장소로부터 새로운 장소로의 상징적인 연결을 만드는 것으로 가능해집니다.
WAL의 목적으로, 데이터베이스 레코드가 변경되기 전에 로그가 쓰이는지 보증해야 하는데, 실제로는 캐쉬 밖에 데이터가 없고 디스크에는 저장되어 있지 않을 때에 디스크 드라이버가 저장에 성공했다고 커넬에 허위의 보고를 실시하는 경우가 있습니다. 정전과 같이, 복구 불가능한 데이터의 파괴가 일어나는 일이 있습니다. 관리자는, PostgreSQL의 WAL로그를 보관 유지하고 있는 디스크 장치가 그러한 거짓 보고를 하지 않게 보증해야 합니다.
체크 포인트가 실행되어 로그가 내보내진 후, 체크 포인트의 위치는 pg_control에 보존됩니다. 따라서, 복구를 실시하는 경우는 서버는 우선 pg_control를 읽어, 다음에 체크 포인트 레코드를 읽습니다. 그리고, 체크 포인트 레코드내에서 나타난 로그의 위치에서 포워드를 검사하는 것으로 REDO 처리를 실시합니다. 데이터 페이지의 내용 전체는, 체크 포인트 후의 최초의 페이지 변경시에 로그내에 보존되기 때문에, 그 체크 포인트 이후로 변경된 모든 페이지는 일관된 상태로 복구됩니다.
pg_control가 손상될 경우에 대비해 로그 세그멘트를 역순서로 읽어(즉 새로운 것으로부터 낡은 것으로), 최종 체크 포인트를 찾아내는 방법을 실제로 실현하는 것이 좋다고 생각됩니다. 아직 이것은 실현되지 않았습니다. pg_control는 꽤 작으므로(1 디스크 페이지 미만), 일부만 기입한다고 문제가 일어나지는 않습니다. 또 이 기입 시점에서 pg_control자체를 읽을 수 없는 것에 대한 데이타베이스 실패 에러 보고는 없습니다. 이 때문에, pg_control는 이론적으로는 약점이지만, 실질적으로 문제가 되지 않습니다.