まず最初に、ディスク上にデータベース格納領域を初期化する必要があります。
この格納領域をデータベースクラスタと呼びます。（標準SQLではカタログクラスタという用語が使用されています）。
データベースクラスタはデータベースの集合で、稼働しているデータベースサーバのただ一つのインスタンスを通して管理されます。
初期化が終わると、データベースクラスタにはpostgresという名前のデータベースが含まれています。
このデータベースは、ユーティリティ、ユーザ、サードパーティ製アプリケーションが使用するデフォルトデータベースになります。
データベースサーバ自身はこのpostgresデータベースの存在を必要としていませんが、多くの外部ユーティリティはその存在を想定しています。
初期化中に他にもtemplate1とtemplate0という2つのデータベースが各クラスタ内に作成されます。
その名前から推測できるように、これはその後に作成されるデータベースのテンプレートとして使われます。
したがって、実際の作業に使用しない方がよいです。
（クラスタ内における新しいデータベースの作成については第23章を参照してください。）
ファイルシステムの観点から見ると、データベースクラスタというのは、すべてのデータが格納される1つのディレクトリということになります。
これはデータディレクトリもしくはデータ領域と呼ばれます。
どこにデータを格納するかは完全にユーザの自由です。
特にデフォルトの領域はありませんが、一般的によく使われるのは/usr/local/pgsql/dataや/var/lib/pgsql/dataです。
データディレクトリは、使用前にPostgreSQLと一緒にインストールされるコマンドinitdbを使用して初期化する必要があります。
パッケージ化された版のPostgreSQLを使用している場合は、データディレクトリを配置する場所について特別な規則がある場合があります。
また、データディレクトリを作成するためのスクリプトが提供されている場合もあります。
その場合は、initdbを直接実行するのではなくそのスクリプトを使用する必要があります。
詳細についてはパッケージレベルのドキュメントを参照してください。
データベースクラスタを手動で初期化するには、-Dオプションを使用してデータベースクラスタのファイルシステムの場所を指定しinitdbを実行します。
例えば次のようにします。
$initdb -D /usr/local/pgsql/data
このコマンドは、前節で説明したPostgreSQLユーザアカウントでログインしている間に実行する必要があることに注意してください。
他にも以下のようにpg_ctlプログラム経由でinitdbを実行することができます。
$pg_ctl -D /usr/local/pgsql/data initdb
pg_ctlがデータベースサーバインスタンスの管理に使用する単一のコマンドになりますので、サーバの起動や停止にpg_ctlを使用している場合(19.3参照)はこちらの方がより直感的かもしれません。
もし指定したディレクトリが存在しない場合は、initdbはその新しいディレクトリを作成しようとします。
もちろん、その親ディレクトリに書き込み権限がない場合initdbは失敗します。
PostgreSQLユーザがデータディレクトリだけでなく、親ディレクトリも所有することを一般的に推奨します。
このようにすると問題になることはありません。
目的の親ディレクトリが存在しない場合は、まずそのディレクトリを作成する必要があります。
親の親ディレクトリが書き込み可能でない場合は、root権限を使用して作成します。
そのため、手順は下記のようになります。
root#mkdir /usr/local/pgsqlroot#chown postgres /usr/local/pgsqlroot#su postgrespostgres$initdb -D /usr/local/pgsql/data
データディレクトリが存在し、すでにファイルが含まれている場合は、initdbは実行を拒否します。これは、誤って既存のインストールを上書きしないようにするためです。
データディレクトリにはデータベースの中のすべてのデータが保持されるため、権限を持たない人からのアクセスを確実に制限することが不可欠です。
ですから、initdbはPostgreSQLユーザ、更にオプションでグループ以外からのアクセス権を剥奪します。
許可されている場合には、グループアクセスは読み出し専用になります。
これにより、クラスタの所有者と同じグループに所属する非特権ユーザが、そのクラスタのデータをバックアップすることや、読み出し権限だけが必要なその他の操作を実行することが可能になります。
既存のクラスタに対してグループアクセスを有効にする、あるいは無効にするには、PostgreSQLを再起動する前に、クラスタが停止済みの状態で、すべてのディレクトリとファイルに適切なモードが設定されている必要があることに注意してください。
そうでないと、データディレクトリ内に異なるモードが混在してしまうかもしれません。
所有者のみにアクセスを許可するクラスタでは、適切なディレクトリのモードは0700で、ファイルモードは0600です。
加えてグループに対して読み出しを許可するクラスタでは、適切なディレクトリのモードは0750で、ファイルモードは0640です。
しかし、ディレクトリの内容は安全ですが、デフォルトのクライアント認証の設定では、すべてのローカルユーザはデータベースに接続でき、データベーススーパーユーザになることさえ可能です。
他のローカルユーザを信用しない場合、initdbの-W、--pwprompt、--pwfileオプションのいずれか1つを使用して、データベーススーパーユーザにパスワードを付与することを推奨します。
また、デフォルトのtrust認証モードを使用しないように、-A scram-sha-256を指定してください。
もしくは、initdbの後、初回のサーバの起動の前に、生成済みのpg_hba.confファイルを変更してください。
（他の穏当な方法として、peer認証やファイルシステムの権限を使用して、接続を制限することもできます。
詳細については第21章を参照してください。）
initdbはまた、データベースクラスタのデフォルトのロケールを初期化します。
通常は、環境のロケール設定を初期化されたデータベースにそのまま適用します。
データベースに異なるロケールを指定することも可能です。
詳細については24.1を参照してください。
特定のデータベースクラスタ内で使用されるデフォルトのソート順はinitdbで設定されます。
異なるソート順を使用する新しいデータベースを作成することもできますが、initdbが作成するテンプレートデータベースで使用される順は削除して再作成しない限り変更することができません。
また、CやPOSIX以外のロケールを使用する場合には性能上の影響もあります。
ですので初回にこれを正しく選択することが重要です。
またinitdbは、データベースクラスタのデフォルトの文字セット符号化方式も設定します。
通常これは、ロケールの設定と合うものが選ばれなければなりません。
詳細は24.3を参照してください。
非Cおよび非POSIXのロケールでは、文字セットのソート順はオペレーティングシステムの照合ライブラリに依存しています。
これは、インデックスに格納されているキーの順序を制御します。
このためにクラスタは、スナップショットのリストア、バイナリストリーミングレプリケーション、異なるオペレーティングシステム、またはオペレーティングシステムのアップグレードのいずれでも互換性のない照合ライブラリバージョンに切り替えることは出来ません。
多くのインストールでは、マシンの「ルート」ボリューム以外のファイルシステム（ボリューム）上にデータベースクラスタを作成します。 この選択をした場合、セカンダリボリュームの最上位ディレクトリ（マウントポイント）をデータディレクトリとして使用することはお勧めできません。 最善の方法はマウントポイントディレクトリ内にPostgreSQLユーザが所有するディレクトリを作成し、その中にデータディレクトリを作成することです。 これにより、権限の問題、特にpg_upgradeなどの操作での問題を避けることができ、またセカンダリボリュームがオフラインになったときに、確実にきれいなエラーを起こすようになります。
一般的にはPOSIXのセマンティクスを備えたすべてのファイルシステムがPostgreSQLで利用できます。 ユーザはベンダーのサポート、性能、慣れ親しんでいるかどうかなどの様々な理由で異なるファイルシステムを選択します。 経験が示すところによると、これ以外の要素が同じなら、単にファイルシステムを変更したり、ファイルシステムの設定を少し変えただけで大きな性能の違いや挙動の違いがあるとは思わないほうが良いでしょう。
PostgreSQLのデータディレクトリを格納するためにNFSファイルシステムが使えます。 PostgreSQLはNFSファイルシステムのために何ら特別なことはしません。つまりNFSがローカルに接続されたドライブと完全に同じように振る舞うものとみなします。 PostgreSQLは、ファイルのロックなど、NFS上で非標準の振る舞いをすると知られている機能は使いません。
NFSをPostgreSQLで使う上での必須要件はhardオプションを使ってファイルシステムをマウントすることです。
hardオプションでは、ネットワークに問題があればプロセスは永久に「ハング」する可能性があります。ですからこの設定では注意深い監視が必要になります。
softオプションはネットワークに問題があるとシステムコールに割り込みますが、PostgreSQLはこの方法で割り込まれたシステムコールを再発行しません。ですからそのような割り込みに対してはI/Oエラーの発生が報告されることとなります。
syncマウントオプションを使う必要はありません。
asyncオプションの動作で十分です。なぜならPostgreSQLは書き込みキャッシュをフラッシュするために適切な時にfsync呼び出しを発行するからです。
（これはローカルファイルシステム上での動作と同様です。）
しかし、syncエクスポートオプションがあるシステム（主にLinux）上のNFSサーバでは、そのオプションを使うことを強くお勧めします。
さもないとNFSクライアント上のfsync、あるいは同等ものは実際にはサーバ上の永続ストレージに到達することが保証されず、fsyncパラメータをオフにして実行するのと同じような破壊をもたらす可能性があります。
これらのマウントオプションとエクスポートオプションのデフォルトはベンダーとバージョンによって違います。ですから曖昧さを避けるためにこれらのオプションをチェックし、また常に明示的にオプションを指定したほうが良いでしょう。
場合によっては外部ストレージ製品は、NFSあるいはiSCSIのような低レベルのプロトコルのどちらでもアクセスできます。 後者の場合にはストレージはブロックデバイスとして扱われ、利用可能などのようなファイルシステムもその上に作ることができます。 このアプローチはNFSの特異性に対処することからDBAを解放するかも知れません。もちろんリモートストレージを管理する複雑さが別のレベルで起こってしまいますが。