他のバージョンの文書 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

19.3. データベースサーバの起動 #

データベースにアクセスするためには、まずデータベースサーバを起動しなくてはいけません。 データベースサーバプログラムはpostgresという名前です。

パッケージ化された版のPostgreSQLを使用している場合は、オペレーティングシステムの規則に従って、サーバをバックグラウンドタスクとして実行するための提供がほぼ確実に含まれています。 パッケージの基盤を使用してサーバを起動させるほうが、自分でこれをおこなう方法を理解するよりもはるかに作業量が少なくなります。 詳細についてはパッケージレベルのドキュメントを参照してください。

サーバを手動で起動するための必要最低限の方法は、-Dオプションを使用してデータディレクトリの場所を指定postgresを直接呼び出することです。 次に例を示します。

$ postgres -D /usr/local/pgsql/data

上記のコマンドはサーバをフォアグラウンドで実行させます。 これは、PostgreSQLユーザアカウントでログインしている間に実行されなくてはいけません。 -Dオプションが指定されていない場合、サーバはPGDATA環境変数で指定されたデータディレクトリを使用しようと試みます。 どちらの変数も指定されていなければ失敗します。

通常はバックグラウンドでpostgresを起動することをお勧めします。 そのためには以下のように通常のUnixシェルの構文を使います。

$ postgres -D /usr/local/pgsql/data >logfile 2>&1 &

この例のように、サーバの標準出力標準エラー出力をどこかに保管しておくことが重要です。 これは監査目的と問題の原因究明に役立ちます。 (ログファイルの取り扱いについての全体的な説明については25.3を参照してください。)

postgresプログラムには、この他にも多くのコマンドラインオプションを指定することができます。 詳細はpostgresマニュアルページと後述の第20章を参照してください。

こうしたシェル構文は長くなりがちです。そのため、 pg_ctl ラッパープログラムが提供されていて、いくつかのタスクを単純化しています。 以下に例を示します。

pg_ctl start -l logfile

これは、サーバをバックグラウンドで起動し、出力を指定されたログファイルに書き出します。 -Dオプションは、ここでもpostgresの場合と同じ意味を持ちます。 pg_ctlによってサーバを停止させることもできます。

通常、コンピュータが起動された時にデータベースサーバも一緒に起動したい場合が多いと思われます。 自動起動スクリプトはオペレーティングシステム固有のものです。 いくつかのスクリプトの例はPostgreSQLcontrib/start-scriptsディレクトリに同梱されています。 このインストールにはおそらくroot権限が必要となります。

起動時にデーモンを開始する方法はシステムによって異なります。 多くのシステムには/etc/rc.localファイルや/etc/rc.d/rc.localファイルがあります。 他のシステムではinit.drc.dディレクトリが使用されます。 何を実行するにしても、サーバはPostgreSQLユーザアカウントで起動させなければなりません。 rootであってはいけませんし、他のユーザでもいけません。 したがって、su postgres -c '...'を使用してコマンドを実行する必要があるでしょう。 以下に例を示します。

su postgres -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog'

さらにいくつかのオペレーティングシステム固有の提案を挙げます。 (ここでは一般的な値で説明していますので、各項目において適切なインストールディレクトリとユーザ名に置き換えて読んでください。)

サーバが実行している間は、そのPIDはデータディレクトリの中のpostmaster.pidファイルに記述されています。 これは同じデータディレクトリで複数のサーバインスタンスが実行されるのを防止し、また、サーバの停止にも使うことができます。

19.3.1. サーバ起動の失敗 #

サーバの起動が失敗する理由として代表的なものがいくつかあります。 サーバのログファイルを点検するか、(標準出力や標準エラーをリダイレクトせずに)手動で起動して、どのようなエラーメッセージが出ているか確認してください。 以下に、よく発生するエラーメッセージのいくつかをより詳細に説明します。

LOG:  could not bind IPv4 address "127.0.0.1": Address already in use
HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
FATAL:  could not create any TCP/IP sockets

これはたいていの場合メッセージが示す通りの意味です。 既にサーバが動いているポートで別のサーバを起動しようとしたことを示しています。 しかし、カーネルエラーメッセージがAddress already in useやそれに類似したものではない場合は、別の問題の可能性もあります。 例えば、予約済みのポート番号でサーバを起動しようとすると下記のようなメッセージが出るかもしれません。

$ postgres -p 666
LOG:  could not bind IPv4 address "127.0.0.1": Permission denied
HINT:  Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL:  could not create any TCP/IP sockets

次のようなメッセージが表示された場合、

FATAL:  could not create shared memory segment: Invalid argument
DETAIL:  Failed system call was shmget(key=5440001, size=4011376640, 03600).

これは、おそらくカーネルによる共有メモリのサイズの上限がPostgreSQLが作ろうとしている作業領域(この例では4011376640バイト)よりも小さいことを示しています。 これはshared_memory_typesysvに設定した場合にのみ発生する可能性があります。 その場合は、サーバを通常よりも少ないバッファ数(shared_buffers)で起動するか、カーネルを再設定して許容される共有メモリサイズを増やすこともできます。 このメッセージは、同じマシン上で複数のサーバを起動しようとした時に、要求された領域の合計がカーネルの上限を超えた場合にも表示されます。

下記のようなエラーの場合:

FATAL:  could not create semaphores: No space left on device
DETAIL:  Failed system call was semget(5440126, 17, 03600).

ディスクの空き容量がなくなったということを示しているわけではありません。 これはカーネルのSystem Vセマフォの上限が、PostgreSQLが作成しようとしている数よりも小さいということを意味しています。 上記のように、許可される接続の数(max_connections)を減らしてサーバを起動させることで問題は回避できるかもしれませんが、最終的にはカーネルの設定を変えてセマフォの上限を増やした方が良いでしょう。

System V IPC設備の設定についての詳細は19.4.1を参照してください。

19.3.2. クライアント接続の問題 #

クライアント側で起こり得るエラー状態はきわめて多様で、アプリケーションに依存します。 その中のいくつかはサーバが起動された方法と直接関係するかもしれません。 以下で説明する以外の状態については各々のクライアントアプリケーションの資料を参照してください。

psql: error: connection to server at "server.joe.com" (123.123.123.123), port 5432 failed: Connection refused
        Is the server running on that host and accepting TCP/IP connections?

これは一般的な接続するサーバが見つけられませんでしたという失敗です。 TCP/IP通信を試みた時に上記のように表示されます。 よくある間違いはサーバにTCP/IPを許可する設定を忘れていることです。

代わりに、ローカルのサーバにUnixソケット通信を試みると下記のような表示が出ます。

psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory
        Is the server running locally and accepting connections on that socket?

サーバが実行中にもかかわらずこうなるなら、クライアントが想定しているソケットパス(ここでは/tmp)がサーバのunix_socket_directories設定と一致しているかどうか確認してください。

接続失敗のメッセージは常にサーバのアドレスか、ソケットパス名を表示し、クライアントが正しいところに接続しようとしていることを確認するのに役立ちます。 もしそこを接続待ちしているサーバがない場合、典型的なカーネルエラーメッセージは、表示されているようにConnection refusedもしくはNo such file or directoryとなります。 (この場合のConnection refusedはサーバが接続要求を受け付けた後に拒否したわけではないということを理解しておくことが大切です。 もしそうだった場合は21.15で示されるような別のメッセージが表示されます。) Connection timed outのような他のメッセージは、例えばネットワーク接続の欠如、あるいはファイアウォールが接続をブロックしているようなもっと根本的な問題を表しています。