Before you can do anything, you must initialize a database storage
area on disk. We call this a <firstterm>database cluster</firstterm>.
(The <acronym>SQL</acronym> standard uses the term catalog cluster.) A
database cluster is a collection of databases that is managed by a
single instance of a running database server. After initialization, a
database cluster will contain a database named <literal>postgres</literal>,
which is meant as a default database for use by utilities, users and third
party applications. The database server itself does not require the
<literal>postgres</literal> database to exist, but many external utility
programs assume it exists. There are two more databases created within
each cluster during initialization, named <literal>template1</literal>
and <literal>template0</literal>. As the names suggest, these will be
used as templates for subsequently-created databases; they should not be
used for actual work. (See <xref linkend="managing-databases"/> for
information about creating new databases within a cluster.)
まず最初に、ディスク上にデータベース格納領域を初期化する必要があります。
この格納領域をデータベースクラスタと呼びます。（標準SQLではカタログクラスタという用語が使用されています）。
データベースクラスタはデータベースの集合で、稼働しているデータベースサーバのただ一つのインスタンスを通して管理されます。
初期化が終わると、データベースクラスタにはpostgresという名前のデータベースが含まれています。
このデータベースは、ユーティリティ、ユーザ、サードパーティ製アプリケーションが使用するデフォルトデータベースになります。
データベースサーバ自身はこのpostgresデータベースの存在を必要としていませんが、多くの外部ユーティリティはその存在を想定しています。
初期化中に他にもtemplate1とtemplate0という2つのデータベースが各クラスタ内に作成されます。
その名前から推測できるように、これはその後に作成されるデータベースのテンプレートとして使われます。
したがって、実際の作業に使用しない方がよいです。
（クラスタ内における新しいデータベースの作成については第22章を参照してください。）
In file system terms, a database cluster is a single directory
under which all data will be stored. We call this the <firstterm>data
directory</firstterm> or <firstterm>data area</firstterm>. It is
completely up to you where you choose to store your data. There is no
default, although locations such as
<filename>/usr/local/pgsql/data</filename> or
<filename>/var/lib/pgsql/data</filename> are popular.
The data directory must be initialized before being used, using the program
<xref linkend="app-initdb"/><indexterm><primary>initdb</primary></indexterm>
which is installed with <productname>PostgreSQL</productname>.
ファイルシステムの観点から見ると、データベースクラスタというのは、すべてのデータが格納される1つのディレクトリということになります。
これはデータディレクトリもしくはデータ領域と呼ばれます。
どこにデータを格納するかは完全にユーザの自由です。
特にデフォルトの領域はありませんが、一般的によく使われるのは/usr/local/pgsql/dataや/var/lib/pgsql/dataです。
データディレクトリは、使用前にPostgreSQLと一緒にインストールされるコマンドinitdbを使用して初期化する必要があります。
If you are using a pre-packaged version
of <productname>PostgreSQL</productname>, it may well have a specific
convention for where to place the data directory, and it may also
provide a script for creating the data directory. In that case you
should use that script in preference to
running <command>initdb</command> directly.
Consult the package-level documentation for details.
パッケージ化された版のPostgreSQLを使用している場合は、データディレクトリを配置する場所について特別な規則がある場合があります。
また、データディレクトリを作成するためのスクリプトが提供されている場合もあります。
その場合は、initdbを直接実行するのではなくそのスクリプトを使用する必要があります。
詳細についてはパッケージレベルのドキュメントを参照してください。
To initialize a database cluster manually,
run <command>initdb</command> and specify the desired
file system location of the database cluster with the
<option>-D</option> option, for example:
データベースクラスタを手動で初期化するには、-Dオプションを使用してデータベースクラスタのファイルシステムの場所を指定しinitdbを実行します。
例えば次のようにします。
$initdb -D /usr/local/pgsql/data
Note that you must execute this command while logged into the <productname>PostgreSQL</productname> user account, which is described in the previous section. このコマンドは、前節で説明したPostgreSQLユーザアカウントでログインしている間に実行する必要があることに注意してください。
As an alternative to the <option>-D</option> option, you can set
the environment variable <envar>PGDATA</envar>.
-Dオプションを使う代わりにPGDATA環境変数を設定することもできます。
Alternatively, you can run <command>initdb</command> via
the <xref linkend="app-pg-ctl"/>
program<indexterm><primary>pg_ctl</primary></indexterm> like so:
他にも以下のようにpg_ctlプログラム経由でinitdbを実行することができます。
$pg_ctl -D /usr/local/pgsql/data initdb
This may be more intuitive if you are
using <command>pg_ctl</command> for starting and stopping the
server (see <xref linkend="server-start"/>), so
that <command>pg_ctl</command> would be the sole command you use
for managing the database server instance.
pg_ctlがデータベースサーバインスタンスの管理に使用する単一のコマンドになりますので、サーバの起動や停止にpg_ctlを使用している場合(18.3参照)はこちらの方がより直感的かもしれません。
<command>initdb</command> will attempt to create the directory you
specify if it does not already exist. Of course, this will fail if
<command>initdb</command> does not have permissions to write in the
parent directory. It's generally recommendable that the
<productname>PostgreSQL</productname> user own not just the data
directory but its parent directory as well, so that this should not
be a problem. If the desired parent directory doesn't exist either,
you will need to create it first, using root privileges if the
grandparent directory isn't writable. So the process might look
like this:
もし指定したディレクトリが存在しない場合は、initdbはその新しいディレクトリを作成しようとします。
もちろん、その親ディレクトリに書き込み権限がない場合initdbは失敗します。
PostgreSQLユーザがデータディレクトリだけでなく、親ディレクトリも所有することを一般的に推奨します。
このようにすると問題になることはありません。
目的の親ディレクトリが存在しない場合は、まずそのディレクトリを作成する必要があります。
親の親ディレクトリが書き込み可能でない場合は、root権限を使用して作成します。
そのため、手順は下記のようになります。
root#mkdir /usr/local/pgsqlroot#chown postgres /usr/local/pgsqlroot#su postgrespostgres$initdb -D /usr/local/pgsql/data
<command>initdb</command> will refuse to run if the data directory
exists and already contains files; this is to prevent accidentally
overwriting an existing installation.
データディレクトリが存在し、すでにファイルが含まれている場合は、initdbは実行を拒否します。これは、誤って既存のインストールを上書きしないようにするためです。
Because the data directory contains all the data stored in the
database, it is essential that it be secured from unauthorized
access. <command>initdb</command> therefore revokes access
permissions from everyone but the
<productname>PostgreSQL</productname> user, and optionally, group.
Group access, when enabled, is read-only. This allows an unprivileged
user in the same group as the cluster owner to take a backup of the
cluster data or perform other operations that only require read access.
データディレクトリにはデータベースの中のすべてのデータが保持されるため、権限を持たない人からのアクセスを確実に制限することが不可欠です。
ですから、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
<productname>PostgreSQL</productname>. Otherwise, a mix of modes might
exist in the data directory. For clusters that allow access only by the
owner, the appropriate modes are <literal>0700</literal> for directories
and <literal>0600</literal> for files. For clusters that also allow
reads by the group, the appropriate modes are <literal>0750</literal>
for directories and <literal>0640</literal> for files.
既存のクラスタに対してグループアクセスを有効にする、あるいは無効にするには、PostgreSQLを再起動する前に、クラスタが停止済みの状態で、すべてのディレクトリとファイルに適切なモードが設定されている必要があることに注意してください。
そうでないと、データディレクトリ内に異なるモードが混在してしまうかもしれません。
所有者のみにアクセスを許可するクラスタでは、適切なディレクトリのモードは0700で、ファイルモードは0600です。
加えてグループに対して読み出しを許可するクラスタでは、適切なディレクトリのモードは0750で、ファイルモードは0640です。
However, while the directory contents are secure, the default
client authentication setup allows any local user to connect to the
database and even become the database superuser. If you do not
trust other local users, we recommend you use one of
<command>initdb</command>'s <option>-W</option>, <option>--pwprompt</option>
or <option>--pwfile</option> options to assign a password to the
database superuser.<indexterm>
<primary>password</primary>
<secondary>of the superuser</secondary>
</indexterm>
Also, specify <option>-A scram-sha-256</option>
so that the default <literal>trust</literal> authentication
mode is not used; or modify the generated <filename>pg_hba.conf</filename>
file after running <command>initdb</command>, but
<emphasis>before</emphasis> you start the server for the first time. (Other
reasonable approaches include using <literal>peer</literal> authentication
or file system permissions to restrict connections. See <xref
linkend="client-authentication"/> for more information.)
しかし、ディレクトリの内容は安全ですが、デフォルトのクライアント認証の設定では、すべてのローカルユーザはデータベースに接続でき、データベーススーパーユーザになることさえ可能です。
他のローカルユーザを信用しない場合、initdbの-W、--pwprompt、--pwfileオプションのいずれか1つを使用して、データベーススーパーユーザにパスワードを付与することを推奨します。
また、デフォルトのtrust認証モードを使用しないように、-A scram-sha-256を指定してください。
もしくは、initdbの後、初回のサーバの起動の前に、生成済みのpg_hba.confファイルを変更してください。
（他の穏当な方法として、peer認証やファイルシステムの権限を使用して、接続を制限することもできます。
詳細については第20章を参照してください。）
<command>initdb</command> also initializes the default
locale<indexterm><primary>locale</primary></indexterm> for the database cluster.
Normally, it will just take the locale settings in the environment
and apply them to the initialized database. It is possible to
specify a different locale for the database; more information about
that can be found in <xref linkend="locale"/>. The default sort order used
within the particular database cluster is set by
<command>initdb</command>, and while you can create new databases using
different sort order, the order used in the template databases that initdb
creates cannot be changed without dropping and recreating them.
There is also a performance impact for using locales
other than <literal>C</literal> or <literal>POSIX</literal>. Therefore, it is
important to make this choice correctly the first time.
initdbはまた、データベースクラスタのデフォルトのロケールを初期化します。
通常は、環境のロケール設定を初期化されたデータベースにそのまま適用します。
データベースに異なるロケールを指定することも可能です。
詳細については23.1を参照してください。
特定のデータベースクラスタ内で使用されるデフォルトのソート順はinitdbで設定されます。
異なるソート順を使用する新しいデータベースを作成することもできますが、initdbが作成するテンプレートデータベースで使用される順は削除して再作成しない限り変更することができません。
また、CやPOSIX以外のロケールを使用する場合には性能上の影響もあります。
ですので初回にこれを正しく選択することが重要です。
<command>initdb</command> also sets the default character set encoding
for the database cluster. Normally this should be chosen to match the
locale setting. For details see <xref linkend="multibyte"/>.
またinitdbは、データベースクラスタのデフォルトの文字セット符号化方式も設定します。
通常これは、ロケールの設定と合うものが選ばれなければなりません。
詳細は23.3を参照してください。
Non-<literal>C</literal> and non-<literal>POSIX</literal> locales rely on the
operating system's collation library for character set ordering.
This controls the ordering of keys stored in indexes. For this reason,
a cluster cannot switch to an incompatible collation library version,
either through snapshot restore, binary streaming replication, a
different operating system, or an operating system upgrade.
非Cおよび非POSIXのロケールでは、文字セットのソート順はオペレーティングシステムの照合ライブラリに依存しています。
これは、インデックスに格納されているキーの順序を制御します。
このためにクラスタは、スナップショットのリストア、バイナリストリーミングレプリケーション、異なるオペレーティングシステム、またはオペレーティングシステムのアップグレードのいずれでも互換性のない照合ライブラリバージョンに切り替えることは出来ません。
Many installations create their database clusters on file systems (volumes) other than the machine's <quote>root</quote> 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 <productname>PostgreSQL</productname> user, and then create the data directory within that. This avoids permissions problems, particularly for operations such as <application>pg_upgrade</application>, and it also ensures clean failures if the secondary volume is taken offline. 多くのインストールでは、マシンの「ルート」ボリューム以外のファイルシステム（ボリューム）上にデータベースクラスタを作成します。 この選択をした場合、セカンダリボリュームの最上位ディレクトリ（マウントポイント）をデータディレクトリとして使用することはお勧めできません。 最善の方法はマウントポイントディレクトリ内にPostgreSQLユーザが所有するディレクトリを作成し、その中にデータディレクトリを作成することです。 これにより、権限の問題、特にpg_upgradeなどの操作での問題を避けることができ、またセカンダリボリュームがオフラインになったときに、確実にきれいなエラーを起こすようになります。
Generally, any file system with POSIX semantics can be used for PostgreSQL. Users prefer different file systems for a variety of reasons, including vendor support, performance, and familiarity. Experience suggests that, all other things being equal, one should not expect major performance or behavior changes merely from switching file systems or making minor file system configuration changes. 一般的にはPOSIXのセマンティクスを備えたすべてのファイルシステムがPostgreSQLで利用できます。 ユーザはベンダーのサポート、性能、慣れ親しんでいるかどうかなどの様々な理由で異なるファイルシステムを選択します。 経験が示すところによると、これ以外の要素が同じなら、単にファイルシステムを変更したり、ファイルシステムの設定を少し変えただけで大きな性能の違いや挙動の違いがあるとは思わないほうが良いでしょう。
It is possible to use an <acronym>NFS</acronym> file system for storing the <productname>PostgreSQL</productname> data directory. <productname>PostgreSQL</productname> does nothing special for <acronym>NFS</acronym> file systems, meaning it assumes <acronym>NFS</acronym> behaves exactly like locally-connected drives. <productname>PostgreSQL</productname> does not use any functionality that is known to have nonstandard behavior on <acronym>NFS</acronym>, such as file locking. PostgreSQLのデータディレクトリを格納するためにNFSファイルシステムが使えます。 PostgreSQLはNFSファイルシステムのために何ら特別なことはしません。つまりNFSがローカルに接続されたドライブと完全に同じように振る舞うものとみなします。 PostgreSQLは、ファイルのロックなど、NFS上で非標準の振る舞いをすると知られている機能は使いません。
The only firm requirement for using <acronym>NFS</acronym> with
<productname>PostgreSQL</productname> is that the file system is mounted
using the <literal>hard</literal> option. With the
<literal>hard</literal> option, processes can <quote>hang</quote>
indefinitely if there are network problems, so this configuration will
require a careful monitoring setup. The <literal>soft</literal> option
will interrupt system calls in case of network problems, but
<productname>PostgreSQL</productname> will not repeat system calls
interrupted in this way, so any such interruption will result in an I/O
error being reported.
NFSをPostgreSQLで使う上での必須要件はhardオプションを使ってファイルシステムをマウントすることです。
hardオプションでは、ネットワークに問題があればプロセスは永久に「ハング」する可能性があります。ですからこの設定では注意深い監視が必要になります。
softオプションはネットワークに問題があるとシステムコールに割り込みますが、PostgreSQLはこの方法で割り込まれたシステムコールを再発行しません。ですからそのような割り込みに対してはI/Oエラーの発生が報告されることとなります。
It is not necessary to use the <literal>sync</literal> mount option. The
behavior of the <literal>async</literal> option is sufficient, since
<productname>PostgreSQL</productname> issues <literal>fsync</literal>
calls at appropriate times to flush the write caches. (This is analogous
to how it works on a local file system.) However, it is strongly
recommended to use the <literal>sync</literal> export option on the NFS
<emphasis>server</emphasis> on systems where it exists (mainly Linux).
Otherwise, an <literal>fsync</literal> or equivalent on the NFS client is
not actually guaranteed to reach permanent storage on the server, which
could cause corruption similar to running with the parameter <xref
linkend="guc-fsync"/> off. The defaults of these mount and export
options differ between vendors and versions, so it is recommended to
check and perhaps specify them explicitly in any case to avoid any
ambiguity.
syncマウントオプションを使う必要はありません。
asyncオプションの動作で十分です。なぜならPostgreSQLは書き込みキャッシュをフラッシュするために適切な時にfsync呼び出しを発行するからです。
（これはローカルファイルシステム上での動作と同様です。）
しかし、syncエクスポートオプションがあるシステム（主にLinux）上のNFSサーバでは、そのオプションを使うことを強くお勧めします。
さもないとNFSクライアント上のfsync、あるいは同等ものは実際にはサーバ上の永続ストレージに到達することが保証されず、fsyncパラメータをオフにして実行するのと同じような破壊をもたらす可能性があります。
これらのマウントオプションとエクスポートオプションのデフォルトはベンダーとバージョンによって違います。ですから曖昧さを避けるためにこれらのオプションをチェックし、また常に明示的にオプションを指定したほうが良いでしょう。
In some cases, an external storage product can be accessed either via NFS or a lower-level protocol such as iSCSI. In the latter case, the storage appears as a block device and any available file system can be created on it. That approach might relieve the DBA from having to deal with some of the idiosyncrasies of NFS, but of course the complexity of managing remote storage then happens at other levels. 場合によっては外部ストレージ製品は、NFSあるいはiSCSIのような低レベルのプロトコルのどちらでもアクセスできます。 後者の場合にはストレージはブロックデバイスとして扱われ、利用可能などのようなファイルシステムもその上に作ることができます。 このアプローチはNFSの特異性に対処することからDBAを解放するかも知れません。もちろんリモートストレージを管理する複雑さが別のレベルで起こってしまいますが。