| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 17. 서버의 설정 | Fast Forward | Next |
WAL조정에 대한 자세한 것은Section 27.3도 참조해 주세요.
이 매개변수가 온이면,PostgreSQL서버는fsync()시스템·콜을 발행하거나 혹은 동등의 방법으로(wal_sync_method를 참조) 갱신이 물리적으로 디스크에 기입되었는지의 확증을 얻으려고 시도합니다.
이것은 운영 시스템 혹은 하드웨어가 크래시 한 후, 확실히 데이터베이스 클러스터를 일관한 상태로 복구시킬 수 있습니다.
그러나,fsync의 사용은 성능을 악화시킵니다. 트랜잭션이 커밋 되면,PostgreSQL은, 운영 시스템이 로그 선행 기입을 디스크에 플러시 때까지 대기하지 않으면 안됩니다. fsync를 무효로 하면, operating system는, 기입의 완충화(버퍼링), 순서 붙이고 그리고 지연에 관해서 최선의 행동을 취할 수가 있습니다. 이것은 큰폭으로 성능을 향상시킵니다. 그러나, 시스템이 크래시 하면, 마지막 몇 개의 커밋된 트랜잭션(transaction)은, 일부 혹은 완전하게 없어질 가능성이 있습니다. 최악의 경우, 회복 불가능한 데이터의 파괴가 발생합니다. (데이터베이스 소프트웨어 그 자체의 크래쉬는, 여기에서는 위험 요인이 없습니다 . 운영시스템 레벨의 크래쉬가 파괴의 위험성을 일으킵니다. )
위험성이 내포 되어 있기 때문에,fsync에 대한 보편적으로 올바른 설정은 존재하지 않습니다. 항상fsync를 무효로 하는 관리자가 있는 한편, 무엇인가 부적당한 것이 발생했을 경우에 명확한 재기동 포인트가 존재하는 것 같은 때는, 초기의 대량 읽을 때에만 무효로 하는 관리자도 있습니다. 한층 더 항상fsync를 유효하게 하는 관리자도 있습니다. 디폴트는, 최대한의 신뢰성의 확보를 위해,fsync를 유효하게 되어 있습니다. 만약 사용하고 있는 운영 시스템, 하드웨어, 유틸리티 회사(혹은 배터리 백업)를 신뢰한다면,fsync를 무효로 하는 것을 검토해도 좋을 것입니다.
이 매개변수는postgresql.conf파일내, 또는, 서버의 커멘드 라인에서만 설정 가능합니다. 이 매개변수를 무효로 하는 경우,full_page_writes또한 무효로 되는 것을 검토해 주세요.
WAL의 갱신을 디스크에 강제하는데 사용되는 방법입니다. fsync가 오프의 경우 이 설정은 도움이 되지 않습니다. 갱신이 전혀 강제당하지 않기 때문입니다. 취할 수 있는 값은 이하의 것입니다.
open_datasync
(open() option O_DSYNC로 WAL 파일을 기입)
fdatasync
(각 커밋 실행시 마다fdatasync()를 호출)
fsync_writethrough
(어떠한 디스크 기입 캐시도 write through(연속 기입) 시키기 때문에, 각 커밋 실행 마다fsync()를 호출)
fsync
(각 커밋 실행시 fsync()를 호출)
open_sync
(open() option O_SYNC로 WAL 파일을 기입)
모든 플랫폼에서 이러한 모든 선택사항을 사용할 수 있는 것은 아닙니다. 디폴트는, 위의 리스트로 플랫폼에서 지원되는 것 중에서 선두에 있는 것입니다. 또,open_*옵션은 가능하면O_DIRECT를 사용합니다. 이 매개변수는postgresql.conf파일내, 또는, 서버의 커멘드 라인에서만 설정 가능합니다.
이 매개변수가 유효한 경우,PostgreSQL서버는 디스크 페이지의 모든 내용을, 체크 포인트의 뒤, 그 페이지의 최초의 변경 과정에서 WAL에 기입합니다. 운영 시스템이 크래시 했을 때에 진행중의 페이지 기입은 부분적으로 완료되지 않을 가능성이 있기 때문에, 이것이 필요합니다. 이 경우, 디스크상의 페이지는 오래된 데이터와 새로운 데이터가 혼재하는 상태가 됩니다. 통상 WAL내에 보존되는 행 레벨의 변경 데이터는, 크래쉬 후의 복구시 이러한 페이지를 회복시키기에는 불충분합니다. 완전한 페이지 이미지가, 페이지를 정확하게 복구할 수 있는 것을 보증합니다. 그러나, WAL에 기입하지 않으면 안 되는 데이터량이 증가합니다. (WAL 재생은 항상 체크 포인트에서 시작되기 때문에, 체크 포인트 후의 최초의 변경시에 이것을 실시하는 것이 충분합니다. 따라서, 완전 페이지 서두의 코스트를 저감 하는 방법의 하나는, 체크 포인트 간격 매개변수를 늘리는 것입니다. )
이 매개변수를 무효로 하면, 통상의 조작 속도가 오릅니다. 그러나, 운영 시스템의 크래쉬나 전원 장해의 뒤의 데이터베이스 파손을 가져올지도 모릅니다. 이 위험성은 작으면서fsync를 무효로 했을 경우와 유사합니다. (배터리 백업 디스크 콘트롤러와 같은) 하드웨어나 허용 할 수 있는 저레벨에서의 부분 기입의 위험성을 감소시키는 파일 시스템 소프트웨어(ReiserFS 4등)가 있으면, 이 매개변수를 무효로 해도 안전할지도 모릅니다.
이 매개변수를 무효로 해도 현시점에서 리커버리(PITR) 용의 WAL 아카이브(archive)의 사용에 영향이 없습니다( Section 23.3를 참조해 주세요).
이 매개변수는postgresql.conf파일내, 또는, 서버의 커멘드 라인에서만 설정 가능합니다. 디폴트는on입니다.
WAL 데이터용으로 공유 메모리내에서 사용되는 메모리량입니다. 디폴트는 64킬로바이트(64kB)입니다. 데이터는 각각의 트랜잭션(transaction) 커밋시에 디스크에 기입되기 때문에, 설정으로서는, 1개의 전형적인 트랜잭션(transaction)에 의해 생성되는 WAL 데이터를 보존할 수 있는 충분한 크기인 것만을 필요로 합니다. 이 매개변수는 서버 기동시만 설정 가능합니다.
이 매개변수를 증가시키면, 사용하고 있는 운영 시스템의 디폴트 환경설정이 허용 하는System V공유 메모리의 한계를 넘은 요구를PostgreSQL가 실시하는 원인이 되는 경우가 있습니다. 필요하면, 이 매개변수를 조정하는 방법에 관해서Section 16.4.1를 참조해 주십시오.
커밋 레코드를 WAL 버퍼에 기입할 때와 버퍼를 디스크에 플러싱 할때의 밀리 세컨드 단위의 시간차이 지연입니다.
시스템 부하가 높고, 지정 기간내에 커밋 준비를 할 수 있던 트랜잭션(transaction)이 복수 존재했을 경우, 제로 이외의 지연 시간이면 복수의 트랜잭션(transaction)를 한 번의fsync()시스템 콜만으로, 주어진 주기 이내에서 커밋할 수 있습니다.
그러나, 만약 다른 트랜잭션(transaction)를 커밋할 수 있는 상태가 되지 않으면, 이 지연은 쓸데없게 됩니다.
이렇게 말하는 것은, 서버 프로세스가 그 커밋 레코드를 기입한 순간에 다른 트랜잭션(transaction)이 진행되고 있는 commit_siblings에만 적어도 실행됩니다.
디폴트의 값은 제로(지연 없음)입니다.
commit_delay지연을 실행하기 전에 필요하게 되는 동시에 열려 있는 트랜잭션(transaction)의 최소수입니다. 보다 큰 값은, 지연 주기의 사이에, 적어도 1개의 다른 트랜잭션(transaction)가 커밋 준비를 갖추게 하는 것을 확실히 합니다. 디폴트는 5 트랜잭션(transaction)입니다.
Maximum distance between automatic WAL checkpoints, in log file segments (each segment is normally 16 megabytes). The default is three segments. This parameter can only be set in the postgresql.conf file or on the server command line. --> 자동 WAL 체크 포인트간의 최대 로그 파일수입니다. (각각의 세그먼트(segment)는 통상 16 메가바이트) 디폴트는 3 세그먼트(segment)입니다. 이 매개변수는postgresql.conf파일내, 또는, 서버의 커멘드 라인에서만 설정 가능합니다.
Maximum time between automatic WAL checkpoints, in seconds. The default is five minutes (5min). This parameter can only be set in the postgresql.conf file or on the server command line. --> 자동적 WAL 체크 포인트간의 최대 간격을 초단위로 지정합니다. 디폴트는 5분 (5min)입니다. 이 매개변수는postgresql.conf파일, 또는, 서버의 커멘드 라인에서만 설정 가능합니다.
체크 포인트 세그먼트(segment) 파일이 충분한 것이 원인이 되어 일어나는 체크 포인트가, 여기서 지정한 초수보다 빈번하게 발생하는 경우, 서버 로그에 메세지를 작성합니다. (이것은,checkpoint_segments를 호출할 필요가 있는 것을 시사하고 있습니다). 디폴트는 30초(30s)입니다. 영의 경우는 경고를 발행하지 않습니다. 이 매개변수는postgresql.conf파일, 또는, 서버의 커멘드 라인에서만 설정 가능합니다.
일련의 WAL 파일의 완료한 세그먼트(segment)의 저장을 실행하는 쉘 커멘드입니다. 문자열내의 어떠한%p는, 저장되는 파일의 절대 경로로 옮겨놓을 수 있고 그리고,%f는 파일명만 치환합니다. (이 경로명은 서버의 작업용 디렉토리, 즉, 클러스터의 데이터 디렉토리로부터의 상대 경로입니다. ) 커멘드내에서 실제의%문자를 내장하려면%%를 사용합니다. 보다 자세하게는Section 23.3.1을 참조해 주십시오. 이 매개변수는postgresql.conf파일, 또는, 서버의 커멘드 라인에서만 설정 가능합니다. 서버 기동시에archive_mode가 유효하지 않으면, 이것은 무시됩니다. archive_command가 공문자열(디폴트), 한편,archive_mode가 유효한 경우, WAL 아카이브(archive) 처리는 임시적으로 무효가 됩니다만, 커멘드가 다음에 제공되는 것을 예측해, 서버는 WAL 세그먼트(segment)의 축적을 계속합니다.
성공했을 경우에 한해서, 또 그 때에 한해서, 제로를 제거하는 상태를 반환하는 것이 이 커멘드에서는 중요합니다. 이하에 예를 나타냅니다.
archive_command = 'cp "%p" /mnt/server/archivedir/"%f"' archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
archive_command(은)는 완료한 WAL 세그먼트(segment) 에 대해서만 호출됩니다. 서버가 거의 없는 WAL 트래픽을(또는 처리를 실행하는 슬랙 시간을 갖는다)생성하는 경우, 트랜잭션(transaction)의 완료와 아카이브(archive) 저장 영역에의 안전한 기록과의 사이에 장기에 걸치는 지연이 있게 됩니다. 오래된 아카이브(archive)가 아닌 데이터에 제한을 붙이기 위해서,archive_timeout를 설정해, 강제적으로 서버를 새로운 WAL 세그먼트(segment)에 정기적으로 전환하도록 할 수 있습니다. 이 매개변수가 0보다 크면, 서버는 전회의 세그먼트(segment) 파일 변환으로부터 지정초수경과했을 경우에 새로운 세그먼트(segment) 파일로 전환합니다. 강제 변환에 의해 조기 에 갇힌 아카이브(archive)가 끝난 파일은 완전하게 완료한 파일과 같은 크기를 가지는 것에 주의해 주세요. 그 때문에, 매우 작은archive_timeout를 사용하는 것은 추천하지 않습니다. 저장 영역을 팽창시켜 버립니다. 통상이라면 분 단위의archive_timeout설정이 합리적입니다. 이 매개변수는 postgresql.conf파일내, 또는, 서버의 커멘드 라인에서만 설정 가능합니다.