サーバーのセットアップと操作
この章では、データベースサーバーをセットアップして実行する方法と、オペレーティングシステムとの対話について説明します。
18.1 PostgreSQLユーザーアカウント
外部からアクセスできるサーバーデーモンと同様に、PostgreSQLを別のユーザーアカウントで実行することもお勧めします。このユーザーアカウントは、サーバーが管理するデータのみを所有する必要があり、他のデーモンと共有しないでください（たとえば、ユーザーnobodyを使用することはお勧めできません）。侵害されたシステムが独自のバイナリファイルを変更する可能性があるため、このユーザーに属するものとして実行可能ファイルをインストールすることはお勧めしません。
システムにUnixユーザーアカウントを追加するには、useraddまたはadduserコマンドを確認します。通常はpostgresが使用されます（このアカウントはこの本でも想定されています）が、別の名前を使用することもできます。
18.2。データベースクラスターを作成する
何かを行う前に、ディスク上のデータベースストレージ領域を初期化する必要があります。これをデータベースクラスタと呼びます（SQL標準で使用される用語はディレクトリクラスタです）。データベースクラスターは、実行中のデータベースサーバーの単一のインスタンスによって管理される複数のデータベースのコレクションです。初期化後、データベースクラスターにはpostgresという名前のデータベースが含まれます。これは、関数、ユーザー、およびサードパーティアプリケーションによって使用されるデフォルトのデータベースを表します。データベースサーバー自体は、postgresデータベースの存在を必要としません。初期化プロセス中にクラスターごとに作成される別のデータベースは、template1と呼ばれます。名前が示すように、後続のデータベースのテンプレートを作成するために使用されます。実際の作業には使用しないでください（クラスターでの新しいデータベースの作成の詳細については、第22章を参照してください）。
ファイルシステムの用語では、データベースクラスタは、すべてのデータが格納される単一のディレクトリです。これをデータディレクトリまたはデータ領域と呼びます。データを保存する場所を選択します。デフォルトの場所はありませんが、/usr/local/pgsql/data或/var/lib/pgsql/data場所の方が人気があります。データベースクラスタを初期化するには、PostgreSQLと共にインストールされたコマンドinitdbを使用します。データベースクラスタのファイルシステムの場所は、-Dオプションで指定します。
次に例を示します。
$ initdb -D /usr/local/pgsql/data
（前のセクションで示したように）PostgreSQLユーザーアカウントでログインした後、このコマンドを実行する必要があることに注意してください。
-Dオプションの代わりに、環境変数PGDATAを設定できます。
もう1つの方法は、pg_ctlプログラムを使用してinitdbを実行できることです。
$ pg_ctl -D /usr/local/pgsql/data initdb
pg_ctlを使用してサーバーを起動および停止する場合（セクション18.3を参照）、データベースサーバーインスタンスを管理するために使用するコマンドはpg_ctlだけであると考えて、この方法はより直感的です。
指定したディレクトリがまだ存在しない場合、initdbはそれを作成しようとします。もちろん、initdbが親ディレクトリに書き込み権限を持っていない場合、これは失敗します。上記の問題が発生しないように、PostgreSQLユーザーにデータディレクトリとその親ディレクトリを所有させることをお勧めします。目的の親ディレクトリが存在しない場合は、最初に作成する必要があります。親親ディレクトリが書き込み可能でない場合は、ルート権限を使用してください。したがって、プロセスは次のようになります。
root# mkdir /usr/local/pgsql
root# chown postgres /usr/local/pgsql
root# su postgres
postgres$ initdb -D /usr/local/pgsql/data
データディレクトリが存在し、すでにファイルが含まれている場合、initdbは実行を拒否します。これにより、既存のインストールを誤って上書きすることを回避できます。
データディレクトリにはデータベースに保存されているすべてのデータが含まれるため、最も重要なことは、このディレクトリを不正アクセスから保護することです。したがって、initdbは、PostgreSQLのユーザーとグループを除くすべてのユーザーのアクセス権を再利用し、選択することもできます。グループアクセスを有効にすると、読み取り専用になります。これにより、同じグループ内の無許可のユーザーがクラスター所有者として機能したり、クラスターデータをバックアップしたり、読み取りアクセス許可のみを必要とするその他の操作を実行したりできます。
既存のクラスターでグループアクセスを有効または無効にする場合は、PostgreSQLを再起動する前に、クラスターをシャットダウンし、すべてのディレクトリとファイルを適切なモードに設定する必要があります。それ以外の場合は、データディレクトリに複数のパターンがあります。クラスタには所有者のみがアクセスできます。適切なモードは、ディレクトリの場合は0700、通常のファイルの場合は0600です。クラスターがグループによって読み取り可能になるようにするには、適切なモードは、そのディレクトリに対して0750、通常のファイルに対して0640である必要があります。
ただし、ディレクトリの内容は安全ですが、デフォルトのクライアント認証設定では、すべてのローカルユーザーがデータベースに接続したり、データベースのスーパーユーザーになることさえできます。他のローカルユーザーを信頼しない場合は、initdbの-W、-pwprompt、または-pwfileオプションのいずれかを使用して、データベースのスーパーユーザーにパスワードを割り当てることをお勧めします。-A md5または-Apasswordを指定して、デフォルトの信頼認証が使用されないようにすることもできます。または、initdbを実行した後、サーバーを初めて起動する前に、生成されたpg_hba.confファイルを変更します（他の可能な方法には、ピア認証またはファイルシステム権限による接続の制限が含まれます。
init dbは、データベースクラスタのデフォルト領域も初期化します。通常、環境のロケール設定を使用し、初期化されたデータベースに適用します。データベースに別の領域を指定できます;これに関する詳細は項23.1にあります。特定のデータベースクラスタで使用されるデフォルトの並べ替え順序は、initdbによって設定されます。別の並べ替え順序で新しいデータベースを作成できますが、initdbによって作成されたテンプレートデータベースで使用される順序は変更できません（データベースを削除して再構築しない限り）。非CまたはPOSIX領域を使用すると、パフォーマンスにも影響します。したがって、最初に正しいものを選択することが重要です。init dbは、データベースクラスタのデフォルトの文字セットエンコーディングも設定します。通常、ロケールに一致する文字セットエンコーディングを選択する必要があります。
非Cおよび非POSIX領域は、オペレーティングシステムの照合ライブラリに依存して文字セットをソートします。これは、インデックスに格納されているキーのソートを制御します。このため、スナップショットリカバリ、バイナリストリームレプリケーション、別のオペレーティングシステムの変更、またはオペレーティングシステムのアップグレードを通じて、クラスタを照合ライブラリの互換性のないバージョンに切り替えることはできません。
18.2.1。セカンダリファイルシステムの使用
多くのインストールでは、マシンの「ルート」ボリュームではなく、ファイルシステム（ボリューム）にデータベースクラスタが作成されます。これを行う場合は、セカンダリボリュームの最上位ディレクトリ（マウントポイント）をデータディレクトリとして使用することはお勧めしません。ベストプラクティスは、PostgreSQLユーザーが所有するマウントポイントディレクトリにディレクトリを作成し、そこにデータディレクトリを作成することです。これにより、特にpg_upgradeなどの操作に関する権限の問題を回避できます。また、セカンダリボリュームが切断された後のクリーンエラーも保証できます。
18.2.2。ネットワークファイルシステムの使用
多くのインストールでは、ネットワークファイルシステム上にデータベースクラスタが作成されます。場合によっては、NFSを介して直接行われるか、内部でNFSを使用するネットワーク接続ストレージデバイス（NAS）を介して行われます。PostgreSQLはNFSファイルシステムを特別に扱いません。つまり、NFSがローカルに接続されたデバイスとまったく同じように動作することを前提としています。クライアントまたはサーバーのNFSが標準のファイルシステムセマンティクスを提供しない場合、信頼性の問題が発生します（https://www.time-travellers.org/shane/papers/NFS_considered_harmful.htmlを参照）。
具体的には、NFSサーバーへの書き込みが遅延（非同期）すると、データ破損の問題が発生する可能性があります。可能であれば、NFSファイルシステムを同期（キャッシュなし）としてマウントすると、この障害を回避できます。また、ソフトマウントされたNFSファイルシステムはお勧めしません。
ストレージエリアネットワーク（SAN）は通常、NFS以外の通信プロトコルを使用しており、このような災害に遭遇する場合とそうでない場合があります。データの一貫性の保証について理解するには、サプライヤーのドキュメントを参照することをお勧めします。PostgreSQLは、使用するファイルシステムよりも信頼できません。