| Pgpool-II 4.4.10 文書 | |||
|---|---|---|---|
| 前のページ | 上に戻る | 第 5章サーバの設定 | 次のページ |
リレーションキャッシュの寿命を秒単位で指定します。 リレーションキャッシュは、Pgpool-IIがテーブルの構造を含む様々な情報を取得したり、テーブルのタイプ（たとえば、参照されているテーブルが一時テーブルかどうかなど）をチェックするために使うPostgreSQLのシステムカタログの問い合わせ結果を保存しておくものです。 キャッシュはpgpoolの子プロセスのローカルメモリ空間に保管されています。 enable_shared_relcacheが有効な場合、子プロセス間で共有するために共有メモリにも保管されます。 もしALTER TABLEでテーブルが変更された場合などは、リレーションキャッシュと一致しなくなります。 そのため、relcache_expireがキャッシュの寿命をコントロールしています。 デフォルトは0で、キャッシュの期限が切れることはありません。
このパラメータは、サーバ起動時にのみ設定できます。
リレーションキャッシュのエントリ数を指定します。 デフォルトは256です。 リレーションキャッシュは、一つのテーブルあたり最大10個程度のエントリが作成されます。 そのため、必要なリレーションキャッシュのサイズは、使用するテーブル数 * 10 で見積れます。
注意: もし以下のようなメッセージがPgpool-IIログに頻繁に出る場合は、パフォーマンス向上のためrelcache_sizeを大きくしてください。
"pool_search_relcache: cache replacement occurred"
このパラメータは、サーバ起動時にのみ設定できます。
onにするとインメモリクエリキャッシュ(項5.13.1参照)を利用して子プロセス間でリレーションキャッシュを共有します。 デフォルトはonです。 それぞれの子プロセスはPostgreSQLのシステムカタログを参照するためにクエリを実行します。 この機能を有効にすると、他のプロセスはクエリキャッシュからカタログを参照した結果を得ることができるので、クエリの実行頻度が減ることが期待できます。 システムカタログが変更されてもキャッシュは削除されません。 ですから時間によるキャッシュの削除をrelcache_expireを使って行うことを強くお勧めします。
本パラメータは、memory_cache_enabledがoffの場合も有効です。 この場合、一部のクエリキャッシュのパラメータ（memqcache_methodとmemqcache_maxcache、および各キャッシュストレージ用のパラメータ）も有効になります。
このパラメータがonなら、Pgpool-IIはローカルのリレーションキャッシュをまず検索します。 該当するキャッシュエントリが見つからない場合は、次に共有クエリキャッシュを検索します。 もしクエリキャッシュに該当エントリが見つかったら、ローカルキャッシュにコピーします。 見つからなかった場合には、PostgreSQLにクエリを発行して問い合わせを実行し、結果をクエリキャッシュに登録するとともに、ローカルキャッシュにも登録します。
このパラメータはサーバ起動時にのみ設定可能です
リレーションキャッシュを作成するためのクエリを送る先のノードを指定します。 primaryにすると、クエリはメイン（プライマリ）に送られます。 これがデフォルトで、最新のデータを入手できるため、ほとんどのユーザに推奨する設定です。 もしメイン（プライマリ）の負荷を下げたい場合は、このパラメータをload_balance_nodeに設定できます。 これにより、クエリは負荷分散ノードに送られます。 これは特に、大陸AにPgpool-IIとプライマリサーバがあり、一方大陸BにPgpool-IIとスタンバイサーバがあるような構成で有効です。 Bのユーザは地理的にスタンバイサーバが近いため、スタンバイからデータを読みたいと思うでしょう。 その場合は、backend_weight0 (これはプライマリの設定です)を0に、backend_weight1(これはスタンバイの設定です)を1にし、relcache_query_targetをload_balance_nodeにします。
しかし、スタンバイにクエリを送る場合、レプリケーションの遅延により、最近作られたテーブルや行はスタンバイサーバにはまだないかもしれないことに注意してください。 ですから、更新頻度の高いシステムではこの設定はおすすめできません。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
catalogあるいはtraceに設定されたとき、SELECTに含まれるテーブルが一時テーブルかどうかのチェックを行います。 catalogに設定すると一時テーブルをチェックするためPgpool-IIはプライマリ/メインPostgreSQLバックエンドのシステムカタログに問い合わせ、プライマリ/マスタサーバの負荷を上げます。
traceに設定されていると、一時テーブルの情報を入手するためにPgpool-IIは一時テーブルの作成と削除を追跡します。 ですからシステムカタログへアクセする必要がありません。 しかし、一時テーブルの生成がPgpool-IIから見えない場合（たとえば関数やトリガの中で行われる場合）、Pgpool-IIは一時テーブルの生成を認識できません。
もしシステムが決して一時テーブルを使用しないことが確かならば、安全にcheck_tmp_tableをnoneにすることができます。
注意: 4.0以前のバージョンとの互換性のために、catalogと同じ意味のon、noneと同じ意味のoffも受け付けますが、将来のバージョンではこれらは削除されるかもしれません。
デフォルトはcatalogです。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。 現在のセッションでのパラメータ値は、PGPOOL SETコマンドで変更することもできます。
onに設定されたとき、SELECTに含まれるテーブルがunloggedテーブルかどうかのチェックを行います。 unloggedテーブルをチェックするためPgpool-IIはプライマリ/メインPostgreSQLバックエンドのシステムカタログに問い合わせ、プライマリ/マスタサーバの負荷を上げます。 もしシステムが決してunloggedテーブルを使用しないことが確かならば（たとえば、9.0 以前のバージョンのPostgreSQLを使っている）、安全にcheck_unlogged_tableをoffにすることができます。 デフォルトはonです。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。 現在のセッションでのパラメータ値は、PGPOOL SETコマンドで変更することもできます。
Pgpool-IIのプロセスIDを格納するファイルのフルパスを指定します。 デフォルトは'/var/run/pgpool/pgpool.pid'です。
このパラメータは、サーバ起動時にのみ設定できます。
pgpool_statusファイルを格納するディレクトリのフルパスを指定します。 デフォルトは'/tmp'です。
このパラメータは、サーバ起動時にのみ設定できます。
| 注意 |
実運用のシステムでこのパラメータをonにしないでください。 この機能はテスト目的専用です。 |
onにすると、ヘルスチェックのテスト機能が有効になります。 この場合、ヘルスチェックプロセスはlogdirの下にあるbackend_down_requestを参照します。 このファイルは、複数の行から構成され、各行は各々のバックエンドに対応します。 各行はバックエンドID（ゼロから始まる十進数でなければなりません）で始まり、続いてタブ、最後に"down"で終わります。 そのバックエンドはダウン状態と見なされ、Pgpool-IIはフェイルオーバを開始します。 フェイルオーバが完了すると、"down"はヘルスチェックプロセスによって"already_down"に書き換えられ、何度もフェイルオーバが起きることを防ぎます。
この機能は特にfailover_require_consensusのテストに有用です。 今3つのwatchdogノードがあるとします。 各々のwatchdogはバックエンド0の健全性を検証します。 "0 down"とwatchdog 0の配下のファイルのみに書き込むと、他のバックエンドはバックエンド0が健全ではないことに同意しないので、フェイルオーバは起きません。 このような、部分的なネットワーク障害がこの機能でシミュレーションできます。
デフォルトはoffです。
このパラメータは、サーバ起動時にのみ設定できます。