작업을 하기 전에 디스크의 데이터베이스 저장소 영역을 초기화해야 한다.이것을 데이터베이스 클러스터라고 한다(표준 SQL에서는 카탈로그 클러스터라고 함.).
데이터베이스 클러스터는 실행 중인 데이터베이스 서버의 단일 인스턴스에 의해 관리되는 데이터베이스 컬렉션이다.
초기화 후 데이터베이스 클러스터에는 일명postgres
라는 데이터베이스가 포함되는데, 이것은 유틸리티, 사용자 및 타사 어플리케이션이 사용하는 기본 데이터베이스이다.
데이터베이스 서버 자체는 postgres
데이터베이스가 불필요하지만, 다수의 외부 유틸리티 프로그램은 이 데이터베이스가 존재한다는 것을 전제로 한다.
초기화 중에 각 클러스터 내에 생성되는 또 다른 데이터베이스는 template1
이라고 한다.
이름에서 알 수 있듯이, 이것은 이후에 생성된 데이터베이스의 템플릿으로 사용되며, 실제 작업에 사용해서는 안 된다(클러스터 내에서 데이터베이스로 새로 생성하는 방법은 22장 참조.).
파일 시스템의 관점에서, 데이터베이스 클러스터는 모든 데이터가 저장되는 단일 디렉터리이다.
이것을 데이터 디렉터리 또는 데이터 영역이라고 한다.
데이터를 어디에 저장할 것인지는 전적으로 사용자의 선택에 달려 있다.
/usr/local/pgsql/data
또는
/var/lib/pgsql/data
가 일반적이다.
이 디렉터리를 서버에서 사용하려면, 먼저
설치된 PostgreSQL의
initdb
명령을 이용해서 데이터베이스 클러스터를 초기화 해야한다.
미리 패키징된 PostgreSQL 버전을
사용하는 경우라면, 이미 이 디렉터리가
지정되어 있는 경우도 있다. 또한 이 초기화 작업을 쉽게
할 수 있는 스크립트를 제공하고 있을 수도 있다. 이 경우라면,
initdb
명령을 이용하지 말고,
그 스크립트를 이용해야한다. 자세한 것은
해당 패키지 사용 설명서를 참조한다.
데이터베이스 클러스터를 수동으로 초기화 하려면,
initdb
명령을 이용하고
데이터베이스 클러스터의 원하는 파일 시스템 위치는 -D
옵션으로 나타낼 수 있다.
예를 들면:
$
initdb -D /usr/local/pgsql/data
앞에서 설명한 대로 PostgreSQL 사용자 계정으로 로그인한 상태에서 이 명령을 실행해야 한다.
또는, 다음과 같이 pg_ctl 프로그램으로 initdb
를 실행할 수 있다.
$
pg_ctl -D /usr/local/pgsql/data initdb
좀 더 직관적으로, 서버를 시작하고 중지하는 데 pg_ctl
을 사용하면(18.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 사용자를 제외한 모든 사용자로부터 접근 권한을 해지한다. 선택적으로 그룹 읽기를 허용할 수도 있다.
그룹 접근은 읽기 전용이어야한다. 데이터베이스 서버를 실행한
사용자의 그룹과 같은 다른 사용자가 해당 데이터 파일을
백업 받을 수 있으며, 기타 읽기 관련 작업을 할 수 있게 된다.
Note that enabling or disabling group access on an existing cluster requires
the cluster to be shut down and the appropriate mode to be set on all
directories and files before restarting
PostgreSQL. Otherwise, a mix of modes might
exist in the data directory. For clusters that allow access only by the
owner, the appropriate modes are 0700
for directories
and 0600
for files. For clusters that also allow
reads by the group, the appropriate modes are 0750
for directories and 0640
for files.
단, 디렉터리 내용이 보호 중인 경우 기본 클라이언트 인증 설정은 로컬 사용자의 데이터베이스 연결을 허용하고 로컬 사용자가 데이터베이스 수퍼유저가 되는 것을 허용하기도 한다.
다른 로컬 사용자를 신뢰하지 않을 경우에는 initdb
의 -W
, --pwprompt
또는 --pwfile
옵션 중 하나를 사용하여 데이터베이스 수퍼유저에게 패스워드를 할당하는 것이 좋다.
또한 -A md5
또는
-A password
를 지정하여 기본 trust
인증 모드가 사용되지 않게 하거나, 서버를 처음으로 시작하기 전에 initdb
를 실행한 후 생성된 pg_hba.conf
파일을 수정해야 한다. (기타 합리적 접근법에는 peer
인증 또는 파일 시스템 권한을 사용하여 연결을 제한하는 것이 있다.
자세한 내용은 20장 참조.)
initdb
에서 데이터베이스 클러스터의 기본 로케일()을 초기화할 수도 있다.
일반적으로는 환경의 로케일(locale) 설정을 가져와서, 이것을 초기화된 데이터베이스에 적용한다. 데이터베이스에 서로 다른 로케일(locale)을 지정할 수 있다.
자세한 내용은 23.1절에 나와 있다.
특정 데이터베이스 클러스터 내에서 사용되는 기본 정렬 순서는 initdb
로 설정되며, 서로 다른 정렬 순서로 새로운 데이터베이스를 생성하는 경우 initdb로 생성된 템플릿 데이터베이스에 사용되는 정렬 순서는 삭제 및 재생성하지 않고는 변경할 수 없다.C
또는 POSIX
이외의 로케일(locale)을 사용하는 경우 성능에도 영향을 미칠 수 있다.
따라서 처음부터 올바른 선택을 하는 것이 중요하다.
initdb
로 데이터베이스 클러스터용 기본 문자 집합 인코딩도 설정한다.
일반적으로, 이것은 로케일(locale) 설정과 동일하게 선택해야 한다.
자세한 내용은 23.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.
일반적으로 POSIX 호환 파일 시스템이라면 어떤 것도 상관 없이 PostgreSQL에서는 사용할 수 있다. 사용자들은 벤더 기술지원, 성능, 친숙함 등 다양한 이유로 여러 파일 시스템을 각각 사용한다. 경험상, 다른 것들은 모두 동일한데, 파일 시스템의 종류를 바꾼다거나, 사소한 파일 시스템 환경 설정을 바꾼다고 해도, 성능이 크게 좋아진다거나, 기능이 크게 바뀌지는 않는다.
PostgreSQL 데이터 디렉터리로 NFS 파일 시스템을 사용할 수 있다. PostgreSQL은 NFS 파일 시스템도 그냥 로컬 드라이브와 같은 것으로 여긴다. 데이터베이스 내부적으로 사용하는 파일 처리 작업은 똑같다. 파일 잠금 처리가 한 예다.
단, NFS 파일 시스템을 사용할 때는,
PostgreSQL에서는 그 파티션이
hard
옵션을 지정해서 마운트한 것을
사용해야 한다.
hard
옵션을 사용하면,
네트워크 통신 문제가 있을 경우, 서버가 “멈출 수 있다.”
그래서, 세심한 모니터링이 필요하다.
soft
옵션을 사용하면,
네트워크 통신 문제가 있을 경우, 파일 시스템이 시스템 콜을 무시할 수
있는데, 이 경우, PostgreSQL은
이렇게 처리 안된 시스템 콜을 다시 처리하지 않아, 입출력 오류가
생길 수도 있다.
sync
옵션은 지정하지 않아도 된다.
async
옵션으로도 충분하다. PostgreSQL
내부적으로 필요한 경우는
캐시를 디스크로 쓰는 플러시 작업을 하는 fsync
호출을 충실히 한다. (로컬 파일 시스템에서 작동하는 방식과 같다.)
하지만, 대부분 NFS 서버로 사용하는
시스템(일반적으로 리눅스)의 export 설정에서는
sync
옵션을 지정하는 것을 권장한다.
한편, NFS 클라이언트가 호출하는 fsync
또는
그 같은 역할을 하는 작업이 반드시 서버에 있는 스토리지에
완벽하게 썼다고 보장하지는 않는다. 이는 데이터베이스 서버가
비정상적으로 종료 되었을 때 커밋된 자료를 잃어버릴 수 있는
fsync off 상태와 같다고 간주 할 수 있다.
NFS 파일 시스템의 마운트 옵션과 서버의 export 옵션의 기본값이
각 벤더사와 버전에 따라 다양하다. 그래서, 자신이 쓰는 환경에서
앞에서 다룬 문제들을 최대한 피할 수 있는 설정은 스스로
확인하고 사용해야한다.
한 경우로, NFS 파일 시스템이 아닌, iSCSI 같은 저수준 프로토콜로 접근할 수 있는 외장 스토리지를 사용할 수 있는데, 이 경우는 OS 상에서는 블록 장치로 보이고, 이것을 원하는 파일 시스템으로 만들어서 사용할 수 있다. 이런 경우는 NFS 사용할 때와 달리 DBA가 신경 쓸 부분이 줄지만, iSCSI 서버와 원격 스토리지 설정, 사용에 따른 또 다른 수준의 작업이 필요하다.