18.3. データベースサーバの起動

PostgreSQL 17.0文書
		第18章サーバの準備と運用	誤訳等の報告
前へ	上へ	18.3. データベースサーバの起動	次へ

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

<title>Starting the Database Server</title>

Before anyone can access the database, you must start the database server. The database server program is called <command>postgres</command>.<indexterm><primary>postgres</primary></indexterm> データベースにアクセスするためには、まずデータベースサーバを起動しなくてはいけません。データベースサーバプログラムはpostgresという名前です。

If you are using a pre-packaged version of <productname>PostgreSQL</productname>, it almost certainly includes provisions for running the server as a background task according to the conventions of your operating system. Using the package's infrastructure to start the server will be much less work than figuring out how to do this yourself. Consult the package-level documentation for details. パッケージ化された版のPostgreSQLを使用している場合は、オペレーティングシステムの規則に従って、サーバをバックグラウンドタスクとして実行するための提供がほぼ確実に含まれています。パッケージの基盤を使用してサーバを起動させるほうが、自分でこれをおこなう方法を理解するよりもはるかに作業量が少なくなります。詳細についてはパッケージレベルのドキュメントを参照してください。

The bare-bones way to start the server manually is just to invoke <command>postgres</command> directly, specifying the location of the data directory with the <option>-D</option> option, for example: サーバを手動で起動するための必要最低限の方法は、-Dオプションを使用してデータディレクトリの場所を指定postgresを直接呼び出することです。次に例を示します。

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

which will leave the server running in the foreground. This must be done while logged into the <productname>PostgreSQL</productname> user account. Without <option>-D</option>, the server will try to use the data directory named by the environment variable <envar>PGDATA</envar>. If that variable is not provided either, it will fail. 上記のコマンドはサーバをフォアグラウンドで実行させます。これは、PostgreSQLユーザアカウントでログインしている間に実行されなくてはいけません。 -Dオプションが指定されていない場合、サーバはPGDATA環境変数で指定されたデータディレクトリを使用しようと試みます。どちらの変数も指定されていなければ失敗します。

Normally it is better to start <command>postgres</command> in the background. For this, use the usual Unix shell syntax: 通常はバックグラウンドでpostgresを起動することをお勧めします。そのためには以下のように通常のUnixシェルの構文を使います。

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

It is important to store the server's <systemitem>stdout</systemitem> and <systemitem>stderr</systemitem> output somewhere, as shown above. It will help for auditing purposes and to diagnose problems. (See <xref linkend="logfile-maintenance"/> for a more thorough discussion of log file handling.) この例のように、サーバの標準出力と標準エラー出力をどこかに保管しておくことが重要です。これは監査目的と問題の原因究明に役立ちます。（ログファイルの取り扱いについての全体的な説明については24.3を参照してください。）

The <command>postgres</command> program also takes a number of other command-line options. For more information, see the <xref linkend="app-postgres"/> reference page and <xref linkend="runtime-config"/> below. postgresプログラムには、この他にも多くのコマンドラインオプションを指定することができます。詳細はpostgresマニュアルページと後述の第19章を参照してください。

This shell syntax can get tedious quickly. Therefore the wrapper program <xref linkend="app-pg-ctl"/><indexterm><primary>pg_ctl</primary></indexterm> is provided to simplify some tasks. For example: こうしたシェル構文は長くなりがちです。そのため、 pg_ctl ラッパープログラムが提供されていて、いくつかのタスクを単純化しています。以下に例を示します。

pg_ctl start -l logfile

will start the server in the background and put the output into the named log file. The <option>-D</option> option has the same meaning here as for <command>postgres</command>. <command>pg_ctl</command> is also capable of stopping the server. これは、サーバをバックグラウンドで起動し、出力を指定されたログファイルに書き出します。 -Dオプションは、ここでもpostgresの場合と同じ意味を持ちます。 pg_ctlによってサーバを停止させることもできます。

Normally, you will want to start the database server when the computer boots.<indexterm> <primary>booting</primary> <secondary>starting the server during</secondary> </indexterm> Autostart scripts are operating-system-specific. There are a few example scripts distributed with <productname>PostgreSQL</productname> in the <filename>contrib/start-scripts</filename> directory. Installing one will require root privileges. 通常、コンピュータが起動された時にデータベースサーバも一緒に起動したい場合が多いと思われます。自動起動スクリプトはオペレーティングシステム固有のものです。いくつかのスクリプトの例はPostgreSQLのcontrib/start-scriptsディレクトリに同梱されています。このインストールにはおそらくroot権限が必要となります。

Different systems have different conventions for starting up daemons at boot time. Many systems have a file <filename>/etc/rc.local</filename> or <filename>/etc/rc.d/rc.local</filename>. Others use <filename>init.d</filename> or <filename>rc.d</filename> directories. Whatever you do, the server must be run by the <productname>PostgreSQL</productname> user account <emphasis>and not by root</emphasis> or any other user. Therefore you probably should form your commands using <literal>su postgres -c '...'</literal>. For example: 起動時にデーモンを開始する方法はシステムによって異なります。多くのシステムには/etc/rc.localファイルや/etc/rc.d/rc.localファイルがあります。他のシステムではinit.dやrc.dディレクトリが使用されます。何を実行するにしても、サーバはPostgreSQLユーザアカウントで起動させなければなりません。 rootであってはいけませんし、他のユーザでもいけません。したがって、su postgres -c '...'を使用してコマンドを実行する必要があるでしょう。以下に例を示します。

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

Here are a few more operating-system-specific suggestions. (In each case be sure to use the proper installation directory and user name where we show generic values.) さらにいくつかのオペレーティングシステム固有の提案を挙げます。（ここでは一般的な値で説明していますので、各項目において適切なインストールディレクトリとユーザ名に置き換えて読んでください。）

For <productname>FreeBSD</productname>, look at the file <filename>contrib/start-scripts/freebsd</filename> in the <productname>PostgreSQL</productname> source distribution. <indexterm><primary>FreeBSD</primary><secondary>start script</secondary></indexterm> FreeBSDでは、PostgreSQLのソース配布物の中にあるcontrib/start-scripts/freebsdファイルを参照してください。
On <productname>OpenBSD</productname>, add the following lines to the file <filename>/etc/rc.local</filename>: <indexterm><primary>OpenBSD</primary><secondary>start script</secondary></indexterm> OpenBSDでは、以下の数行を/etc/rc.localファイルに追加してください。
```
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then
    su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/postgresql/log -D /usr/local/pgsql/data'
    echo -n ' postgresql'
fi
```
On <productname>Linux</productname> systems either add <indexterm><primary>Linux</primary><secondary>start script</secondary></indexterm> Linuxシステムでは、
```
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
```
to <filename>/etc/rc.d/rc.local</filename> or <filename>/etc/rc.local</filename> or look at the file <filename>contrib/start-scripts/linux</filename> in the <productname>PostgreSQL</productname> source distribution. を/etc/rc.d/rc.localや/etc/rc.localに追加してください。または、PostgreSQLのソース配布物の中にあるcontrib/start-scripts/linuxファイルを参照してください。
When using <application>systemd</application>, you can use the following service unit file (e.g., at <filename>/etc/systemd/system/postgresql.service</filename>):<indexterm><primary>systemd</primary></indexterm> systemdを使用する場合は以下のサービスユニットファイルを（例えば/etc/systemd/system/postgresql.serviceとして）使用できます。
```
[Unit]
Description=PostgreSQL database server
Documentation=man:postgres(1)
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
User=postgres
ExecStart=/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
KillSignal=SIGINT
TimeoutSec=infinity

[Install]
WantedBy=multi-user.target
```
Using <literal>Type=notify</literal> requires that the server binary was built with <literal>configure --with-systemd</literal>. Type=notifyを使うには、サーバのバイナリがconfigure --with-systemdでビルドされている必要があります。
Consider carefully the timeout setting. <application>systemd</application> has a default timeout of 90 seconds as of this writing and will kill a process that does not report readiness within that time. But a <productname>PostgreSQL</productname> server that might have to perform crash recovery at startup could take much longer to become ready. The suggested value of <literal>infinity</literal> disables the timeout logic. タイムアウトの設定について慎重に検討してください。この文書を書いている時点で、systemdのデフォルトのタイムアウトは90秒で、その時間内に準備ができたことを報告しないプロセスは終了させられます。しかし、PostgreSQLサーバは起動時にクラッシュリカバリを実行せねばならないことがあり、準備ができるまでにそれよりずっと長い時間を要することがあります。ここで提案されているinfinityという値は、そのタイムアウトの仕組みを無効にします。
On <productname>NetBSD</productname>, use either the <productname>FreeBSD</productname> or <productname>Linux</productname> start scripts, depending on preference. <indexterm><primary>NetBSD</primary><secondary>start script</secondary></indexterm> NetBSDでは、FreeBSDかLinuxの好きな方の起動スクリプトを使用してください。
On <productname>Solaris</productname>, create a file called <filename>/etc/init.d/postgresql</filename> that contains the following line: Solarisでは、/etc/init.d/postgresqlというファイルを作成し、そこに以下の1行を記述してください。 <indexterm><primary>Solaris</primary><secondary>start script</secondary></indexterm>
```
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
```
Then, create a symbolic link to it in <filename>/etc/rc3.d</filename> as <filename>S99postgresql</filename>. そして、/etc/rc3.d以下にS99postgresqlとしてそのファイルに対するシンボリックリンクを作成してください。

While the server is running, its <acronym>PID</acronym> is stored in the file <filename>postmaster.pid</filename> in the data directory. This is used to prevent multiple server instances from running in the same data directory and can also be used for shutting down the server. サーバが実行している間は、そのPIDはデータディレクトリの中のpostmaster.pidファイルに記述されています。これは同じデータディレクトリで複数のサーバインスタンスが実行されるのを防止し、また、サーバの停止にも使うことができます。

18.3.1. サーバ起動の失敗 #

<title>Server Start-up Failures</title>

There are several common reasons the server might fail to start. Check the server's log file, or start it by hand (without redirecting standard output or standard error) and see what error messages appear. Below we explain some of the most common error messages in more detail. サーバの起動が失敗する理由として代表的なものがいくつかあります。サーバのログファイルを点検するか、（標準出力や標準エラーをリダイレクトせずに）手動で起動して、どのようなエラーメッセージが出ているか確認してください。以下に、よく発生するエラーメッセージのいくつかをより詳細に説明します。

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

This usually means just what it suggests: you tried to start another server on the same port where one is already running. However, if the kernel error message is not <computeroutput>Address already in use</computeroutput> or some variant of that, there might be a different problem. For example, trying to start a server on a reserved port number might draw something like: これはたいていの場合メッセージが示す通りの意味です。既にサーバが動いているポートで別のサーバを起動しようとしたことを示しています。しかし、カーネルエラーメッセージが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

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

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

probably means your kernel's limit on the size of shared memory is smaller than the work area <productname>PostgreSQL</productname> is trying to create (4011376640 bytes in this example). This is only likely to happen if you have set <literal>shared_memory_type</literal> to <literal>sysv</literal>. In that case, you can try starting the server with a smaller-than-normal number of buffers (<xref linkend="guc-shared-buffers"/>), or reconfigure your kernel to increase the allowed shared memory size. You might also see this message when trying to start multiple servers on the same machine, if their total space requested exceeds the kernel limit. これは、おそらくカーネルによる共有メモリのサイズの上限がPostgreSQLが作ろうとしている作業領域（この例では4011376640バイト）よりも小さいことを示しています。これはshared_memory_typeをsysvに設定した場合にのみ発生する可能性があります。その場合は、サーバを通常よりも少ないバッファ数（shared_buffers）で起動するか、カーネルを再設定して許容される共有メモリサイズを増やすこともできます。このメッセージは、同じマシン上で複数のサーバを起動しようとした時に、要求された領域の合計がカーネルの上限を超えた場合にも表示されます。

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

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

does <emphasis>not</emphasis> mean you've run out of disk space. It means your kernel's limit on the number of <systemitem class="osname">System V</systemitem> semaphores is smaller than the number <productname>PostgreSQL</productname> wants to create. As above, you might be able to work around the problem by starting the server with a reduced number of allowed connections (<xref linkend="guc-max-connections"/>), but you'll eventually want to increase the kernel limit. ディスクの空き容量がなくなったということを示しているわけではありません。これはカーネルのSystem Vセマフォの上限が、PostgreSQLが作成しようとしている数よりも小さいということを意味しています。上記のように、許可される接続の数（max_connections）を減らしてサーバを起動させることで問題は回避できるかもしれませんが、最終的にはカーネルの設定を変えてセマフォの上限を増やした方が良いでしょう。

Details about configuring <systemitem class="osname">System V</systemitem> <acronym>IPC</acronym> facilities are given in <xref linkend="sysvipc"/>. System V IPC設備の設定についての詳細は18.4.1を参照してください。

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

<title>Client Connection Problems</title>

Although the error conditions possible on the client side are quite varied and application-dependent, a few of them might be directly related to how the server was started. Conditions other than those shown below should be documented with the respective client application. クライアント側で起こり得るエラー状態はきわめて多様で、アプリケーションに依存します。その中のいくつかはサーバが起動された方法と直接関係するかもしれません。以下で説明する以外の状態については各々のクライアントアプリケーションの資料を参照してください。

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?

This is the generic <quote>I couldn't find a server to talk to</quote> failure. It looks like the above when TCP/IP communication is attempted. A common mistake is to forget to configure the server to allow TCP/IP connections. これは一般的な「接続するサーバが見つけられませんでした」という失敗です。 TCP/IP通信を試みた時に上記のように表示されます。よくある間違いはサーバにTCP/IPを許可する設定を忘れていることです。

Alternatively, you might get this when attempting Unix-domain socket communication to a local server: 代わりに、ローカルのサーバに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?

If the server is indeed running, check that the client's idea of the socket path (here <literal>/tmp</literal>) agrees with the server's <xref linkend="guc-unix-socket-directories"/> setting. サーバが実行中にもかかわらずこうなるなら、クライアントが想定しているソケットパス（ここでは/tmp）がサーバのunix_socket_directories設定と一致しているかどうか確認してください。

A connection failure message always shows the server address or socket path name, which is useful in verifying that the client is trying to connect to the right place. If there is in fact no server listening there, the kernel error message will typically be either <computeroutput>Connection refused</computeroutput> or <computeroutput>No such file or directory</computeroutput>, as illustrated. (It is important to realize that <computeroutput>Connection refused</computeroutput> in this context does <emphasis>not</emphasis> mean that the server got your connection request and rejected it. That case will produce a different message, as shown in <xref linkend="client-authentication-problems"/>.) Other error messages such as <computeroutput>Connection timed out</computeroutput> might indicate more fundamental problems, like lack of network connectivity, or a firewall blocking the connection. 接続失敗のメッセージは常にサーバのアドレスか、ソケットパス名を表示し、クライアントが正しいところに接続しようとしていることを確認するのに役立ちます。もしそこを接続待ちしているサーバがない場合、典型的なカーネルエラーメッセージは、表示されているようにConnection refusedもしくはNo such file or directoryとなります。（この場合のConnection refusedはサーバが接続要求を受け付けた後に拒否したわけではないということを理解しておくことが大切です。もしそうだった場合は20.15で示されるような別のメッセージが表示されます。） Connection timed outのような他のメッセージは、例えばネットワーク接続の欠如、あるいはファイアウォールが接続をブロックしているようなもっと根本的な問題を表しています。

前へ	上へ	次へ
18.2. データベースクラスタの作成	ホーム	18.4. カーネルリソースの管理