まず第一に、ディスク上にデータベース格納領域を初期化する必要があります。 この格納領域をデータベースクラスタと呼びます(SQLではカタログクラスタという用語が使用されます)。 データベースクラスタはデータベースの集合で、稼働しているデータベースサーバのただ1つのインスタンスを通して管理されます。 初期化が終わると、データベースクラスタにはpostgresという名前のデータベースが含まれています。 このデータベースは、ユーティリティやユーザ、サードパーティ製アプリケーションのデフォルトデータベースとして用意されています。 データベースサーバ自身はこのpostgresデータベースの存在を必要としていません。 初期化中に他にもtemplate1というデータベースが各クラスタ内に作成されます。 その名前から推測できるように、これはその後に作成されるデータベースのテンプレートとして使われます。 したがって、実際の作業に使用すべきではありません (クラスタ内における新しいデータベースの作成については第21章を参照してください)。
ファイルシステムの観点から見ると、データベースクラスタというのは、全てのデータが格納される1つのディレクトリということになります。 これはデータディレクトリもしくはデータ領域と呼ばれます。 どこにデータを格納するかは完全にユーザの自由です。 特にデフォルトの領域はありませんが、一般的によく使われるのは/usr/local/pgsql/dataか/var/lib/pgsql/dataです。 データベースクラスタを初期化するためには、PostgreSQLと一緒にインストールされるinitdbコマンドを使用してください。 データベースクラスタのファイルシステム上の場所は-Dオプションで示します。 例えば次のようにします。
$ initdb -D /usr/local/pgsql/data
このコマンドは、前節で説明したPostgreSQLユーザアカウントでログインして実行する必要があります。
もし指定したディレクトリが存在しない場合は、initdbはその新しいディレクトリを作成しようとします。 しかし(ここのアドバイスに従って非特権アカウントを作成した場合など)作成権限がない場合があります。 その場合は(rootとして)手動でディレクトリ自体を作成し、その所有者をPostgreSQLユーザに変更します。 下記がその例となります。
root# mkdir /usr/local/pgsql/data root# chown postgres /usr/local/pgsql/data root# su postgres postgres$ initdb -D /usr/local/pgsql/data
データディレクトリが既に初期化されているように見える場合は、initdbは実行を拒否します。
データディレクトリにはデータベースの中の全てのデータが保持されるため、権限を持たない人のアクセスを確実に制限することが不可欠です。 ですから、initdbはPostgreSQLユーザ以外にはアクセス権を与えません。
しかし、ディレクトリの内容は安全ですが、デフォルトのクライアント認証の設定では、全てのローカルユーザはデータベースに接続でき、データベーススーパーユーザになることさえ可能です。 他のローカルユーザを信用しない場合、initdbの-W、--pwprompt、--pwfileオプションのいずれか1つを使用して、データベーススーパーユーザにパスワードを付与することを推奨します。 また、デフォルトのtrust認証モードを使用しないように、-A md5もしくは-A passwordを指定してください。 もしくは、initdbの後、初回のサーバの起動の前に、生成済みのpg_hba.confファイルを変更してください (他の穏当な方法として、ident認証やファイルシステムの権限を使用して、接続を制限することもできます。 詳細については第19章を参照してください)。
initdbはまた、データベースクラスタのデフォルトのロケールを初期化します。 通常は、環境のロケール設定を初期化されたデータベースにそのまま適用します。 データベースに異なるロケールを指定することも可能です。 詳細については項22.1を参照してください。 特定のデータベースクラスタ内で使用されるデフォルトのソート順はinitdbで設定されます。 異なるソート順を使用する新しいデータベースを作成することもできますが、initdbが作成するテンプレートデータベースで使用される順は削除して再作成しない限り変更することができません。 また、CやPOSIX以外のロケールを使用する場合には性能上の影響もあります。
またinitdbは、データベースクラスタのデフォルトの文字セット符号化方式も設定します。 通常これは、ロケールの設定と合うものが選ばれなければなりません。 詳細は項22.2を参照してください。
多くのインストレーションはネットワークファイルシステム上にデータベースクラスタを作成します。 直接NFSを介して行うこともありますし、NFSを内部的に使うネットワークアタッチトストレージ(NAS)デバイスを使用することもあります。 PostgreSQLはNFSファイルシステムに特別なことを何も行いません。 つまりNFSはローカル接続のドライブ(DAS、ダイレクトアタッチトストレージ)とまったく同様に振る舞うという前提です。 クライアントとサーバのNFS実装が標準セマンティックスを持たないならば、信頼性に関する問題が発生します (http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html参照)。 特にNFSサーバへの遅延(非同期)書きこみが信頼性に関する問題を引き起こします。 可能ならばNFSファイルシステムを(キャッシュ無しで)同期マウントし、これを防止してください。更に、NFSをソフトマウントすることは薦められません。 (ストレージエリアネットワーク(SAN)はNFSよりも低レベルな通信プロトコルを使用します。)