PostgreSQLの導入と初期設定

NTT オープンソースソフトウェアセンタ 板垣 貴裕

 

この記事は、gihyo.jp & Let's Postgres 連動企画「今こそ！PostgreSQL」の第4回記事です。「PostgreSQLの今を知る」シリーズに続き、今回から 4回に分けて PostgreSQL の使い方を解説していきます。第4回目は、PostgreSQL の導入、管理ツール類、運用を始める前に確認しておくべきポイントについて解説します。

導入

インストール、基本ツール、追加の GUI ツールについて解説します。

インストール

PostgreSQL はソースコードや実行バイナリの形式で配布されています。32bit版と 64bit版がありますが、OS に併せて選ぶのが適当だと思います。(Windows では 32bit版のみ)

インストールの手順は「目的別ガイド：インストール編」に一覧があります。CentOS, Ubuntu, Windows Vista, Max OS X へのインストールを解説しています。

基本ツールを確認する

PostgreSQL サーバと一緒にコマンドライン・ベースの操作ツールもインストールされていると思います。それぞれのツールの使い方を押さえておきましょう。

プログラム名 説明
initdb データベースクラスタを初期化します。PostgreSQL をインストールした後に、最初に実行するプログラムになります。ただし、インストーラによっては、インストール中にデータベースクラスタを既に作成済みの場合もあります。初期化の際にはロケールも設定してください。
pg_ctl データベースサーバの起動, 終了, 設定ファイルの再読込などを行います。こちらも、インストーラによっては既にサービスとしてサーバを登録 / 実行済みの場合もあります。
psql データベースへ接続し、任意のSQLを実行できるコマンドラインツールです。詳しくは記事「psqlを使ってみよう」「Cygwin版psqlを使ってみよう」をご覧下さい。
vacuumdb データベース全体に VACUUM を行います。v8.3 以降では autovacuum で VACUUM を行うことが推奨されていますが、負荷が低くなる時間帯の予想がつく場合には、その間に vacuumdb が実行されるよう cron 等に登録しておくのは、現在も有効な運用方法です。
reindexdb データベース全体に REINDEX を行います。v8.0 以降では、お世話になることは少ないでしょう。(使わなくて済むような運用を考えたほうが良い、とも言えます。)
clusterdb データベース全体に CLUSTER を行います。reindexdb と同様、お世話になることは少ないでしょう。
pg_dump 1つのデータベースの論理バックアップを行います。テーブル個別のリストアができるため、通常はカスタム形式 (-Fc) でバックアップすると良いでしょう。
pg_dumpall すべてのデータベースの論理バックアップを行います。テーブルスペースやロール (ユーザ) のバックアップには、こちらを使います。
pg_restore カスタム形式の論理バックアップをリストアします (SQL形式では psql を使います)。

GUI ツールを追加する

コマンドラインベースでの管理が馴染まない場合でも、さまざまな GUI 管理ツールが利用できます。広く利用されているオープンソースのツールを紹介します。

pgAdmin
PostgreSQL 専用の、クライアント・サーバ方式の GUI プログラムです。多くのプラットホームに対応しており、Windows のインストーラではサーバと同時にインストールされます。管理ツールの中では最も機能が充実した製品です。バックアップやオブジェクトの作成などの管理機能のほか、SQL の入力補完機能やグラフィカル・クエリ・ビルダも提供しています。
phpPgAdmin
 
PostgreSQL 専用の、ウェブブラウザ・ベースのプログラムです。スタックビルダを使っていれば、Apache や PHP と一緒に手軽にインストールすることができます。オブジェクトの閲覧、簡単なSQLの実行、ネットワーク経由でのデータ取得に向いています。
Webmin
ウェブブラウザ・ベースのプログラムです。サーバプログラム全般を管理でき、PostgreSQL に対してもバックアップ、オブジェクトの作成、SQL の実行など一通りの操作ができます。PostgreSQL の管理画面は、デフォルト設定では奥のほうに隠れています (右図参照) が、トップに表示できるように設定変更もできます。

他ツールや比較に関しては、以下のサイトも参考にして下さい。

初期設定

サービスの開始前に最低限 気をつけておくべき設定をチェックリスト風にまとめてみました。 全ての項目を確認しておきましょう。サービスを開始した後やデータ量が増加した後では、全くサービスに影響を及ぼさずに設定を修正することは難しくなってきます。早いうちから目を光らせておくことが重要です。

項目 説明
最新のアップデート版を利用していますか? 8.4.x の x が新しいものを利用しましょう。アップデートであれば、データは変更なしで利用できます。アップデートの頻度は特に決まっていませんが、4ヶ月に1回ほどになることが多いようです。
パラメータに関するチェックリスト
SHMALL, SHMMAX を増やしましたか? (Windows を除く) Unix, Linux, Mac OS X では、共有メモリを多く割り当てるためにはOSの共有メモリ設定を変更する必要があります。さもないと「FATAL: could not create shared memory segment」エラーで起動できません。
pg_hba.conf は確認しましたか? ログインの認証方法を設定するファイルです。別マシンから接続するためには設定が必要です。また、パスワード認証をさせたい場合には、trust 以外 (md5 など) に設定する必要があります。
listen_address は確認しましたか? 「ローカルからは接続できるのに、別マシンからはできない」というトラブルの多くは、このパラメータの設定忘れです。postgresql.conf の中にあります。
shared_buffers を環境に合わせて設定しましたか? 変更にはサーバの再起動が必要になります。PostgreSQL が利用できる全メモリの 10-20% 程度を割り当てると良いでしょう。postgresql.conf の中にあります。
max_fsm_pages をデータベース容量に合わせて設定しましたか? (v8.3以前) 不足すると VACUUM で不要領域を再利用しきれません。いったん肥大化すると、VACUUM FULL や CLUSTER 等のアクセス停止を伴う再編成が必要になってしまいます。max_fsm_pages を十分に割り当て、VACUUM だけで運用できるのが理想です。postgresql.conf の中にあります。
バックアップに関するチェックリスト
アーカイブログは取得していますか? (v8.0以降) 更新結果を失いたくない場合には、オンライン・バックアップと Point-In-Time Recovery を利用するために、WALファイルを保存する必要があります。パラメータ archive_mode, archive_command を設定しましょう。この際、アーカイブ先のディスク容量も監視してください。
pg_dump を定期的に実行していますか? ディスク故障時にバックアップ時点まで巻き戻ってよいのであれば、pg_dump や pg_dumpall でのバックアップが手軽です。1日1回など、定期的にバックアップを取りましょう。
メンテナンスに関するチェックリスト
autovacuum を有効にしましたか? (v7.4以降) 不要領域の回収には VACUUM を、統計情報の更新には ANALYZE を定期的に実行する必要があります。参照のみのテーブルであっても約20億トランザクションおきに VACUUM が必要になることに注意しましょう。v8.0 以前では contrib モジュールで提供されています。
1日1回 vacuumdb をしていますか? autovacuum を有効にしない場合、もしくは有効にしていても夜間等にシステムの負荷が下がることが予想できる場合には、vacuumdb 等で明示的に VACUUM を実行すると安心です。夜中に VACUUM しておけば、次の日の昼間に autovacuum が動作する可能性も減らせます。 ただし、VACUUM FULL を行うオプション -f, --full は使ってはいけません。
VACUUM のコスト遅延を設定しましたか? (v8.0以降) PostgreSQL は VACUUM 中であっても参照や更新ができますが、多くの I/O が発生するのでサーバの負荷が高まります。コスト遅延を設定して、VACUUM に割り当てる I/O リソースを制限しておきましょう。
VACUUM FULL は止めましたか? 毎日のように頻繁に VACUUM FULL, CLUSTER, REINDEX をするのは間違った運用です。autovacuum に任せるなど、十分な頻度で VACUUM を行えば、これらの再編成処理は必要なくなるはずです。
監視に関するチェックリスト
サーバログは保存していますか? ログをテキストまたは syslog に保存するようにしましょう。記事「ログ関連の設定」が参考になります。
ディスク領域を監視していますか? $PGDATA, 各テーブルスペース, pg_xlog, アーカイブ先のディスクの容量を、定期的に監視するようにしましょう。特に pg_xlog 領域がディスクフルになると PANIC エラーでサーバが全体が停止する恐れがあります。

今回は、PostgreSQL の導入と運用を始める前に確認しておくべきポイントについて簡単に解説しました。次回以降の連載で、さらに詳しい運用方法について説明していきます。

(2009年10月14日 公開)