Simple Configuration Recommendation/ja

原文最終更新日：13 September 2013

PostgreSQLの推奨設定

データベース環境の管理は、データベースの知識とは別の知識を要求します。データベース管理（DBA）はシステムとストレージ管理に密に関連します。PostgreSQLは、ホストOSのストレージ管理に強く依存します。Oracleのストレージ管理機能のような優位性や複雑性を持ち合わせていません。

これらの推奨事項はPostgreSQLデータベース設定を標準化、簡易化するものです。

ソフトウェアの配置場所と所有権

LinuxにおけるPostgreSQLの標準的なインストールディレクトリは、実行ファイル、ソース、様々なサブディレクトリにあるデータファイルを含んだ/usr/local/pgsqlとなります。しかしながら、PostgreSQLはオープンソースソフトウェアであり、ディストリビュータ、パッケージ作成者または協力者といった誰もがソフトウェアをどのディレクトリに配置し、誰のアカウントの所有とするかを要求します。

いくつかのパッケージ管理ソフトウェアは実行ファイル、ライブラリ、manページとcontribファイルを様々な場所に設置します。これらのソリューションは拒否してください。ソフトウェアインストレーションにおいて標準的なシンプルな設定を行うことは管理をよりし易くします。

ソフトウェア、データベースファイルそしてサーバプロセスの所有者とグループは、postgres:dbaであるべきです。UIDとGIDはシステム管理する専用のものとするべきです。

基本となるソフトウェアのインストールディレクトリを作成します：

  /opt/postgres

ソフトウェアバージョンの最初の2文字を使ってインストールディレクトリを定義します（例では9.0）：

  /opt/postgres/9.0

バージョン番号の3文字目のアップグレードに通常はサーバの停止、新しいソフトウェアへの変更、サーバのリスタートを伴うことを知っておいてください。しかしながら、最初もしくは2文字目のバージョンへのアップグレードはデータファイルのすべてのアップグレードを要求します。ソフトウェアのバージョンを分割して維持することはアップグレードする手助けとなります。

単一クラスタとサーバごとのデータベース

以下のデータベースオブジェクトはPostgreSQLの中でクラスタの範囲で存在し、クラスタごとの単一のデータベースを持つことが望ましいです：

• 設定ファイル
• WAL（オンラインとアーカイブされた）ファイル
• テーブルスペース
• ユーザアカウントとロール
• サーバログファイル

データベースオブジェクト分離のより古いやり方は複数のデータベースの利用を通じて行うものでした。代替案でより管理しやすいデータベースオブジェクトを分離する手法はスキーマの利用を通じて行うものです。

単一のサーバ内でデータ領域とIPポート番号を違うものにしたPostgreSQLクラスタを分離するためには、それらを個別に作成する必要があります。しかしながら、Solarisのzones、FreeBSDのjailsまたはXenやKVMのようなハイパーバイザーを持つOSの仮想的な機能では、単一のホストに複数のクラスタの作成は不要です。

ファイルシステムレイアウト

最も融通が利き、管理しやすい環境を作成するために、個々のデータベース構成物をそれら独自のファイルシステムに分離することです。以下のファイルシステム（マウントポイント）を作成すると良いでしょう：

/pgarchive	アーカイブログファイルを格納する場所。
/pgbackup	物理と論理バックアップの格納場所。論理バックアップ（pg_dump）では、EXPORTSというサブディレクトリを作成します。物理バックアップでは、FULL{日付}を作成し、習慣的にサブディレクトリを作成します。しかしながら、物理バックアップはファイルシステムのスナップショットの利用にて制御されます。詳しくは後述。
/pgcluster	PosgreSQLクラスタデータディレクトリ（PGDATA環境変数の値）。ここにはすべての設定ファイルとPosgreSQLクラスタのすべてのディレクトリが格納されます。注記：オンラインWALファイルは/pgcluster/pg_xlogに設定されているでしょう。
/pglog	サーバログファイルの格納場所。
/pgdata-system	データベースのデフォルトテーブルスペースの場所。これはデータベースの作成時に利用されるものです。データベースのカタログ情報が格納されます。
/pgdata-temp	データベースのデフォルトテンポラリテーブルスペースの場所。これはテンポラリソート情報のために必要とされます。注記：デフォルトテーブルスペースのpgsql_tmpディレクトリはテンポラリテーブルスペースが定義されてない場合に利用されます。
/pgdata-app_tblspc	アプリケーションのテーブルスペース。すべてのスキーマにて、最低2テーブルスペースが存在します。一つはテーブル用、もう一つはインデックス用です。

PostgreSQLは、テーブルスペースとデータベースオブジェクトのサイズ制限の宣言設定を有していません；OSは使用機器のサイズを管理すると予想されます。これはすべてのテーブルスペースにおいて分離したマウントポイント（ファイルシステム）を作成することが要求されるという理由からです。これは特にデータベース管理からストレージとOS管理を分割するという構成における複雑なレイヤーの追加です。しかしながら、複雑性のレベルはデータベースオブジェクトの分離と分割の優位性を凌ぐものとなります。

ファイルシステムの伸張と管理が、提供された管理形態の方式に沿っていること望ましいです。DBAは領域管理内のディスクグループの一式に与えられ、ファイルシステムに応じて分割されます。ZFSは、管理委任のファイルシステムの例となります。

サーバ設定情報

PITRのための"継続的なアーカイブ"の使用設定。

  archive_mode = on
  archive_command = 'cp %p /pgarchive/%f'
  wal_level = 'archive'

サーバログファイルのローテーション設定。（7日または10MBのいずれか早い方）

  log_directory = '/pgcluster/log'
  log_filename = 'postgresql-%Y%m%d_%H%M%S.log'
  log_rotation_age = 7d
  log_rotation_size = 10MB
  log_truncate_on_rotation = off
  log_line_prefix = '%t c%  '

サーバログファイルに接続情報を集約。

  log_connections = on
  log_disconnections = on

DDLトランザクションのログ書き込み。

  log_statement = 'ddl'

SSLの有効化。

  ssl = on
  ssl_ciphers = 'ALL'

デフォルトのpostgresデータベースの削除またはリモート接続を拒否します。

アプリケーションスキーマの設置のためにデータベースの作成をしてください。パブリックなスキーマの削除をしてください。

アカウント管理

postgresアカウントでデータベースのスーパーユーザとしてデータベースサーバへの接続を避けてください。バックアップのような管理プロセスでは、多くの場合postgresアカウントを未だ利用するでしょう;しかしながら接続ユーザとアプリケーションへの接続の際は使用すべきではありません。ローカル接続にのみpostgresデータベースユーザを許可してください。注記：バージョン9.1ではpg_hba.conf内のlocalセクションのauth-optinにて認証方式を使用することが最も望ましいものとなります。

データベースに直接接続するすべてのユーザのために独特なアカウントを作成してください。DBAユーザはスーパーユーザ権限が必要となり、デプロイの代表者はスキーマオブジェクト定義の操作のための権限が必要となり、開発者は生産物の問題を診断するためにアプリケーションオブジェクトにselect権限が必要となるでしょう。

ユーザアカウント認証のために（例えばLDAPのような）集中型エンタープライズアカウントを利用することが可能となります。

アプリケーションスキーマを使って同期されるアカウントを作成してください。これらのスキーマアカウントへの接続を回避してください。実際にはアカウントをNOLOGINとすることができます。

ユーザがアプリケーションスキーマにオブジェクト定義をデプロイするとき、適切な権限を持つ必要があります。これらのユーザにアプリケーションスキーマのロールを与えることは、この活動を許可するには十分なものです。新しく作成された、いかなるオブジェクトの所有権はスキーマに合致するアカウントに設定されることに注意してください。

アカウントの管理を容易にするために、ユーザに直接権限を付与することに対して権限を付与するためのロールを使用します。

一般的にアプリケーションはプールされた（共有された）アカウントを利用してデータベースに接続します。これらのアカウントは定義済みアプリケーションサーバからのみデータベースに接続できることに注意してください。ユーザはこれらのプールされたアカウントを利用して直接データベースにログインすることを許可しないようにするべきです。

物理的なデータベースバックアップ

オンラインバックアップを実行するために、データベースがアーカイブログモードで動作することは重要です。PostgreSQLリファレンスマニュアルの継続的アーカイブとポイントインタイムリカバリ（PITR）の章を参照してください。

スナップショット／ロールバック機能をもつZFSのような高度なファイルシステムを利用することはいくつかの重要な利点があります。HOTバックアップモードでデータベースを設置し、データベースストレージを作成したファイルシステムのスナップショットを作成すること、そしてバックアップモードの外側からデータベースのバックアップを取ることは、tarまたはcpioを使用してバックアッププロセスの間にすべてのデータファイルを互いの場所にコピーすることより望ましいです。

スナップショット取得後に安全性確保のためにデータファイルを互いの場所にコピーすることがオプションとして利用可能です；しかしながら、スナップショット取得の時間を少なくするために、データベースがHOTバックアップモードである必要があります。オンラインバックアップ（スナップショット）を利用する最も多いリカバリの状況は"テープからの復旧"に代わりに利用されます。

ファイルシステムをシステム管理者に任せることはファイルシステムのスナップショットの管理において優位性があります。DBAはシステム管理とストレージ管理にベストプラクティスを適用させなければならないでしょう。