PostgreSQL 9.5.4 문서 | |||
---|---|---|---|
이전 | 위로 | 장 17. 서버 설정 및 운용 | 다음 |
작업을 하기 전에 디스크의 데이터베이스 저장소 영역을 초기화해야 한다.이것을 데이터베이스 클러스터라고 한다(표준 SQL에서는 카탈로그 클러스터라고 함.). 데이터베이스 클러스터는 실행 중인 데이터베이스 서버의 단일 인스턴스에 의해 관리되는 데이터베이스 컬렉션이다. 초기화 후 데이터베이스 클러스터에는 일명postgres라는 데이터베이스가 포함되는데, 이것은 유틸리티, 사용자 및 타사 어플리케이션이 사용하는 기본 데이터베이스이다. 데이터베이스 서버 자체는 postgres 데이터베이스가 불필요하지만, 다수의 외부 유틸리티 프로그램은 이 데이터베이스가 존재한다는 것을 전제로 한다. 초기화 중에 각 클러스터 내에 생성되는 또 다른 데이터베이스는 template1이라고 한다. 이름에서 알 수 있듯이, 이것은 이후에 생성된 데이터베이스의 템플릿으로 사용되며, 실제 작업에 사용해서는 안 된다(클러스터 내에서 데이터베이스로 새로 생성하는 방법은 21장 참조.).
파일 시스템의 관점에서, 데이터베이스 클러스터는 모든 데이터가 저장되는 단일 디렉터리이다. 이것을 데이터 디렉터리 또는 데이터 영역이라고 한다. 데이터를 어디에 저장할 것인지는 전적으로 사용자의 선택에 달려 있다. /usr/local/pgsql/data 또는 /var/lib/pgsql/data가 일반적이지만, 필수는 아니다. 데이터베이스 클러스터를 초기화하려면 PostgreSQL과 함께 설치된 initdb 명령을 사용한다. 데이터베이스 클러스터의 원하는 파일 시스템 위치는 -D 옵션으로 나타낼 수 있다. 예를 들면:
$ initdb -D /usr/local/pgsql/data
앞에서 설명한 대로 PostgreSQL 사용자 계정으로 로그인한 상태에서 이 명령을 실행해야 한다.
작은 정보: -D 옵션 대신 환경 변수 PGDATA를 설정할 수 있다.
또는, 다음과 같이 pg_ctl 프로그램으로 initdb를 실행할 수 있다.
$ pg_ctl -D /usr/local/pgsql/data initdb
좀 더 직관적으로, 서버를 시작하고 중지하는 데 pg_ctl을 사용하면(17.3절참조), pg_ctl은 데이터베이스 서버 인스턴스를 관리하는 유일한 명령이 된다.
initdb 명령은 지정한 디렉터리가 없으면, 직접 만든다. 이 때 이 명령을 수행하는 운영체제 사용자가 그 디렉터리를 만들 권한이 있어야 한다. 일반적으로 데이터 클러스터 디렉터리의 상위 디렉터리에 그 사용자에 대한 쓰기 권한이 있어야 한다. 그렇지 않고, 단순히 데이터 클러스터 디렉터리에 대해서만, 해당 소유권을 지정하고 싶다면, 먼저 root 권한으로 데이터 클러스터로 사용될 디렉터리를 만들고, 그 디렉터리의 소유주를 바꾸어 준다. 통상 일반적인 데이터 클러스터 초기화 작업은 다음과 같은 형태로 진행된다:
root# mkdir /usr/local/pgsql root# chown postgres /usr/local/pgsql root# su postgres postgres$ initdb -D /usr/local/pgsql/data
initdb 명령은 지정한 데이터 클러스터 디렉터리 안에 어떤 파일이 있으면, 이미 초기화 작업을 진행한 것으로 판단하고, 중지 된다.
데이터 디렉터리에는 데이터베이스의 모든 데이터가 저장되어 있으므로 무단 액세스로부터 데이터 디렉터리를 보호하는 것이 중요하기 때문에 initdb는 PostgreSQL 사용자를 제외한 모든 사용자로부터 접근 권한을 해지한다.
단, 디렉터리 내용이 보호 중인 경우 기본 클라이언트 인증 설정은 로컬 사용자의 데이터베이스 연결을 허용하고 로컬 사용자가 데이터베이스 수퍼유저가 되는 것을 허용하기도 한다. 다른 로컬 사용자를 신뢰하지 않을 경우에는 initdb의 -W, --pwprompt 또는 --pwfile 옵션 중 하나를 사용하여 데이터베이스 수퍼유저에게 패스워드를 할당하는 것이 좋다. 또한 -A md5 또는 -A password를 지정하여 기본 trust 인증 모드가 사용되지 않게 하거나, 서버를 처음으로 시작하기 전에 initdb를 실행한 후 생성된 pg_hba.conf 파일을 수정해야 한다. (기타 합리적 접근법에는 peer 인증 또는 파일 시스템 권한을 사용하여 연결을 제한하는 것이 있다. 자세한 내용은 19장 참조.)
initdb에서 데이터베이스 클러스터의 기본 로케일()을 초기화할 수도 있다. 일반적으로는 환경의 로케일(locale) 설정을 가져와서, 이것을 초기화된 데이터베이스에 적용한다. 데이터베이스에 서로 다른 로케일(locale)을 지정할 수 있다. 자세한 내용은 22.1절에 나와 있다. 특정 데이터베이스 클러스터 내에서 사용되는 기본 정렬 순서는 initdb로 설정되며, 서로 다른 정렬 순서로 새로운 데이터베이스를 생성하는 경우 initdb로 생성된 템플릿 데이터베이스에 사용되는 정렬 순서는 삭제 및 재생성하지 않고는 변경할 수 없다.C 또는 POSIX 이외의 로케일(locale)을 사용하는 경우 성능에도 영향을 미칠 수 있다. 따라서 처음부터 올바른 선택을 하는 것이 중요하다.
initdb로 데이터베이스 클러스터용 기본 문자 집합 인코딩도 설정한다. 일반적으로, 이것은 로케일(locale) 설정과 동일하게 선택해야 한다. 자세한 내용은 22.3절 참조.
C 로케일이 아닌 경우나, POSIX 로케일이 아닌 경우 해당 운영체제의 문자세트 정렬 라이브러리를 사용한다. 이것은 인덱스에서 키의 정렬 순서를 관여한다. 이런 이유로, 한 클러스터의 스냅샷 복원, 바이너리 스트리밍 복제 작업은 이 정렬 라이브러리가 운영체제가 달라서, 또는 운영체제 업그레이드로 달라질 경우 정상적으로 처리되지 않을 수 있다.
참고: initdb 기본 동작 방식이 운영체제의 언어 환경에 따라 기본 로케일을 자동으로 판단한다. 즉, initdb 명령을 수행하는 운영체제의 쉘 환경 설정이 한국어로 되어 있다면, 자동으로 로케일 설정이 한국어로 지정되어 클러스터가 만들어진다. 이렇게 만들어지면, 한국어 자료에 대한 인덱스 사용에 따른 쿼리 최적화가 의도된 대로 작동하지 않을 수 있다.
그래서, 일반적으로 한국어 환경에서는 이 부분을 고려하여 다음과 같이 데이터 클러스터 초기화 작업을 진행한다.
$ initdb -D /usr/local/pgsql/data -E utf8 --no-locale
Many installations create their database clusters on file systems (volumes) other than the machine's "root" volume. If you choose to do this, it is not advisable to try to use the secondary volume's topmost directory (mount point) as the data directory. Best practice is to create a directory within the mount-point directory that is owned by the PostgreSQL user, and then create the data directory within that. This avoids permissions problems, particularly for operations such as pg_upgrade, and it also ensures clean failures if the secondary volume is taken offline.
Many installations create their database clusters on network file systems. Sometimes this is done via NFS, or by using a Network Attached Storage (NAS) device that uses NFS internally. PostgreSQL does nothing special for NFS file systems, meaning it assumes NFS behaves exactly like locally-connected drives. If the client or server NFS implementation does not provide standard file system semantics, this can cause reliability problems (see http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html). Specifically, delayed (asynchronous) writes to the NFS server can cause data corruption problems. If possible, mount the NFS file system synchronously (without caching) to avoid this hazard. Also, soft-mounting the NFS file system is not recommended.
Storage Area Networks (SAN) typically use communication protocols other than NFS, and may or may not be subject to hazards of this sort. It's advisable to consult the vendor's documentation concerning data consistency guarantees. PostgreSQL cannot be more reliable than the file system it's using.