| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 16. 운영 시스템의 환경 | Fast Forward | Next |
데이터베이스에 접근하기 위해서는, 우선 데이터베이스 서버를 기동하지 않으면 안됩니다. 데이터베이스 서버 프로그램은 postgres라는 이름입니다. postgres프로그램은 자신이 사용하는 데이터가 어디에 있는지 알고 있을 필요가 있어, 이것은 -D옵션으로 지정할 수 있습니다. 따라서, 서버를 기동하는 제일 간단한 방법은, 이하와 같은 명령입니다.
$ postgres -D /usr/local/pgsql/data
상기의 명령은, 서버를 foreground로 실행시킵니다. 이것은, PostgreSQL사용자계정에 로그인해 실행되지 않으면 안됩니다. -D옵션이 지정되어 있지 않은 경우, 서버는 PGDATA환경 변수로 지정된 데이터 디렉토리를 사용하려고 시도합니다. 어느 쪽의 변수도 지정되어 있지 않으면 실패합니다.
통상은, 백그라운드에서 postgres를 기동하는 것을 추천합니다. 이를 위해, 이하와 같이 통상의 쉘의 구문을 사용합니다.
$ postgres -D /usr/local/pgsql/data >logfile 2>&1 &
이 예와 같이, 서버의 표준 출력과 표준 에러출력을 어디엔가 보관해 두는 것이 중요합니다. 이것은 추적 기록의 목적과 문제의 원인 구명에 도움이 됩니다 (로그 파일의 취급에 대한 전체적인 설명에 대해서는 Section 22.3을 참조해 주세요).
postgres프로그램에는, 이 그 밖에도 많은 명령 라인 옵션을 지정할 수가 있습니다. 자세한 것은 postgres 레퍼런스 페이지와 후술하는 Chapter 17을 참조해 주세요.
이러한 쉘 구문은 길어지기 쉽습니다. 그 때문에, pg_ctl 프로그램이 제공되고 있어, 몇개의 과업을 단순화하고 있습니다. 이하에 예를 나타냅니다.
pg_ctl start -l logfile
이것은, 서버를 백그라운드에서 기동해, 출력이 지정된 로그 파일에 써냅니다. -D옵션은, 여기에서도 postgres의 경우와 같은 의미를 가집니다. pg_ctl에 의해 서버를 정지시킬 수도 있습니다.
통상, 컴퓨터가 기동되었을 때에 데이터베이스 서버도 함께 기동하고 싶은 경우가 많다고 생각됩니다. 자동 기동 스크립트는, 운영시스템 고유의 것입니다. 몇 가지는 PostgreSQL의 /contrib/start-scripts디렉토리에 부여되고 있습니다. 이 설치에는 루트 권한이 필요합니다.
기동시에 demon를 개시하는 방법은 시스템에 따라서 다릅니다. 많은 시스템에는 /etc/rc.local파일이나 /etc/rc.d/rc.local파일이 있습니다. 다른 시스템에서는 rc.d디렉토리가 사용됩니다. 무엇을 실행 한다고 해도, 서버는 PostgreSQL사용자계정으로 기동시키지 않으면 안됩니다. 루트여서는 안되고 , 다른 사용자라도 쓸 만하지 않습니다. 따라서, su -c '...' postgres를 사용해 명령을 실행하는 것이 좋을 것입니다. 이하에 예를 나타냅니다.
su -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog' postgres
한층 더 몇 가지의 운영시스템 고유의 제안을 듭니다 (여기에서는 일반적인 값으로 설명하고 있기 때문에, 각 항목에 대해 적절한 설치 디렉토리와 사용자명에 옮겨놓아 읽어 주세요).
FreeBSD에서는, PostgreSQL로 배포되는 소스안에 있는 contrib/start-scripts/freebsd파일을 참조해 주세요.
OpenBSD에서는, 이하의 몇 줄기를 /etc/rc.local파일에 추가해 주세요.
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then
su - -c '/usr/local/pgsql/bin/pg_ctl start -l /var/postgresql/log -s' postgres
echo -n ' postgresql'
fi
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
(을)를 /etc/rc.d/rc.local에 추가해 주세요. 또는, PostgreSQL로 배포되는 소스안에 있는 contrib/start-scripts/linux파일을 참조해 주세요.
Solaris에서는, /etc/init.d/postgresql라는 파일을 작성해, 거기에 이하의 1행을 기술해 주세요.
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
그리고, /etc/rc3.d이하에 S99postgresql로서 그 파일에 대한 기호 연결을 작성해 주세요.
서버가 실행하고 있는 동안은, 그 PID는 데이터 디렉토리 안의 postmaster.pid파일에 기술되고 있습니다. 이것은 같은 데이터 디렉토리에서 복수의 서버 인스턴스가 실행되는 것을 방지하고, 또, 서버의 종료에도 사용할 수 있습니다.
서버의 기동이 실패하는 이유로서 대표적인 것이 몇 가지가 있습니다. 서버의 로그 파일을 체크하는지, (표준 출력이나 표준 에러를 리디렉트하지 않고) 수동으로 기동해, 어떠한 에러 메세지가 나와 있는지 확인해 주세요. 이하에, 자주 발생하는 에러 메세지의 몇가지를 보다 상세하게 설명합니다.
LOG: could not bind IPv4 socket: Address already in use HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. FATAL: could not create TCP/IP listen socket
이것은 대부분의 경우 메세지가 나타내는 그대로의 의미입니다. 이미 서버가 움직이고 있는 포트로 다른 postmaster를 기동하려고 한 것을 나타내고 있습니다. 그러나, 커넬 에러 메세지가 Address already in use나 거기에 유사한 것이 아닌 경우는, 다른 문제의 가능성도 있습니다. 예를 들면, 예약 끝난 포트 번호로 서버를 기동하려고 하면 아래와 같은 메세지가 나올지도 모릅니다.
$ postgres -p 666 LOG: could not bind IPv4 socket: Permission denied HINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry. FATAL: could not create TCP/IP listen socket
다음과 같은 메세지가 표시되었을 경우,
FATAL: could not create shared memory segment: Invalid argument DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600).
이것은, 아마 커넬에 의한 공유 메모리의 사이즈의 상한이 PostgreSQL가 만들려 하고 있는 작업 영역보다 작을 가능성이 있습니다 (이 예에서는 4011376640바이트입니다). 또는, System V방식의 공유 메모 리사 포트가 커넬에 전혀 설정되어 있지 않을 가능성도 있습니다. 일시적인 방법으로서(shared_buffers를 사용해) 서버를 통상보다 적은 버퍼수로 기동할 수도 있습니다. 그러나 최종적으로는, 커넬을 재설정해, 사용 가능한 공유 메모 리사이즈를 늘리는 것이 좋을 것입니다. 이 메세지는, 같은 머신상에서 복수의 서버를 기동하려고 했을 때에, 요구된 영역의 합계가 커넬의 상한을 넘었을 경우에도 표시됩니다.
아래와 같은 에러는 디스크의 빈 용량이 없어졌다고 하는 것을 나타내고 있는 것은 아닙니다 .
FATAL: could not create semaphores: No space left on device DETAIL: Failed system call was semget(5440126, 17, 03600).
이것은 커넬의 System Vsemaphore의 상한이, PostgreSQL가 작성하려는 수보다 작다는 것을 의미하고 있습니다. 상기와 같이, 허가되는 접속의 수를 줄여(max_connections를 사용해) 서버를 기동시키는 것으로 문제는 회피할 수 있을지도 모릅니다만, 최종적으로는 커넬의 설정을 바꾸어 semaphore의 상한을 늘리는 것이 좋을 것입니다.
"illegal system call"라고 하는 에러가 표시되었을 경우는, 사용하고 있는 커넬에서는 공유 메모리나 semaphore가 전혀 지원되지 않을 가능성이 있습니다. 그 경우, 이러한 기능을 사용할 수 있도록 커넬을 다시 설정하는 것이 유일한 선택사항이 됩니다.
System V IPC설비의 설정에 대한 자세한 것은 Section 16.4.1을 참조해 주세요.
클라이언트측에서 일어날 수 있는 에러 상태는 극히 다양해, 어플리케이션에 의존합니다. 그 중의 몇개는 서버가 기동된 방법과 직접 관계할지도 모릅니다. 이하로 설명하는 이외 상태에 대해서는 각각의 클라이언트 어플리케이션의 자료를 참조해 주세요.
psql: could not connect to server: Connection refused
Is the server running on host "server.joe.com" and accepting
TCP/IP connections on port 5432?
이것은 일반적인 "접속하는 서버를 찾아낼 수 없다"는 실패입니다. TCP/IP통신을 시도했을 때에 상기와 같이 표시됩니다. 자주 있는 실수는 서버에 TCP/IP를 허가하는 설정을 잊고 있는 것입니다.
대신에, 로컬의 서버에 Unix 소켓 통신을 시도하면 아래와 같은 표시가 나옵니다.
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
마지막 행은, 클라이언트가 올바른 곳에 접속하려고 하고 있는 것을 실증하는데 도움이 됩니다. 만약 거기에 움직이고 있는 서버가 없는 경우, 전형적인 커넬 에러 메세지는, 표시되고 있도록 Connection refused 혹은 No such file or directory가 됩니다 (이 경우의 Connection refused는 서버가 접속 요구를 접수 거부한 것이 아닌 것을 이해해 두는 것이 중요합니다. 만약 그랬던 경우는 Section 20.3으로 나타나는 것과 같은 다른 메세지가 표시됩니다). Connection timed out같은 다른 메세지는, 예를 들면 네트워크 접속의 결여와 같은 좀 더 근본적인 문제를 나타내고 있습니다.