「FAQ」の版間の差分

提供: pgpool Wiki
移動先: 案内、 検索
(→‎Pgpool-II Frequently Asked Questions)
(英語版 FAQ を和訳しました。)
1行目: 1行目:
 
__FORCETOC__
 
__FORCETOC__
  
−
== Pgpool-II Frequently Asked Questions ==
+
== Pgpool-II FAQ ==
  
−
=== '''Why configure fails by "pg_config not found" on my Ubuntu box?''' ===
+
=== '''私の Ubuntu box では "pg_config not found" と設定に失敗するのはなぜですか？''' ===
−
: pg_config is in libpq-dev package. You need to install it before running configure.
+
: pg_config は libpq-dev パッケージに含まれています。設定の前に libpq-dev パッケージをインストールする必要があります。
  
−
=== '''Why records inserted on the primary node do not appear on the standby nodes?''' ===
+
=== '''プライマリノードにインサートしたレコードがスタンバイノードで表示されないのはなぜですか？''' ===
−
: Are you using streaming replication and a hash index on the table? Then it's a known limitation of streaming replication. The inserted record is there. But if you SELECT the record using the hash index, it will not appear. Hash index changes do not produce WAL record thus they are not reflected to the standby nodes. Solutions are: 1) use btree index instead 2) use pgpool-II native replication.
+
: ストリーミングレプリケーションと、テーブルにハッシュインデックスを使っていませんか？それらはストリーミングレプリケーションの制限として知られています。インサートされたレコードはそこにあります。しかし、ハッシュインデックスを使ってそのレコードを参照すると、表示されません。ハッシュインデックスの変更は WAL レコードを作成しないので、スタンバイノードに反映されません。解決方法は、 1) 代わりに btree インデックスを使うか、 2) pgpool-II のレプリケーションモードを使うかです。
  
−
=== '''Can I mix different versions of PostgreSQL as pgpool-II backends?''' ===
+
=== '''pgpool-II のバックエンドサーバとしてバージョンの異なる PostgreSQL を混在させることはできますか？''' ===
−
: You cannot mix different major versions of PostgreSQL, for example 8.4.x and 9.0.x. On the other hand you can mix different minor versions of PostgreSQL, for example 9.0.3 and 9.0.4. Pgpool-II assumes messages from PostgreSQL to pgpool-II are identical anytime. Different major version of PostgreSQL may send out different messages and this would cause trouble for Pgpool-II.
+
: メジャーバージョンの異なる PostgreSQL（たとえば、8.4.x と 9.0.x）を混在させることはできませんが、 マイナーバージョンの異なる PostgreSQL（たとえば 9.0.3 と 9.0.4）を混在させることはできます。Pgpool-II は PostgreSQL から pgpool-II へ送信されるメッセージは常に同一であることを想定しています。メジャーバージョンが異なる PostgreSQL は異なるメッセージを送信する可能性があり、これは pgpool-II に問題を引き起こす可能性があります。
  
−
=== '''Can I mix different platforms of PostgreSQL as pgpool-II backends, for example Linux and Windows?''' ===
+
=== '''たとえば、Linux と Windows といったように、pgpool-II のバックエンドサーバとして PostgreSQL のプラットフォームを混在させることはできますか？''' ===
−
: In streaming replication mode, no. Because streaming replication requires that primary and standby platforms are phsyically identical. On the other hand, pgpool-II's replication mode only requires logically database clusters identical. Beware, however, that online recovery script does not use rsync or some such, which do phical copying among database clusters. You want to use pg_dumpall instead.
+
: ストリーミングレプリケーションモードの場合は、できません。ストリーミングレプリケーションは、プライマリとスタンバイのプラットフォームが物理的に同一である必要があるからです。その一方で、pgpool-II の レプリケーションモードは論理的にデータベースクラスタが同一であることしか必要でありません。しかしながら、 オンラインリカバリのスクリプトは rsync やデータベースクラスタを含めた物理的なコピーといったようなことに使えない点に注意してください。代わりに pg_dumall を使ってください。
  
−
=== '''It seems my pgpool-II does not do load balancing. Why?''' ===
+
=== '''pgpool-II がロードバランスを行っていないようですが、なぜですか？''' ===
−
: First of all, pgpool-II' load balancing is "session base", not "statement base". That means, DB node selection for load balancing is decided at the beginning of session. So all SQL statements are sent to the same DB node until the session ends.
+
: まずはじめに、 pgpool-II のロードバランスは "セッションベース" であり "ステートメントベース" ではありません。これはつまり、 ロードバランス用の DB ノードの選択は、セッションの開始時に決定されることを意味しています。したがって、全ての SQL ステートメントは、セッションが終了するまで、同じ DB ノードに送信されます。
  
−
: Another point is, whether statement is in an explicit transaction or not. If the statement is in a transaction, it will not be load balanced in the replication mode. In pgpool-II 3.0 or later, SELECT will be load balanced even in a transaction if operated in the master/slave mode.
+
: 他の注意点は、ステートメントが明示的なトランザクションであるかそうでないかということです。ステートメントがトランザクション内であった場合、レプリケーションモードのステートメントはロードバランスされないでしょう。 pgpool-II 3.0 かそれ以降であれば、マスタースレーブモード時の SELECT 文はトランザクション内であってもロードバランスされるでしょう。
  
−
: Note the method to choose DB node is not LRU or some such. Pgpool-II chooses DB node randomly considering the "weight" parameter in pgpool.conf. This means that the chosen DB node is not uniformly distributed among DB nodes in short term. You might want to inspect the effect of load balancing after ~100 queries have been sent.
+
: DB ノードの選択方法は LRU といったような方式ではないことに留意してください。Pgpool-II は、pgpool.conf の "weight" パラメータによって無作為に DB ノードを選択します。これはつまり、選択された DB ノードは短期的には他の DB ノードに一様に分散されないことを意味しています。 100 クエリが送信されたあとで、ロードバランスの効果を検査してください。
  
−
: Also cursor statements are not load balanced in replication mode. i.e.:DECLARE..FETCH are sent to all DB nodes in replication mode. This is because the SELECT might come with FOR UPDATE/FOR SHARE. Note that some applications including psql could use CURSOR for SELECT. For example, from PostgreSQL 8.2, if "\set FETCH_COUNT n" is executed, psql unconditionaly uses a curor named "_psql_cursor".
+
: レプリケーションモードでは、カーソル宣言もロードバランスされません。つまり、レプリケーションモードでは、 "DECLARE..FETCH" は全ての DB ノードに送信されます。これは、SELECT 文には "FOR UPDATE/FOR SHARE" が付属する場合があるからです。psql を含んでいるいくつかのアプリケーションは SELECT 文でカーソルが使えるということに留意してください。例えば、PostgreSQL 8.2からは、"\set FETCH_COUNT n" が実行された場合、psql は無条件に "_psql_cursor" と名付けられたカーソルを使用します。
  
−
=== '''How can I observe the effect of load balancing?''' ===
+
=== '''ロードバランスの効果を確認するにはどうすればよいですか？''' ===
−
: We recommend to enable "log_per_node_statement" directive in pgpool.conf for this. Here is an example of the log:
+
: pgpool.conf の "log_per_node_statement" ディレクティブを有効にしてください。以下はログの一例です:
 
: <pre>2011-05-07 08:42:42 LOG:  pid 22382: DB node id: 1 backend pid: 22409 statement: SELECT abalance FROM pgbench_accounts WHERE aid = 62797;</pre>
 
: <pre>2011-05-07 08:42:42 LOG:  pid 22382: DB node id: 1 backend pid: 22409 statement: SELECT abalance FROM pgbench_accounts WHERE aid = 62797;</pre>
−
: The "DB node id: 1" shows which DB node was chosen for this loadbalancing session.
+
: "DB node id: 1" はどの DB ノードがこのロードバランシングセッションで選択されたかを示しています。
  
−
: Please make sure that you start pgpool-II with "-n" option to get pgpool-II log. (or you can use syslog in pgpool-II 3.1 or later)
+
: pgpool-II のログを取得したい場合は、必ず pgpool-II に "-n" オプションを指定して起動してください（あるいは、pgpool-II 3.1 かそれ以降であれば、syslog を使うこともできます）。
  
−
=== '''Why am I getting "ProcessFrontendResponse: failed to read kind from frontend. frontend abnormally exited" in my pgool log?''' ===
+
=== '''pgpool の ログで "ProcessFrontendResponse: failed to read kind from frontend. frontend abnormally exited" を受け取るのはなぜですか？''' ===
−
: Well, your clients might be ill-behaved:-) PostgreSQL's protocol requires clients to send particular packet before they disconnect the connection. pgpool-II complains that clients disconnect without sending the packet. You could reprodcude the problem by using psql. Connect to pgpool using psql. Kill -9 psql. You will silimar message in the log. The message will not appear if you quit psql normaly. Another possibility is unstable network connection between your client machine and pgpool-II. Check the cable and network interface card.
+
: ええと、おそらくクライアントが行儀の悪い振る舞いをしているのでしょう:-) PostgreSQL のプロトコルは、クライアントが接続を終了する際に特定のパケットを送信することを要求します。pgpool-II は クライアントがパケットを送信せずに切断したことを訴えています。これは psql を使って再現可能です。psql で pgpool に接続してください。Kill -9 で psql を終了してください。似たようなログが出力されるでしょう。このメッセージは、正常に psql を終了した場合は表示されないでしょう。その他の可能性はクライアントマシーンと pgpool-II 間の不安定なネットワーク接続です。ケーブルと NIC を確認してみてください。
  
−
 
+
=== '''ストリーミングレプリケーションモードで pgpool-II を実行しています。動作しているようですが、以下のエラーがログにありました。なぜですか？''' ===
−
=== '''I'm running pgpool-II in streaming replication mode. It seems it works but I find following errors in the log. Why?''' ===
 
 
<dl><dd><pre>2011-07-19 08:21:59 ERROR: pid 10727: s_do_auth: unknown response "E" before processing BackendKeyData
 
<dl><dd><pre>2011-07-19 08:21:59 ERROR: pid 10727: s_do_auth: unknown response "E" before processing BackendKeyData
 
2011-07-19 08:21:59 ERROR: pid 10727: s_do_auth: unknown response "" before processing BackendKeyData
 
2011-07-19 08:21:59 ERROR: pid 10727: s_do_auth: unknown response "" before processing BackendKeyData
44行目: 43行目:
 
2011-07-19 08:21:59 ERROR: pid 10727: make_persistent_db_connection: s_do_auth failed
 
2011-07-19 08:21:59 ERROR: pid 10727: make_persistent_db_connection: s_do_auth failed
 
2011-07-19 08:21:59 ERROR: pid 10727: find_primary_node: make_persistent_connection failed</pre></dl>
 
2011-07-19 08:21:59 ERROR: pid 10727: find_primary_node: make_persistent_connection failed</pre></dl>
−
: pgpool-II tries to connect to PostgreSQL to execute some functions such as pg_current_xlog_location(), which is used for detecting primary server or checking replication delay. The messages above indicate that pgpool-II failed to connect with user = health_check_user and password = health_check_password. You need to set them properly even if health_check_period = 0.
+
: pgpool-II は PostgreSQL に接続して pg_current_xlog_location() などの関数を実行します。これらはプライマリサーバの検出やレプリケーションの遅延を確認するために使われます。上記のメッセージは user と health_check_user が同一で、password と health_check_password が同一の状態で pgpool-II が接続に失敗したことを示しています。health_check_period が 0 であったとしても、これらのパラメータは適切に設定してください。
  
−
: Note that pgpool-II 3.1 or later will use sr_check_user and sr_check_password for it instead.
+
: pgpool-II 3.1 かそれ以降であれば sr_check_user と sr_check_password が代わりに使えることを留意してください。
  
−
=== '''When I run pgbench to test pgpool-II, pgbench hangs. If I directly run pgbench against PostgreSQL, it works fine. Why?''' ===
+
=== '''pgpool-II の検証のために pgbench を実行したら、pgbench がハングしました。PostgreSQL に対して直接 pgbench を実行したらうまくいきました。なぜですか？''' ===
−
: pgbench creates concurrent connections (the number of connections is specified by "-c" option) before starting actual transactions. So if the number of concurrent transactions specified by "-c" exceeds num_init_children, pgbench will stuck because it will wait for pgpool accepting connections forever (remember that pgpool-II accepts up to num_init_children concurrent sessions. If the number of concurrent sessions reach num_init_children, new session will be queued). On the other hand PostgreSQL does not accept concurrent sessions more than max_connections. So in this case you will just see PostgreSQL errors, rather than connection blocking. If you want to test pgpool-II's connection queuing, you can use psql instead of pgbench. In the example session below, num_init_children = 1 (this is not a recommended setting in the real world. This is just for simplicity).
+
: pgbench は実際のトランザクションを実行する前に同時接続（"-c" オプションで指定される接続数）を行います。したがって、"-c" で指定された同時接続数が num_init_children を超えた場合、pgbench は pgpool の接続許可を永久に待ち続けるために固まってしまうでしょう（pgpool-II は最大 num_init_children までの同時セッションを受け付けることを忘れないでください。同時セッション数が num_init_children に到達した場合、新しいセッションがキューされます）。その一方で、PostgreSQL は同時セッションを max_connections 以上受け付けません。したがって、この場合は接続をブロックするよりも、PostgreSQL のログを確認してみてください。pgpool-II の接続要求のキューイングを検証したい場合は、pgbench の代わりに psql が使えます。以下の例では、 num_init_children = 1 としています（これは実際には推奨される設定ではありません。単純化しています）。
 
<dl><dd><pre>$ psql test <-- connect to pgpool from terminal #1
 
<dl><dd><pre>$ psql test <-- connect to pgpool from terminal #1
 
psql (9.1.1)
 
psql (9.1.1)
60行目: 59行目:
 
Type "help" for help.
 
Type "help" for help.
 
test=# </pre></dl>
 
test=# </pre></dl>
−
* '''I created pool_hba.conf and pool_passwd to enable md5 authentication through pgpool-II but it does not work. Why?'''
+
 
−
: Probably you made mistake somewhere. For your help here is a table which describes error patterns depending on the setting of pg_hba.conf, pool_hba.conf and pool_passwd.
+
=== '''pgpool-II を通して md5 認証ができるように pool_hba.conf と pool_passwd を設定しましたが、 うまく動作しません。なぜですか？''' ===
 +
: おそらく、どこかを間違えています。参考として pg_hba.conf、pool_hba.conf、pool_passwd 設定時のエラーパターンを表にしておきます。
 
<dl><dd>
 
<dl><dd>
 
{|styles="background:white; color:black" border="1"
 
{|styles="background:white; color:black" border="1"
101行目: 101行目:
 
|}
 
|}
 
</dl>
 
</dl>
−
=== '''How can I set up SSL for pgpool-II?''' ===
+
 
−
<dl><dd>SSL support for pgpool-II consists of two parts: 1)between client and pgpool-II 2)pgpool-II and PostgreSQL. #1 and #2 are independent each other. For example, you can only enable SSL connection of #1, or #2. Or you can enable both #1 and #2. I explain #1 (for #2, please take a look at PostgreSQL documentation).
+
=== '''pgpool-II の SSL 設定はどうすればよいですか？''' ===
−
<br>
+
: pgpool-II の SSL サポートは 2 つのパートからなっています: 1) クライアントと pgpool-II 間、 2) pgpool-II と PostgreSQL 間です。#1 と #2 は互いに独立しています。たとえば、#1 か #2 のどちらかだけ SSL 接続を有効にできます。あるいは、#1 と #2 のどちらも有効にできます。#1 について説明します（#2 については、PostgreSQL のドキュメントを確認してください)。
−
Make sure that pgpool is built with openssl. If you build from source code, use --with-openssl option.
+
 
−
<br>
+
: pgpool が openssl を有効にした状態でビルドされていることを確認してください。ソースコードからビルドする場合、--with-openssl オプションを使ってください。
−
First create server certificate. In the command below you will be asked PEM pass phrase(It will be asked when pgpool starts up).
+
 
−
If you want to start pgpool without being asked pass phrase, you can remove it later.
+
: はじめにサーバ証明証を作成します。以下のコマンドで、PEM パスフレーズ（pgpool 起動時に要求されます）を要求されます。
−
([[sample server certficate create session]])
+
: パスフレーズの要求なしに pgpool を起動したい場合は、あとで削除することも可能です([[sample server certficate create session]])。
−
<pre>
+
<dl><dd><pre>openssl req -new -text -out server.req</pre></dl>
−
openssl req -new -text -out server.req
+
: 必要であれば、 PEM パスフレーズを削除してください。
−
</pre>
+
<dl><dd><pre>$ openssl rsa -in privkey.pem -out server.key
−
Remove PEM pass phrase if you want.
 
−
<pre>
 
−
$ openssl rsa -in privkey.pem -out server.key
 
 
Enter pass phrase for privkey.pem:
 
Enter pass phrase for privkey.pem:
 
writing RSA key
 
writing RSA key
−
$ rm privkey.pem
+
$ rm privkey.pem</pre></dl>
−
</pre>
+
: 証明書を自己署名証明書に変更してください。
−
Turn the certificate into a self-signed certificate.
+
<dl><dd><pre>$ openssl req -x509 -in server.req -text -key server.key -out server.crt</pre></dl>
−
<pre>
+
: server.key と server.crt を適切な場所にコピーしてください。ここでは /usr/local/etc にコピーしたことにします。server.key の適切なパーミッションを維持するために、 cp -p を必ず使ってください。あるいは、パーミッションを後で設定してください。
−
$ openssl req -x509 -in server.req -text -key server.key -out server.crt
+
<dl><dd><pre>$ chmod og-rwx /usr/local/etc/server.key</pre></dl>
−
</pre>
+
: 証明書と鍵の位置を pgpool.conf で設定してください。
−
Copy server.key and server.crt to appropreate place. Suppose we copy to /usr/local/etc.
+
<dl><dd><pre>ssl = on
−
Make sure that you use cp -p to retain appropreate permission of server.key.
 
−
Alternatively you can set permission later.
 
−
<pre>
 
−
$ chmod og-rwx /usr/local/etc/server.key
 
−
</pre>
 
−
Set the certificate and key location in pgpool.conf.
 
−
<pre>
 
−
ssl = on
 
 
ssl_key = '/usr/local/etc/server.key'
 
ssl_key = '/usr/local/etc/server.key'
−
ssl_cert = '/usr/local/etc/server.crt'
+
ssl_cert = '/usr/local/etc/server.crt'</pre></dl>
−
</pre>
+
: pgpool を再起動してください。クライアントと pgpool 間の SSL 接続が動作しているか確認するために psql で pgpool に接続してください。
−
Restart pgpool.
+
<dl><dd><pre>psql -h localhost -p 9999 test
−
To confirm SSL connection between client and pgpool is working, connect to pgpool using psql.
 
−
<pre>
 
−
psql -h localhost -p 9999 test
 
 
psql (9.1.1)
 
psql (9.1.1)
 
SSL connection (cipher: AES256-SHA, bits: 256)
 
SSL connection (cipher: AES256-SHA, bits: 256)
 
Type "help" for help.
 
Type "help" for help.
  
−
test=# \q
+
test=# \q</pre></dl>
−
</pre>
+
: "SSL connection..." と表示されていたら、クライアントと pgpool 間の SSL 接続は動作しています。"-h localhost" オプションを必ず使用してください。SSL は TCP/IP でのみ動作し、Unix ドメインソケットでは動作しないからです。
−
If you see "SSL connection...", SSL connection between client and pgpool is working.
+
 
−
Please make sure that use "-h localhost" option. Because SSL only works with TCP/IP,
+
=== '''レプリケーションモードで pgpool-II を使っています。 pgpool-II が INSERT クエリ内の current_timestamp を呼び出し時の同一時刻に置き換えること期待しましたが、置き換えられませんでした。なぜですか？''' ===
−
with Unix domain socket SSL does not work.
+
:おそらく、INSERT クエリが（public.mytable のような）スキーマが修飾されたテーブル名を使っており、 pool_regclass 関数を pgpool にインストールしていないのでしょう。pgpool_reglclass がないと pgpool-II はスキーマ修飾を除いたテーブル名のみを扱います。
−
</dl>
 
−
=== '''I'm using pgpool-II in replication mode. I expected that pgpool-II replaces current_timestamp call with time constants in my INSERT query, but actually it doesn't. Why?''' ===
 
−
:Probably your INSERT query uses schema qualied table name (like public.mytable) and you did not install pool_regclass function coming pgpool. Without pgpool_reglclass, pgpool-II only deals with table names without schema qualification.
 
  
−
=== '''Why max_connection must satisfy this formula max_connection >= (num_init_children * max_pool) and not max_connection >= num_init_children?''' ===
+
=== '''max_connection が not max_connection >= num_init_children でなく、max_connection >= (num_init_children * max_pool) を満たしていなければならないのはなぜですか？''' ===
−
: Probably you need to understand how pgpool uses these variables. Here is internal processing inside pgpool.
+
: おそらく、pgpool がこれらの値をどのように使うのかを理解する必要があります。以下は、pgpool の内部処理です。
 
<ol>
 
<ol>
−
<li>Wait for connection request from clients.
+
<li>クライアントからの接続要求を待ちます。
−
<li>pgpool child receives connection request from a client.
+
<li>pgpool 子プロセスがクライアントからの接続要求を受けます。
−
<li>The pgpool child looks for existing connection in the pool which
+
<li>最大 max_pool の、接続要求されたデータベースとユーザのペアを保持しているコネクションプールから、pgpool 子プロセスは存在している接続を探します。
−
  has requested database/user pair up to max_pool.
+
<li>見つかれば、それを再利用します。
−
<li>If found, reuse it.
+
<li>見つからなければ、PostgreSQL への新しい接続を開き、それをコネクションプールへ登録します。コネクションプールに空きスロットがなければ、最も古い接続を終了し、そのスロットを再利用します。
−
<li> If not found, opens a new connection to PostgreSQL and registers to
+
<li>クライアントがセッションの終了要求を送るまで、クエリ処理を行います。
−
  the pool.  If the pool has no empty slot, closes the oldest
+
<li>クライアントの接続を終了しますが、将来の利用のために PostgreSQL への接続は維持します。
−
  connection to PostgreSQL and reuse the slot.
+
<li>#1 に戻ります。
−
<li>Do some query processing until the client sends session close request.
 
−
<li>Close the connection to client but keeps the connection to
 
−
  PostgreSQL for future use.
 
−
<li>Go to #1
 
 
</ol>
 
</ol>
  
−
=== '''Is connection pool cache shared among pgpool process?''' ===
+
=== '''コネクションプールキャッシュは pgpool プロセス内で共有していますか？''' ===
−
:No, the connection pool cache is in pgpool's process private memory and is not shared by other pgpool. This is how the connection cache is managed: Suppose pgpool process 12345 has connection cache for database A/user B but process 12346 does not have connection cache for database A/user B and both 12345 and 12346 are in idle state(no client is connecting at this point). If client connects to pgpool process 12345 with database A/user B, then the exisiting connection of 12345 is reused. On the other hand, If client connects to pgpool process 12346, 12346 needs to create new connection.  Whether 12345 or 12346 is chosen, is not under control of pgpool. However in the long run, each pgpool child process will be equally chosen and it is expected that each process's pool will be resued equally.
+
:いいえ、コネクションプールキャッシュは pgpool のプライベートメモリ内に存在しており、他の pgpool と共有されていません。コネクションキャッシュの管理方法は次の通りです: pgpool プロセス 12345 がデータベース A/ユーザ B のコネクションキャッシュを持っており、プロセス 12346 はデータベース A/ユーザ B のコネクションキャッシュを持っておらず、どちらのプロセスもアイドル状態（この時点ではクライアントが接続していない）と仮定します。クライアントがデータベース A/ユーザ Bで、 プロセス 12345 の pgpool に接続する場合、存在している 12345 のコネクションが再利用されます。その一方で、クライアントが プロセス 1236 の　pgpool に接続する場合、12346 は新しい接続を作成する必要があります。12345 か 12346 のどちらが選択されるかを、pgpool はコントロールしていません。しかしながら、長期的には各 pgpool 子プロセスが同等に選択され、各プロセスのコネクションプールは同等に再利用されるでしょう。
−
 
 
−
=== '''Why my SELECTs are not cached?''' ===
 
−
 
 
−
:Certain libraries such as iBatis, MyBatis always rollback transactions if they are not explicitely committed. Pgpool never caches SELECTs result in a rollbacked transaction because they might not be inconsistent.
 
−
 
 
−
=== '''Can I use # comments or blank lines in pool_passwd?''' ===
 
  
−
: The answer is simple. No (just like /etc/passwd).
+
=== '''SELECT 文がキャッシュされないのはなぜですか？''' ===
 +
:iBatis, MyBatis といったいくつかのライブラリは、明示的にコミットしない場合、常にトランザクションをロールバックします。不整合を起こす可能性があるので、pgpool はロールバックされたトランザクションの SELECT 文の結果は決してキャッシュしません。
  
−
=== '''I cannot use MD5 authentication if start pgpool without -n option. Why?''' ===
+
=== '''pool_passwd に # コメントや空行は使えますか？''' ===
−
: You must have given -f option as a relative path: i.e. "-f pgpool.conf", rather than full path: i.e. "-f /usr/local/etc/pgpool.conf". Pgpool tries to locate the full path of pool_passwd (which is neccesary for MD5 auth) from pgpool.conf path. This is fine with -n option. However if pgpool starts without -n option, it changes current directory to "/", which is neccessary processs for daemonizing. As a result, pgpool tries to open "/pool_passwd", which will not successs.
+
: 答えはシンプルです。使えません（/etc/passwd と同じようなものです）。
  
−
=== '''I see standby servers go down status in steaming replication mode and see PostgreSQL messages "terminating connection due to conflict" Why?''' ===
+
=== '''-n オプションを指定せずに pgpool を起動すると MD5 認証が使えません。なぜですか？''' ===
−
: If you see following messages along with those, it is likely vacuum on primary server removes rows which SELECTs on standby server want to see. Workaround is setting "hot_standby_feedback = on" in your standby server's postgresql.conf.
+
: -f オプションで相対パスを指定しなければなりません: i.e. "-f pgpool.conf" もしくは、フルパスを指定しなければなりません: i.e. "-f /usr/local/etc/pgpool.conf"。 pgpool は pgpool.conf パスから（MD5 認証に必要な）pool_passwd のフルパスを設定しようとします。しかしながら、-n オプションを指定せずに pgpool を起動すると、カレントディレクトリが "/" に変わってしまいます。そしてこれは、プロセスのデーモン化に必要です。結果として、 pgpool は "/pool_passwd" を開こうとして失敗してしまいます。
  
 +
=== '''ストリーミングレプリケーションモード時にスタンバイサーバが故障状態になり、 PostgreSQL の "terminating connection due to conflict" というメッセージを確認しました。なぜですか？''' ===
 +
: 以下のメッセージを含んでいるとしたら、プライマリサーバの vacuum がスタンバイサーバの SELECT 文で参照しようとした行を削除してしまった可能性があります。回避方法は、スタンバイサーバのpostgresql.conf に "hot_standby_feedback = on" を設定することです。
 
<dl><dd><pre>
 
<dl><dd><pre>
 
2013-04-07 19:38:10 UTC FATAL:  terminating connection due to conflict with recovery
 
2013-04-07 19:38:10 UTC FATAL:  terminating connection due to conflict with recovery
197行目: 173行目:
 
</pre></dl>
 
</pre></dl>
  
−
=== '''Every few minites load of the system which pgpool-II running on gets high as much as 5-10. Why?''' ===
+
=== '''pgpool-II が起動しているシステムのロードアベレージが 5 〜 10 程度に高くなります。なぜですか？''' ===
−
: Mulptiple users stats that this is observed only Linux kernel 3.0. 2.6 or 3.2 does show the behavior. We suspect that there is a problem with 3.0 kernel. See more discussions on "[pgpool-general: 1528] Mysterious Load Spikes".
+
: 多数のユーザが Linux kernel 3.0. 2.6 か 3.2 のみで発生すると述べています。私達は、Linux Kernel 3.0 の問題ではないかと推測しています。 詳細なディスカッションは "[pgpool-general: 1528] Mysterious Load Spikes" を参照してください。
−
 
 
−
=== '''When watchdog enabled and the connection number reach the number of num_init_children, VIP switchover occurs. Why?''' ===
 
  
−
:When the connection number reach the number of num_init_children, the watchdog will be failed because select 1 is failed, and then VIP will be transfer to another pgpool. Unfortunately, there are no way to discriminate normal client's connections from watchdog's connection. Larger num_init_children, wd_life_point and smaller wd_interval may prevent the problem somewhat.
+
=== '''watchdog を有効にした状態で接続数が num_init_children に到達すると、VIP のスイッチオーバーが発生します。なぜですか？''' ===
 +
:接続数が num_init_children に到達すると、select 1 が失敗するので watchdog が失敗します。そのため、 VIP は他の pgpool へ移動します。残念ながら、通常のクライアントと watchdog の接続を区別する方法はありません。num_init_children と wd_life_point を増やし、ler wd_interval を減らすとこの問題をいくらか防ぐことができるかもしれません。
  
−
:The next major version, pgpool-II 3.3, will support a new monitoring method which uses UDP heartbeat packets instead of queries such like 'SELECT 1' to resolve the problem.
+
:次のメジャーバージョンの pgpool-II 3.3 では、この問題を解決するために 'SELECT 1' のようなクエリの代わりに UDP のハートビートパケットを使った新しい監視方法をサポートします。
  
−
=== '''Why do I need to install pgpool_regclass? ''' ===
+
=== '''pgpool_regclass をインストールする必要があるのはなぜですか？ ''' ===
−
: If you are using PostgreSQL 8.0 or later, installing pgpool_regclass function on all PostgreSQL to be accessed by pgpool-II is strongly recommended, as it is used internally by pgpool-II. Without this, handling of duplicate table names in different schema might cause trouble (temporary tables aren't a problem).
+
:PostgreSQL 8.0 かそれ以降を使用している場合、pgpool-II がアクセスできるようにするために全ての PostgreSQL に pgpool_regclass 関数をインストールすることは強く推奨されており、実際に pgpool-II は内部でそれを利用しています。 pgpool_regclass 関数がないと、異なるスキーマの同じテーブル名を扱う場合に問題を引き起こす可能性があります（一時テーブルは問題ありません）。
−
:Related FAQ is here http://www.pgpool.net/mediawiki/index.php?title=FAQ&action=submit#I.27m_using_pgpool-II_in_replication_mode._I_expected_that_pgpool-II_replaces_current_timestamp_call_with_time_constants_in_my_INSERT_query.2C_but_actually_it_doesn.27t._Why.3F
+
:関連のある FAQ はこちらです。 http://www.pgpool.net/mediawiki/index.php?title=FAQ&action=submit#I.27m_using_pgpool-II_in_replication_mode._I_expected_that_pgpool-II_replaces_current_timestamp_call_with_time_constants_in_my_INSERT_query.2C_but_actually_it_doesn.27t._Why.3F
  
−
=== '''md5 authentication does not work. Please help''' ===
+
=== '''md5 認証が動作しません。助けてください。''' ===
−
: There's an excellent summary of various check points to set up md5 authentication. Please take a look at it.
+
: md5 認証セットアップのチェックポイントがとても良くまとめられたサマリがあります。そこを参照してください。
 
: http://www.pgpool.net/pipermail/pgpool-general/2013-May/001773.html
 
: http://www.pgpool.net/pipermail/pgpool-general/2013-May/001773.html
  
−
=== '''I'm running pgpool/PostgreSQL on Amazon AWS and occasionaly I get network errors. Why?''' ===
+
=== '''Amazon AWS で pgpool/PostgreSQL を運用していると、時々ネットワークエラーになります。なぜですか？''' ===
−
: It's a known problem with AWS. We recommend to complain to the Amazon support.
+
: AWS の既知の問題です。Amazon のサポートを利用することをお勧めします。
−
 
 
−
=== '''I cannot run pcp command on my Ubuntu box. Why?''' ===
 
−
: pcp commands need libpcp.so. In Ubuntu it is included "libpgpool0" package.
 
  
−
=== '''On line recovery failed. How can debug this?''' ===
+
=== '''私の Ubuntu box では pcp コマンドが実行できません。なぜですか？''' ===
−
: pcp_recovery_node executes recovery_1st_stage_command and/or recovery_2nd_stage_command depending on your configuration. Those scripts are supposed to be executed on the master PostgreSQL node (the first live node in replication mode or primary node in streaming replication mode). "BackendError" means there's something wrong in pgpool and/or PostgreSQL. To verify this, I recommend followings;
+
: pcp コマンドは libpcp.so を必要とします。Ubuntu では "libpgpool0" パッケージに含まれています。
  
 +
=== '''オンラインリカバリに失敗しました。どのようにデバッグすればよいですか？''' ===
 +
: pcp_recovery_node は recovery_1st_stage_command と recovery_2nd_stage_command の両方かどちらかを実行し、これは設定次第です。これらのスクリプトはマスターの PostgreSQL ノード（レプリケーションモード時の始めの稼働ノードか、ストリーミングレプリケーション時のプライマリノード）で実行されることになっています。"BackendError" は pgpool と PostgreSQL の両方かどちらか一方になにか問題が発生したことを意味します。これを検証するには、以下の手順をお勧めします。
 
<ol>
 
<ol>
−
<li>start pgpool with debug option
+
<li>デバッグオプションを指定して pgpool を起動します。
−
<li>execute pcp_recovery_node
+
<li>pcp_recovery_node を実行します。
−
<li>examin pgpool log and master PostgreSQL log
+
<li>pgpool とマスターの PostgreSQL のログを確認します。
 
</ol>
 
</ol>
  
−
=== ''' Watchdog doesn't start if not all "other" nodes are alive'''===
+
=== ''' 他のノードが稼働しているのに、Watchdog が起動しません。'''===
−
It's a feature. Watchdog's lifeheck will start after all of the pgpools has started. Until this, failover of the virtual IP never occurs.
+
: 仕様です。Watchdog の 生存監視は全ての pgpool の起動が完了した後で開始します。これまでは、 仮想 IP のフェイルオーバが全く発生しませんでした。
 +
 
 +
=== '''トランザクションを開始すると、pgool-II もスタンバイノードでトランザクションを開始します。なぜですか？'''===
 +
: これは JDBC ドライバがカーソルを使いたい場合に必要な処置です。Pgpool-II はカーソル宣言を含めて SELECT 文をスタンバイノードへ自動的に割り振ります。残念ながら、カーソル宣言は明示的なトランザクション内で実行される必要があります。
 +
 
 +
=== '''スキーマが修飾されたテーブル名を使うと、pgpool-II がオンメモリクエリキャッシュを無効にしてくれず、古いデータを受け取ってしまいます。なぜですか？'''===
 +
: "pgpool_regclass" 関数をインストールしていないのではないでしょうか。この関数がないと、pgpool-II はスキーマ修飾されたテーブル名のスキーマ名を無視し、キャッシュの無効化に失敗します。
 +
 
 +
=== '''定期的に "read_startup_packet: incorrect packet length" といったエラーメッセージを受け取ります。これは何を意味しているのですか？'''===
 +
: Zabbix や Nagios を含んだ監視ツールは、定期的にパケットや ping を pgpool の待ち受けポートに送信します。残念ながらこれらのパケットは適切なコンテンツを有しておらず、pgpool はdラーを出してしまいます。このようなパケットを誰が送信しているか不明な場合、"log_connections" を有効にして送信元のホストとポートを確認することができます。送信元が監視ツールであれば、この問題を回避するために監視を停止するか、より良い手段として、監視方法を "SELECT 1" のような適切なクエリに変更してください。
 +
 
 +
=== '''数分おきに繰り返し Tomcat で "An I/O Error occurred while sending to the backend" といったエラーを受け取ります。なぜですか？'''===
 +
: Tomcat は pgpool に持続的な接続を作成します。client_idle_limit を有効にしている場合、 pgpool はその接続を終了し、次の機会では Tomcat が pgpool に 何かを送信しようとした際にエラーメッセージを伴って送信内容は破棄されてしまいます。
 +
: 解決方法は client_idle_limit を無効に設定することです。しかしながら、これは多くの接続のアイドル状態を放置してしまいます。
 +
: 別の解決方法が、Lachezar Dobrevlution 氏によって提供されました:
 +
<blockquote>
 +
: Tomcat側 に time-out を設定すると解決できるかもしれません。 http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
 +
:  （私が知る限りで）設定するパラメータは以下です。:
 +
:    minIdle (default is 10, set to 0)
 +
:  timeBetweenEvictionRunsMillis (default 5000)
 +
:  minEvictableIdleTimeMillis    (default 60000)
 +
: この設定は 5 秒ごとに監視を試み、接続が過去 60 秒間利用されていなければ、いかなる接続も終了します。両者の合計値を pgpool のクライアントのタイムアウト値よりも低くしていれば、pgpool 側のタイムアウトの前に、Tomcat 側で接続が終了するでしょう。
 +
: 以下の設定もまた有用です。
 +
:    testOnBorrow (default false, set to true)
 +
:    validationQuery (default none, set to 'SELECT version();' no quotes)
 +
: これは、アプリケーションに終了した接続を提供することなく、その接続が待機中で終了すべき接続であるかを確認するのに有効でしょう。
 +
</blockquote>
  
−
== pgpoolAdmin Frequently Asked Questions ==
+
== pgpoolAdmin FAQ ==
  
−
=== '''pgpoolAdmin does not show any node in pgpool status and node status. Why?''' ===
+
=== '''pgpoolAdmin の pgpol status と node status にノード情報がありません。なぜですか？''' ===
−
: pgpoolAdmin uses PHP's PostgreSQL extention (pg_connect and pg_query etc.). Probably the extention does not work as expected. Please check apache error log. Also please check the FAQ item below.
+
: pgpoolAdmin は PHP の PostgreSQL エクステンション（pg_connect、pg_query など）を使います。おそらくエクステンションが期待通りに動作していません。apache のエラーログを確認してください。以下の FAQ も確認してください。
  
−
=== '''Why does node status in pgpoolAdmin show "down" status even if PostgreSQL is up and running?''' ===
+
=== '''PostgreSQL が稼働中であるにもかかわらず、 pgpoolAdmin の node status が "down" ステータスを示しているのはなぜですか？''' ===
−
: pgpoolAdmin checks PostgreSQL status by connecting with user = "health_check_user" and database = template1. Thus you should allow pgpoolAdmin to access PostgreSQL with those user and database without password. You can check PostgreSQL log to verify this. If health_check_user does not exist, you will see something like:
+
: pgpoolAdminは PostgreSQL のステータスを ユーザ = "health_check_user"、データベース = template1 と指定して接続することで監視しています。したがって、pgpoolAdmin が指定のユーザとデータベースにパスワードなしで PostgreSQL にアクセスできるようにする必要があります。PostgreSQL のログでこれを検証することができます。health_check_user が存在しないと以下のようなログが確認できます。:
 
: <pre>20148 2011-07-06 16:41:59 JST FATAL:  role "foo" does not exist</pre>
 
: <pre>20148 2011-07-06 16:41:59 JST FATAL:  role "foo" does not exist</pre>
 
: If the user is protected by password, you will see:
 
: If the user is protected by password, you will see:

2013年12月9日 (月) 10:56時点における版


目次

Pgpool-II FAQ

私の Ubuntu box では "pg_config not found" と設定に失敗するのはなぜですか？

pg_config は libpq-dev パッケージに含まれています。設定の前に libpq-dev パッケージをインストールする必要があります。

プライマリノードにインサートしたレコードがスタンバイノードで表示されないのはなぜですか？

ストリーミングレプリケーションと、テーブルにハッシュインデックスを使っていませんか？それらはストリーミングレプリケーションの制限として知られています。インサートされたレコードはそこにあります。しかし、ハッシュインデックスを使ってそのレコードを参照すると、表示されません。ハッシュインデックスの変更は WAL レコードを作成しないので、スタンバイノードに反映されません。解決方法は、 1) 代わりに btree インデックスを使うか、 2) pgpool-II のレプリケーションモードを使うかです。

pgpool-II のバックエンドサーバとしてバージョンの異なる PostgreSQL を混在させることはできますか？

メジャーバージョンの異なる PostgreSQL（たとえば、8.4.x と 9.0.x）を混在させることはできませんが、 マイナーバージョンの異なる PostgreSQL（たとえば 9.0.3 と 9.0.4）を混在させることはできます。Pgpool-II は PostgreSQL から pgpool-II へ送信されるメッセージは常に同一であることを想定しています。メジャーバージョンが異なる PostgreSQL は異なるメッセージを送信する可能性があり、これは pgpool-II に問題を引き起こす可能性があります。

たとえば、Linux と Windows といったように、pgpool-II のバックエンドサーバとして PostgreSQL のプラットフォームを混在させることはできますか？

ストリーミングレプリケーションモードの場合は、できません。ストリーミングレプリケーションは、プライマリとスタンバイのプラットフォームが物理的に同一である必要があるからです。その一方で、pgpool-II の レプリケーションモードは論理的にデータベースクラスタが同一であることしか必要でありません。しかしながら、 オンラインリカバリのスクリプトは rsync やデータベースクラスタを含めた物理的なコピーといったようなことに使えない点に注意してください。代わりに pg_dumall を使ってください。

pgpool-II がロードバランスを行っていないようですが、なぜですか？

まずはじめに、 pgpool-II のロードバランスは "セッションベース" であり "ステートメントベース" ではありません。これはつまり、 ロードバランス用の DB ノードの選択は、セッションの開始時に決定されることを意味しています。したがって、全ての SQL ステートメントは、セッションが終了するまで、同じ DB ノードに送信されます。
他の注意点は、ステートメントが明示的なトランザクションであるかそうでないかということです。ステートメントがトランザクション内であった場合、レプリケーションモードのステートメントはロードバランスされないでしょう。 pgpool-II 3.0 かそれ以降であれば、マスタースレーブモード時の SELECT 文はトランザクション内であってもロードバランスされるでしょう。
DB ノードの選択方法は LRU といったような方式ではないことに留意してください。Pgpool-II は、pgpool.conf の "weight" パラメータによって無作為に DB ノードを選択します。これはつまり、選択された DB ノードは短期的には他の DB ノードに一様に分散されないことを意味しています。 100 クエリが送信されたあとで、ロードバランスの効果を検査してください。
レプリケーションモードでは、カーソル宣言もロードバランスされません。つまり、レプリケーションモードでは、 "DECLARE..FETCH" は全ての DB ノードに送信されます。これは、SELECT 文には "FOR UPDATE/FOR SHARE" が付属する場合があるからです。psql を含んでいるいくつかのアプリケーションは SELECT 文でカーソルが使えるということに留意してください。例えば、PostgreSQL 8.2からは、"\set FETCH_COUNT n" が実行された場合、psql は無条件に "_psql_cursor" と名付けられたカーソルを使用します。

ロードバランスの効果を確認するにはどうすればよいですか？

pgpool.conf の "log_per_node_statement" ディレクティブを有効にしてください。以下はログの一例です:
2011-05-07 08:42:42 LOG:   pid 22382: DB node id: 1 backend pid: 22409 statement: SELECT abalance FROM pgbench_accounts WHERE aid = 62797;
"DB node id: 1" はどの DB ノードがこのロードバランシングセッションで選択されたかを示しています。
pgpool-II のログを取得したい場合は、必ず pgpool-II に "-n" オプションを指定して起動してください（あるいは、pgpool-II 3.1 かそれ以降であれば、syslog を使うこともできます）。

pgpool の ログで "ProcessFrontendResponse: failed to read kind from frontend. frontend abnormally exited" を受け取るのはなぜですか？

ええと、おそらくクライアントが行儀の悪い振る舞いをしているのでしょう:-) PostgreSQL のプロトコルは、クライアントが接続を終了する際に特定のパケットを送信することを要求します。pgpool-II は クライアントがパケットを送信せずに切断したことを訴えています。これは psql を使って再現可能です。psql で pgpool に接続してください。Kill -9 で psql を終了してください。似たようなログが出力されるでしょう。このメッセージは、正常に psql を終了した場合は表示されないでしょう。その他の可能性はクライアントマシーンと pgpool-II 間の不安定なネットワーク接続です。ケーブルと NIC を確認してみてください。

ストリーミングレプリケーションモードで pgpool-II を実行しています。動作しているようですが、以下のエラーがログにありました。なぜですか？

2011-07-19 08:21:59 ERROR: pid 10727: s_do_auth: unknown response "E" before processing BackendKeyData
2011-07-19 08:21:59 ERROR: pid 10727: s_do_auth: unknown response "" before processing BackendKeyData
2011-07-19 08:21:59 ERROR: pid 10727: s_do_auth: unknown response "" before processing BackendKeyData
2011-07-19 08:21:59 ERROR: pid 10727: s_do_auth: unknown response "" before processing BackendKeyData
2011-07-19 08:21:59 ERROR: pid 10727: s_do_auth: unknown response "[" before processing BackendKeyData
2011-07-19 08:21:59 ERROR: pid 10727: pool_read2: EOF encountered with backend
2011-07-19 08:21:59 ERROR: pid 10727: make_persistent_db_connection: s_do_auth failed
2011-07-19 08:21:59 ERROR: pid 10727: find_primary_node: make_persistent_connection failed
pgpool-II は PostgreSQL に接続して pg_current_xlog_location() などの関数を実行します。これらはプライマリサーバの検出やレプリケーションの遅延を確認するために使われます。上記のメッセージは user と health_check_user が同一で、password と health_check_password が同一の状態で pgpool-II が接続に失敗したことを示しています。health_check_period が 0 であったとしても、これらのパラメータは適切に設定してください。
pgpool-II 3.1 かそれ以降であれば sr_check_user と sr_check_password が代わりに使えることを留意してください。

pgpool-II の検証のために pgbench を実行したら、pgbench がハングしました。PostgreSQL に対して直接 pgbench を実行したらうまくいきました。なぜですか？

pgbench は実際のトランザクションを実行する前に同時接続（"-c" オプションで指定される接続数）を行います。したがって、"-c" で指定された同時接続数が num_init_children を超えた場合、pgbench は pgpool の接続許可を永久に待ち続けるために固まってしまうでしょう（pgpool-II は最大 num_init_children までの同時セッションを受け付けることを忘れないでください。同時セッション数が num_init_children に到達した場合、新しいセッションがキューされます）。その一方で、PostgreSQL は同時セッションを max_connections 以上受け付けません。したがって、この場合は接続をブロックするよりも、PostgreSQL のログを確認してみてください。pgpool-II の接続要求のキューイングを検証したい場合は、pgbench の代わりに psql が使えます。以下の例では、 num_init_children = 1 としています（これは実際には推奨される設定ではありません。単純化しています）。
$ psql test <-- connect to pgpool from terminal #1
psql (9.1.1)
Type "help" for help.
test=# 
$ psql test <-- tries to connect to pgpool from terminal #2 but it is blocked.
test=# SELECT 1; <--- do something from terminal #1 psql
test=# \q <-- quit psql session on terminal #1
psql (9.1.1) <-- now psql on terminal #2 accepts session
Type "help" for help.
test=#

pgpool-II を通して md5 認証ができるように pool_hba.conf と pool_passwd を設定しましたが、 うまく動作しません。なぜですか？

おそらく、どこかを間違えています。参考として pg_hba.conf、pool_hba.conf、pool_passwd 設定時のエラーパターンを表にしておきます。
pg_hba.conf pool_hba.conf pool_passwd result
md5 md5 yes md5 auth
md5 md5 no "MD5" authentication with pgpool failed for user "XX"
md5 trust yes/no MD5 authentication is unsupported in replication, master-slave and parallel mode
trust md5 yes no auth
trust md5 no "MD5" authentication with pgpool failed for user "XX"
trust trust yes/no no auth

pgpool-II の SSL 設定はどうすればよいですか？

pgpool-II の SSL サポートは 2 つのパートからなっています: 1) クライアントと pgpool-II 間、 2) pgpool-II と PostgreSQL 間です。#1 と #2 は互いに独立しています。たとえば、#1 か #2 のどちらかだけ SSL 接続を有効にできます。あるいは、#1 と #2 のどちらも有効にできます。#1 について説明します（#2 については、PostgreSQL のドキュメントを確認してください)。
pgpool が openssl を有効にした状態でビルドされていることを確認してください。ソースコードからビルドする場合、--with-openssl オプションを使ってください。
はじめにサーバ証明証を作成します。以下のコマンドで、PEM パスフレーズ（pgpool 起動時に要求されます）を要求されます。
パスフレーズの要求なしに pgpool を起動したい場合は、あとで削除することも可能です(sample server certficate create session)。
openssl req -new -text -out server.req
必要であれば、 PEM パスフレーズを削除してください。
$ openssl rsa -in privkey.pem -out server.key
Enter pass phrase for privkey.pem:
writing RSA key
$ rm privkey.pem
証明書を自己署名証明書に変更してください。
$ openssl req -x509 -in server.req -text -key server.key -out server.crt
server.key と server.crt を適切な場所にコピーしてください。ここでは /usr/local/etc にコピーしたことにします。server.key の適切なパーミッションを維持するために、 cp -p を必ず使ってください。あるいは、パーミッションを後で設定してください。
$ chmod og-rwx /usr/local/etc/server.key
証明書と鍵の位置を pgpool.conf で設定してください。
ssl = on
ssl_key = '/usr/local/etc/server.key'
ssl_cert = '/usr/local/etc/server.crt'
pgpool を再起動してください。クライアントと pgpool 間の SSL 接続が動作しているか確認するために psql で pgpool に接続してください。
psql -h localhost -p 9999 test
psql (9.1.1)
SSL connection (cipher: AES256-SHA, bits: 256)
Type "help" for help.

test=# \q
"SSL connection..." と表示されていたら、クライアントと pgpool 間の SSL 接続は動作しています。"-h localhost" オプションを必ず使用してください。SSL は TCP/IP でのみ動作し、Unix ドメインソケットでは動作しないからです。

レプリケーションモードで pgpool-II を使っています。 pgpool-II が INSERT クエリ内の current_timestamp を呼び出し時の同一時刻に置き換えること期待しましたが、置き換えられませんでした。なぜですか？

おそらく、INSERT クエリが（public.mytable のような）スキーマが修飾されたテーブル名を使っており、 pool_regclass 関数を pgpool にインストールしていないのでしょう。pgpool_reglclass がないと pgpool-II はスキーマ修飾を除いたテーブル名のみを扱います。

max_connection が not max_connection >= num_init_children でなく、max_connection >= (num_init_children * max_pool) を満たしていなければならないのはなぜですか？

おそらく、pgpool がこれらの値をどのように使うのかを理解する必要があります。以下は、pgpool の内部処理です。
  1. クライアントからの接続要求を待ちます。
  2. pgpool 子プロセスがクライアントからの接続要求を受けます。
  3. 最大 max_pool の、接続要求されたデータベースとユーザのペアを保持しているコネクションプールから、pgpool 子プロセスは存在している接続を探します。
  4. 見つかれば、それを再利用します。
  5. 見つからなければ、PostgreSQL への新しい接続を開き、それをコネクションプールへ登録します。コネクションプールに空きスロットがなければ、最も古い接続を終了し、そのスロットを再利用します。
  6. クライアントがセッションの終了要求を送るまで、クエリ処理を行います。
  7. クライアントの接続を終了しますが、将来の利用のために PostgreSQL への接続は維持します。
  8. #1 に戻ります。

コネクションプールキャッシュは pgpool プロセス内で共有していますか？

いいえ、コネクションプールキャッシュは pgpool のプライベートメモリ内に存在しており、他の pgpool と共有されていません。コネクションキャッシュの管理方法は次の通りです: pgpool プロセス 12345 がデータベース A/ユーザ B のコネクションキャッシュを持っており、プロセス 12346 はデータベース A/ユーザ B のコネクションキャッシュを持っておらず、どちらのプロセスもアイドル状態（この時点ではクライアントが接続していない）と仮定します。クライアントがデータベース A/ユーザ Bで、 プロセス 12345 の pgpool に接続する場合、存在している 12345 のコネクションが再利用されます。その一方で、クライアントが プロセス 1236 の　pgpool に接続する場合、12346 は新しい接続を作成する必要があります。12345 か 12346 のどちらが選択されるかを、pgpool はコントロールしていません。しかしながら、長期的には各 pgpool 子プロセスが同等に選択され、各プロセスのコネクションプールは同等に再利用されるでしょう。

SELECT 文がキャッシュされないのはなぜですか？

iBatis, MyBatis といったいくつかのライブラリは、明示的にコミットしない場合、常にトランザクションをロールバックします。不整合を起こす可能性があるので、pgpool はロールバックされたトランザクションの SELECT 文の結果は決してキャッシュしません。

pool_passwd に # コメントや空行は使えますか？

答えはシンプルです。使えません（/etc/passwd と同じようなものです）。

-n オプションを指定せずに pgpool を起動すると MD5 認証が使えません。なぜですか？

-f オプションで相対パスを指定しなければなりません: i.e. "-f pgpool.conf" もしくは、フルパスを指定しなければなりません: i.e. "-f /usr/local/etc/pgpool.conf"。 pgpool は pgpool.conf パスから（MD5 認証に必要な）pool_passwd のフルパスを設定しようとします。しかしながら、-n オプションを指定せずに pgpool を起動すると、カレントディレクトリが "/" に変わってしまいます。そしてこれは、プロセスのデーモン化に必要です。結果として、 pgpool は "/pool_passwd" を開こうとして失敗してしまいます。

ストリーミングレプリケーションモード時にスタンバイサーバが故障状態になり、 PostgreSQL の "terminating connection due to conflict" というメッセージを確認しました。なぜですか？

以下のメッセージを含んでいるとしたら、プライマリサーバの vacuum がスタンバイサーバの SELECT 文で参照しようとした行を削除してしまった可能性があります。回避方法は、スタンバイサーバのpostgresql.conf に "hot_standby_feedback = on" を設定することです。
2013-04-07 19:38:10 UTC FATAL:  terminating connection due to conflict with recovery
2013-04-07 19:38:10 UTC DETAIL:  User query might have needed to see row versions that must be removed.
2013-04-07 19:38:10 UTC HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2013-04-07 19:38:10 UTC LOG:  could not send data to client: Connection reset by peer
2013-04-07 19:38:10 UTC ERROR:  canceling statement due to conflict with recovery
2013-04-07 19:38:10 UTC DETAIL:  User query might have needed to see row versions that must be removed.
2013-04-07 19:38:10 UTC LOG:  could not send data to client: Broken pipe
2013-04-07 19:38:10 UTC FATAL:  connection to client lost

pgpool-II が起動しているシステムのロードアベレージが 5 〜 10 程度に高くなります。なぜですか？

多数のユーザが Linux kernel 3.0. 2.6 か 3.2 のみで発生すると述べています。私達は、Linux Kernel 3.0 の問題ではないかと推測しています。 詳細なディスカッションは "[pgpool-general: 1528] Mysterious Load Spikes" を参照してください。

watchdog を有効にした状態で接続数が num_init_children に到達すると、VIP のスイッチオーバーが発生します。なぜですか？

接続数が num_init_children に到達すると、select 1 が失敗するので watchdog が失敗します。そのため、 VIP は他の pgpool へ移動します。残念ながら、通常のクライアントと watchdog の接続を区別する方法はありません。num_init_children と wd_life_point を増やし、ler wd_interval を減らすとこの問題をいくらか防ぐことができるかもしれません。
次のメジャーバージョンの pgpool-II 3.3 では、この問題を解決するために 'SELECT 1' のようなクエリの代わりに UDP のハートビートパケットを使った新しい監視方法をサポートします。

pgpool_regclass をインストールする必要があるのはなぜですか？

PostgreSQL 8.0 かそれ以降を使用している場合、pgpool-II がアクセスできるようにするために全ての PostgreSQL に pgpool_regclass 関数をインストールすることは強く推奨されており、実際に pgpool-II は内部でそれを利用しています。 pgpool_regclass 関数がないと、異なるスキーマの同じテーブル名を扱う場合に問題を引き起こす可能性があります（一時テーブルは問題ありません）。
関連のある FAQ はこちらです。 http://www.pgpool.net/mediawiki/index.php?title=FAQ&action=submit#I.27m_using_pgpool-II_in_replication_mode._I_expected_that_pgpool-II_replaces_current_timestamp_call_with_time_constants_in_my_INSERT_query.2C_but_actually_it_doesn.27t._Why.3F

md5 認証が動作しません。助けてください。

md5 認証セットアップのチェックポイントがとても良くまとめられたサマリがあります。そこを参照してください。
http://www.pgpool.net/pipermail/pgpool-general/2013-May/001773.html

Amazon AWS で pgpool/PostgreSQL を運用していると、時々ネットワークエラーになります。なぜですか？

AWS の既知の問題です。Amazon のサポートを利用することをお勧めします。

私の Ubuntu box では pcp コマンドが実行できません。なぜですか？

pcp コマンドは libpcp.so を必要とします。Ubuntu では "libpgpool0" パッケージに含まれています。

オンラインリカバリに失敗しました。どのようにデバッグすればよいですか？

pcp_recovery_node は recovery_1st_stage_command と recovery_2nd_stage_command の両方かどちらかを実行し、これは設定次第です。これらのスクリプトはマスターの PostgreSQL ノード（レプリケーションモード時の始めの稼働ノードか、ストリーミングレプリケーション時のプライマリノード）で実行されることになっています。"BackendError" は pgpool と PostgreSQL の両方かどちらか一方になにか問題が発生したことを意味します。これを検証するには、以下の手順をお勧めします。
  1. デバッグオプションを指定して pgpool を起動します。
  2. pcp_recovery_node を実行します。
  3. pgpool とマスターの PostgreSQL のログを確認します。

他のノードが稼働しているのに、Watchdog が起動しません。

仕様です。Watchdog の 生存監視は全ての pgpool の起動が完了した後で開始します。これまでは、 仮想 IP のフェイルオーバが全く発生しませんでした。

トランザクションを開始すると、pgool-II もスタンバイノードでトランザクションを開始します。なぜですか？

これは JDBC ドライバがカーソルを使いたい場合に必要な処置です。Pgpool-II はカーソル宣言を含めて SELECT 文をスタンバイノードへ自動的に割り振ります。残念ながら、カーソル宣言は明示的なトランザクション内で実行される必要があります。

スキーマが修飾されたテーブル名を使うと、pgpool-II がオンメモリクエリキャッシュを無効にしてくれず、古いデータを受け取ってしまいます。なぜですか？

"pgpool_regclass" 関数をインストールしていないのではないでしょうか。この関数がないと、pgpool-II はスキーマ修飾されたテーブル名のスキーマ名を無視し、キャッシュの無効化に失敗します。

定期的に "read_startup_packet: incorrect packet length" といったエラーメッセージを受け取ります。これは何を意味しているのですか？

Zabbix や Nagios を含んだ監視ツールは、定期的にパケットや ping を pgpool の待ち受けポートに送信します。残念ながらこれらのパケットは適切なコンテンツを有しておらず、pgpool はdラーを出してしまいます。このようなパケットを誰が送信しているか不明な場合、"log_connections" を有効にして送信元のホストとポートを確認することができます。送信元が監視ツールであれば、この問題を回避するために監視を停止するか、より良い手段として、監視方法を "SELECT 1" のような適切なクエリに変更してください。

数分おきに繰り返し Tomcat で "An I/O Error occurred while sending to the backend" といったエラーを受け取ります。なぜですか？

Tomcat は pgpool に持続的な接続を作成します。client_idle_limit を有効にしている場合、 pgpool はその接続を終了し、次の機会では Tomcat が pgpool に 何かを送信しようとした際にエラーメッセージを伴って送信内容は破棄されてしまいます。
解決方法は client_idle_limit を無効に設定することです。しかしながら、これは多くの接続のアイドル状態を放置してしまいます。
別の解決方法が、Lachezar Dobrevlution 氏によって提供されました:
Tomcat側 に time-out を設定すると解決できるかもしれません。 http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
（私が知る限りで）設定するパラメータは以下です。:
minIdle (default is 10, set to 0)
timeBetweenEvictionRunsMillis (default 5000)
minEvictableIdleTimeMillis (default 60000)
この設定は 5 秒ごとに監視を試み、接続が過去 60 秒間利用されていなければ、いかなる接続も終了します。両者の合計値を pgpool のクライアントのタイムアウト値よりも低くしていれば、pgpool 側のタイムアウトの前に、Tomcat 側で接続が終了するでしょう。
以下の設定もまた有用です。
testOnBorrow (default false, set to true)
validationQuery (default none, set to 'SELECT version();' no quotes)
これは、アプリケーションに終了した接続を提供することなく、その接続が待機中で終了すべき接続であるかを確認するのに有効でしょう。

pgpoolAdmin FAQ

pgpoolAdmin の pgpol status と node status にノード情報がありません。なぜですか？

pgpoolAdmin は PHP の PostgreSQL エクステンション（pg_connect、pg_query など）を使います。おそらくエクステンションが期待通りに動作していません。apache のエラーログを確認してください。以下の FAQ も確認してください。

PostgreSQL が稼働中であるにもかかわらず、 pgpoolAdmin の node status が "down" ステータスを示しているのはなぜですか？

pgpoolAdminは PostgreSQL のステータスを ユーザ = "health_check_user"、データベース = template1 と指定して接続することで監視しています。したがって、pgpoolAdmin が指定のユーザとデータベースにパスワードなしで PostgreSQL にアクセスできるようにする必要があります。PostgreSQL のログでこれを検証することができます。health_check_user が存在しないと以下のようなログが確認できます。:
20148 2011-07-06 16:41:59 JST FATAL:  role "foo" does not exist
If the user is protected by password, you will see:
20220 2011-07-06 16:42:16 JST FATAL:  password authentication failed for user "foo"
20221 2011-07-06 16:42:16 JST LOG:  could not receive data from client: Connection reset by peer
20221 2011-07-06 16:42:16 JST LOG:  unexpected EOF within message length word
20246 2011-07-06 16:42:26 JST LOG:  could not receive data from client: Connection reset by peer
20246 2011-07-06 16:42:26 JST LOG:  unexpected EOF within message length word
「https://pgpool.net/mediawiki/jp/index.php?title=FAQ&oldid=558」から取得