他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

18.2. データベースクラスタの作成

まず最初に、ディスク上にデータベース格納領域を初期化する必要があります。 この格納領域をデータベースクラスタと呼びます。(標準SQLではカタログクラスタという用語が使用されています)。 データベースクラスタはデータベースの集合で、稼働しているデータベースサーバのただ一つのインスタンスを通して管理されます。 初期化が終わると、データベースクラスタにはpostgresという名前のデータベースが含まれています。 このデータベースは、ユーティリティ、ユーザ、サードパーティ製アプリケーションが使用するデフォルトデータベースになります。 データベースサーバ自身はこのpostgresデータベースの存在を必要としていませんが、多くの外部ユーティリティはその存在を想定しています。 初期化中に他にもtemplate1というデータベースが各クラスタ内に作成されます。 その名前から推測できるように、これはその後に作成されるデータベースのテンプレートとして使われます。 したがって、実際の作業に使用しない方がよいです。 (クラスタ内における新しいデータベースの作成については第22章を参照してください。)

ファイルシステムの観点から見ると、データベースクラスタというのは、すべてのデータが格納される1つのディレクトリということになります。 これはデータディレクトリもしくはデータ領域と呼ばれます。 どこにデータを格納するかは完全にユーザの自由です。 特にデフォルトの領域はありませんが、一般的によく使われるのは/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がデータベースサーバインスタンスの管理に使用する単一のコマンドになりますので、サーバの起動や停止にpg_ctlを使用している場合(18.3参照)はこちらの方がより直感的かもしれません。

もし指定したディレクトリが存在しない場合は、initdbはその新しいディレクトリを作成しようとします。 もちろん、その親ディレクトリに書き込み権限がない場合initdbは失敗します。 PostgreSQLユーザがデータディレクトリだけでなく、親ディレクトリも所有することを一般的に推奨します。 このようにすると問題になることはありません。 目的の親ディレクトリが存在しない場合は、まずそのディレクトリを作成する必要があります。 親の親ディレクトリが書き込み可能でない場合は、root権限を使用して作成します。 そのため、手順は下記のようになります。

root# mkdir /usr/local/pgsql
root# chown postgres /usr/local/pgsql
root# su postgres
postgres$ initdb -D /usr/local/pgsql/data

データディレクトリが存在し、すでにファイルが含まれている場合は、initdbは実行を拒否します。これは、誤って既存のインストールを上書きしないようにするためです。

データディレクトリにはデータベースの中のすべてのデータが保持されるため、権限を持たない人からのアクセスを確実に制限することが不可欠です。 ですから、initdbPostgreSQLユーザ、更にオプションでグループ以外からのアクセス権を剥奪します。 許可されている場合には、グループアクセスは読み出し専用になります。 これにより、クラスタの所有者と同じグループに所属する非特権ユーザが、そのクラスタのデータをバックアップすることや、読み出し権限だけが必要なその他の操作を実行することが可能になります。

既存のクラスタに対してグループアクセスを有効にする、あるいは無効にするには、PostgreSQLを再起動する前に、クラスタが停止済みの状態で、すべてのディレクトリとファイルに適切なモードが設定されている必要があることに注意してください。 そうでないと、データディレクトリ内に異なるモードが混在してしまうかもしれません。 所有者のみにアクセスを許可するクラスタでは、適切なディレクトリのモードは0700で、ファイルモードは0600です。 加えてグループに対して読み出しを許可するクラスタでは、適切なディレクトリのモードは0750で、ファイルモードは0640です。

しかし、ディレクトリの内容は安全ですが、デフォルトのクライアント認証の設定では、すべてのローカルユーザはデータベースに接続でき、データベーススーパーユーザになることさえ可能です。 他のローカルユーザを信用しない場合、initdb-W--pwprompt--pwfileオプションのいずれか1つを使用して、データベーススーパーユーザにパスワードを付与することを推奨します。 また、デフォルトのtrust認証モードを使用しないように、-A md5もしくは-A passwordを指定してください。 もしくは、initdbの後、初回のサーバの起動のに、生成済みのpg_hba.confファイルを変更してください。 (他の穏当な方法として、peer認証やファイルシステムの権限を使用して、接続を制限することもできます。 詳細については第20章を参照してください。)

initdbはまた、データベースクラスタのデフォルトのロケールを初期化します。 通常は、環境のロケール設定を初期化されたデータベースにそのまま適用します。 データベースに異なるロケールを指定することも可能です。 詳細については23.1を参照してください。 特定のデータベースクラスタ内で使用されるデフォルトのソート順はinitdbで設定されます。 異なるソート順を使用する新しいデータベースを作成することもできますが、initdbが作成するテンプレートデータベースで使用される順は削除して再作成しない限り変更することができません。 また、CPOSIX以外のロケールを使用する場合には性能上の影響もあります。 ですので初回にこれを正しく選択することが重要です。

またinitdbは、データベースクラスタのデフォルトの文字セット符号化方式も設定します。 通常これは、ロケールの設定と合うものが選ばれなければなりません。 詳細は23.3を参照してください。

Cおよび非POSIXのロケールでは、文字セットのソート順はオペレーティングシステムの照合ライブラリに依存しています。 これは、インデックスに格納されているキーの順序を制御します。 このためにクラスタは、スナップショットのリストア、バイナリストリーミングレプリケーション、異なるオペレーティングシステム、またはオペレーティングシステムのアップグレードのいずれでも互換性のない照合ライブラリバージョンに切り替えることは出来ません。

18.2.1. セカンダリファイルシステムの使用

多くのインストールでは、マシンのルートボリューム以外のファイルシステム(ボリューム)上にデータベースクラスタを作成します。 この選択をした場合、セカンダリボリュームの最上位ディレクトリ(マウントポイント)をデータディレクトリとして使用することはお勧めできません。 最善の方法はマウントポイントディレクトリ内にPostgreSQLユーザが所有するディレクトリを作成し、その中にデータディレクトリを作成することです。 これにより、権限の問題、特にpg_upgradeなどの操作での問題を避けることができ、またセカンダリボリュームがオフラインになったときに、確実にきれいなエラーを起こすようになります。

18.2.2. ネットワークファイルシステムの使用

多くのインストレーションはネットワークファイルシステム上にデータベースクラスタを作成します。 直接NFSを介して行うこともありますし、NFSを内部的に使うネットワークアタッチドストレージ(NAS)デバイスを使用することもあります。 PostgreSQLNFSファイルシステムに特別なことを何も行いません。 つまりNFSはローカル接続のドライブとまったく同様に振る舞うという前提です。 クライアントとサーバのNFS実装が標準ファイルシステム・セマンティクスを持たないならば、信頼性の問題を引き起こす可能性があります。 (https://www.time-travellers.org/shane/papers/NFS_considered_harmful.html参照)。 具体的には、NFSサーバへの遅延(非同期)書きこみがデータ破損の問題を引き起こす可能性があります。 可能ならばNFSファイルシステムを(キャッシュ無しで)同期マウントし、この危険を防止してください。更に、NFSをソフトマウントすることは薦められません。

ストレージエリアネットワーク(SAN)は通常NFSとは異なる通信プロトコルを使用し、この種の危険がある場合と無い場合があります。 これは、データの整合性の保証に関するベンダのドキュメントを参照することをお勧めします。 PostgreSQLは、使用しているファイルシステム以上に信頼性が高くなることはありません。