| Pgpool-II 4.0.6 文書 | |||
|---|---|---|---|
| 前のページ | 上に戻る | 第 5章サーバの設定 | 次のページ |
Pgpool-IIのSELECTクエリの負荷分散はマスタースレーブモード（項5.3.1）とレプリケーションモード（項5.3.2）で動作します。 有効時、Pgpool-IIは更新を伴うクエリを、マスタースレーブモードではプライマリノードに、レプリケーションモードでは全てのバックエンドノードに対し送信します。 そして、その他のクエリは全てのバックエンドの間で負荷分散されます。 負荷分散メカニズムが参照クエリをどのノードに送信するかはセッション開始時に決められ、セッションの終了まで変更されません。 ただし、いくつかの例外があります。 詳細については以下をご覧ください。
注意: 負荷分散ができないためにプライマリノードまたは全バックエンドノードに送られるクエリもまた、 負荷分散アルゴリズムの考慮に入れられます。
注意: もし負荷分散対象のクエリをPgpool-IIに負荷分散してほしくない場合には、SELECT文の前の/*NO LOAD BALANCE*/コメントを付与することができます。 これにより、そのクエリの負荷分散は無効となり、Pgpool-IIはこれをマスターノード（マスタースレーブモードではプライマリノード）に送信します。
注意: どのDBノードが負荷分散ノードになっているかは、SHOW POOL_NODESを利用して確認できます。
クエリが負荷分散されるためには、以下の全ての条件を満たす必要があります：
PostgreSQLのバージョンが7.4以降である
レプリケーションモードまたはマスタースレーブモードである
問い合わせが明示的なトランクザションブロックの内側にない(つまり、BEGINを発行していない)
ただし、以下の条件が満たされればトランザクションブロックの内側であっても負荷分散の対象となります。
トランザクション分離レベルがSERIALIZABLEでない
トランザクション内で更新を伴うクエリが実行されていない (更新を伴うクエリが実行されるまでは負荷分散されます。 ここで「更新を伴うクエリ」とは、SELECT以外のDDLやDMLを指します。 black/white function listで指定される更新関数を含むSELECTは更新を伴うクエリとは見なされません。 この仕様は将来変更される可能性があります)
もしblack/white function listが空の場合は、関数を持つSELECTは、更新を伴うクエリとは見なされません。
SELECT INTO 文ではない
SELECT FOR UPDATE/SELECT FOR SHARE文ではない
SELECT または COPY TO STDOUT, EXPLAIN, EXPLAIN ANALYZE SELECT... から始まる。 (black_function_listまたはwhite_function_listで指定された書き込み関数を含むSELECTを除く) ignore_leading_white_space = trueの場合は最初の空白文字は無視されます。
マスタースレーブモードの場合、更に以下の条件が満たされなければなりません。
一時テーブルを使っていない
unloggedテーブルを使っていない
システムカタログを使っていない
注意: SELECTクエリの前に任意のコメントを挿入することにより負荷分散を抑制することができます。
/*REPLICATION*/ SELECT ...SQLコメントの記述が負荷分散に影響を与えないようにするには、allow_sql_commentsをonにします。 replicate_selectも参照してください。
注意: JDBC ドライバにはautocommitオプションがあります。 autocommit を無効にすると、ドライバが内部でBEGINおよびCOMMITコマンドを実行し、明示的なトランザクションが開始されます。 この場合、トランザクション内における上記の負荷分散の制限事項が適用されます。
一般的には、特定の条件を満している場合、参照クエリは負荷分散します。 ただし、更新を伴うクエリは負荷分散に影響する可能性があります。 ここで、”更新を伴うクエリ”とは以下の例を除く全てのクエリを指します。
FOR UPDATE/SHARE がないSELECT/WITH
COPY TO STDOUT
EXPLAIN
EXPLAIN ANALYZEおよびクエリが書き込み関数を含まないSELECT
SHOW
更新を伴うクエリが存在する場合、続いて実行される参照クエリは負荷分散しません。 すなわち、disable_load_balance_on_writeの設定に応じて（ストリーミングレプリケーションの）プライマリノードまたは（その他のモードの）マスターノードに送ります。
ストリーミングレプリケーションとHot Standbyを利用している環境では、プライマリノードに送ってよい問い合わせ、スタンバイに送ってもよい問い合わせ、両方に送らなければならない問い合わせを厳密に管理する必要があります。 Pgpool-IIのストリーミングレプリケーションモードは、こうした振り分けを自動的に行ないます。
クエリそのものから、どのクエリがどのノードに送られるべきかを区別します。
プライマリノードにしか送られない問い合わせ
INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE, CREATE, DROP, ALTER, COMMENT
SELECT ... FOR SHARE | UPDATE
トランザクションの分離レベルがSERIALIZABLEの場合のSELECT
ROW EXCLUSIVE MODEよりも強いLOCK
DECLARE, FETCH, CLOSE
SHOW
トランザクションコマンドの一部
BEGIN READ WRITE, START TRANSACTION READ WRITE
SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE
SET transaction_read_only = off
二相コミット関連のコマンド。PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED
LISTEN, UNLISTEN, NOTIFY
VACUUM
シーケンス関連の関数(nextvalやsetvalなど)の呼び出し
ラージオブジェクトの生成
マルチステートメントSQL(1行の中に複数のSQLが含まれている)
プライマリノードとスタンバイノードのどちらにも送ることのできる問い合わせ。 負荷分散設定が有効ならば、スタンバイノードにも送信されます。 レプリケーションの遅延がdelay_thresholdを上回っている場合は問い合わせはプライマリノードに送られます。
SELECT (上記以外)
COPY TO
プライマリノードとスタンバイノードのどちらにも送られる問い合わせ
SET
DISCARD
DEALLOCATE ALL
明示的なトランザクションでは、以下のようになります。
BEGINなどのトランザクション開始コマンドは、プライマリノードとスタンバイノードの両方に送られます。
続くSELECTなど、プライマリ/スタンバイのどちらにも送ることのできる問い合わせは、プライマリのトランザクション内でそのまま実行されるか、スタンバイノードで実行されます。
INSERTなど、スタンバイに送ることのできない問い合わせが現われた場合はプライマリに送られます。 そういったコマンドの後は、SELECTであってもプライマリノードに送られます。 これは、INSERTなどの問い合わせの結果を SELECTが直ちに参照できるようにするためです。 この状態は、トランザクションが閉じるか、アボートするまで続きます。
問い合わせが、拡張問い合わせモードで実行される場合は、問い合わせのparse段階で、問い合わせがスタンバイに送信可能かが決まります。 その際の判断ルールは通常のSQLと同じです。 たとえば問い合わせがINSERTならば、プライマリノードに送られます。 それに後に続くbind, describe, executeも同じくプライマリに送られます。
注意: 負荷分散によりSELECT文のparseがスタンバイノードに送信され、その後INSERTなどのDML文がPgpool-IIに送られた場合、parse済のSELECTはプライマリノードで実行されなければなりません。 そのため、同じSELECTがプライマリノードで再度パースされることになります。
最後に、pgpool-IIのパーサが構文エラーと判断した問い合わせはプライマリノードだけに送られます。
onに設定すると、Pgpool-IIは入ってきたSELECTクエリに対する負荷分散を有効にします。 すなわち、クライアントからのSELECTクエリは設定されたPostgreSQLバックエンドに振り分けます。 デフォルトはoffです。
このパラメータはサーバ起動時にのみ設定可能です。
onに設定すると、負荷分散の際にSQL文行頭の空白を無視します(全角スペースは無視されません)。 これは、DBI/DBD:Pgのように、ユーザの意図に反してに空白を追加するようなAPIを使っているときに有用です。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
データベースに対して更新を行なわない関数名をコンマ区切りで指定します。 このリストに指定されていない関数呼び出しを含むSELECTは負荷分散されません。 これらのクエリはレプリケーションモードにおいてはすべてのDBノードで複製され、マスタースレーブモードにおいてはプライマリノードにのみ送信されます。
関数名のマッチングに正規表現を使うことができます。 正規表現には自動的に^と$が付与されます。
例 5-2. 正規表現の使用
もし読み出しのみを行う関数が"get_"あるいは"select_"で始まるようにしてあるのであれば、white_function_listを以下のように設定可能です。
white_function_list = 'get_.*,select_.*'
注意: Pgpool-IIはリストを参照する際に、暗黙のうちに入力SQLの関数名からスキーマ修飾部分を削除するため、white_function_listでスキーマ修飾を使えません。 その結果、リスト中のスキーマ修飾された関数名は、決して入力SQLの関数と一致しません。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
データベースに対して更新を行う関数名をコンマ区切りで指定します。 このリストに指定された関数呼び出しを含むSELECTは負荷分散されません。 これらのクエリはレプリケーションモードにおいてはすべてのDBノードで複製され、マスタースレーブモードにおいてはプライマリノードにのみ送信されます。
関数名のマッチングに正規表現を使うことができます。 正規表現には自動的に^と$が付与されます。
例 5-3. 正規表現の使用
もし更新を行う関数が"set_"、"update_"、"delete_"、あるいは"insert_"で始まるようにしてあるのであれば、black_function_listを以下のように設定可能です。
black_function_list = 'nextval,setval,set_.*,update_.*,delete_.*,insert_.*'
注意: Pgpool-IIはリストを参照する際に、暗黙のうちに入力SQLの関数名からスキーマ修飾部分を削除するため、black_function_listでスキーマ修飾を使えません。 その結果、リスト中のスキーマ修飾された関数名は、決して入力SQLの関数と一致しません。
注意: black_function_listとwhite_function_listは互いに排他的で、２つのリストの内、どちらか一方のみ設定することができます。
例 5-4. nextval()とsetval()を適切なバックエンドに送る設定
Pgpool-II V3.0より前のバージョンでは、固定でnextval()とsetval()がデータベースに書き込みを行なう関数であると認識されていました。 以下のようにwhite_function_listとblack_function_listを設定することで、それと同じように動作させることができます。
white_function_list = ''
black_function_list = 'nextval,setval,lastval,currval'
注意: PostgreSQLにはnextval()とsetval()に加え、lastval()とcurrval()があります。 lastval()とcurrval()は書き込みを行う関数ではありませんが、これらの関数が負荷分散されることで発生するエラーを防ぐため、lastval()とcurrval()を書き込みを行う関数として扱うのが望ましいです。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
特定の SQL をプライマリノードに送信するように black_query_pattern_listを設定します。 SQL パターンをセミコロン区切りで指定します。 マスタースレーブモードのみで動作します。
SQL のマッチングに正規表現を使うことができます。 正規表現には自動的に^と$が付与されます。 "'"、";" あるいは "*" などの文字を SQL パターンの中で利用する場合、"\" でエスケープする必要があります。 SQL パターンの中で正規表現の特殊文字を使用する場合、"\" でエスケープする必要があります。 例えば、"'"、";"、"*"、"("、")"、"|"、"+"、"."、"\"、"?"、"^"、"$"、"{","}"、"{"、"}" などの特殊文字の場合、"\" でエスケープする必要があります。 また、指定される SQL パターンでは大文字と小文字を区別しません。
例 5-5. 正規表現の使用
もし以下の SQL をプライマリノードに送信したい場合、black_query_pattern_listを以下のように設定可能です。
SELECT * FROM table_name1;
SELECT col1, col2 FROM table_name2 WHERE col1 LIKE '%a%';
table_name3 という文字列を含む SQL
black_query_pattern_list = 'SELECT \* FROM table_name1\;;SELECT col1, col2 FROM table_name2 WHERE col1 LIKE \'%a%\'\;;.*table_name3.*'
注意: black_query_pattern_listとwhite_function_listの両方にマッチした場合、 white_function_listの設定が無視され、プライマリノードのみに送信されます。
SQL のパターンにもよりますが、この機能を使用する場合、パフォーマンスが 1-2％ 低下する可能性があります。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
特定のデータベース接続でSELECTクエリが指定したロードバランス比率で特定のバックエンドノードに送信されるように、"データベース名:ノードID(比率)"ペアのリストを指定します。ロードバランス比率は0-1の間の値を指定します。 比率の指定を省略した場合は、デフォルトの1.0となります。
たとえば"test:1(0.5)"とした場合、"test"データベースへの接続においては、Pgpool-IIは50%のSELECTクエリをIDが1のバックエンドノードに送信します。 複数の"データベース名:ノードID"のペアを カンマ(,)で区切って指定することができます。
データベース名には正規表現を指定することができます。 ノードIDには特別なキーワードを使うことができます。 "primary"が指定された場合にはクエリはプライマリノードに送られます。 また、"standby"が指定された場合はスタンバイノードのうちどれかをウェイト(backend_weight)に応じてランダムに選択します。
例 5-6. database_redirect_preference_listの利用
SELECTクエリのルーティングルールを以下のように設定したい場合：
全てのpostgresデータベースにおけるSELECTクエリはプライマリバックエンドノードに送る。
全てのmydb0またはmydb1データベースにおける30%のSELECTクエリはIDが1のバックエンドノードに送る。
全てのmydb2データベースにおけるSELECTクエリはスタンバイバックエンドノードに送る。
database_redirect_preference_listは以下のように設定します。
database_redirect_preference_list = 'postgres:primary,mydb[01]:1(0.3),mydb2:standby'
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
特定のクライアントアプリケーションの接続でSELECTクエリが指定したロードバランス比率で特定のバックエンドノードに送信されるように、"アプリケーション名:ノードID(比率)"ペアのリストを指定します。
注意: 「アプリケーション名」とはクライアントがデータベースに接続する時に指定する名称で、PostgreSQL V9.0以降で利用可能です。
たとえば、psqlコマンドのアプリケーション名は"psql"です。
注意: Pgpool-IIは、クライアントから送信されたスタートアップパケットに含まれるアプリケーション名だけを認識します。 クライアントは事後にセッションの中でアプリケーション名を指定できますが、それはPgpool-IIのクエリルーティングでは考慮されません。
app_name_redirect_preference_listの記法はdatabase_redirect_preference_listと同じですので、アプリケーション名には正規表現も使用できます。 同様に特別なキーワード"primary"はプライマリノードを、"standby"はスタンバイサーバのいずれかを意味します。 ロードバランス比率は0-1の間の値を指定します。ロードバランス比率の指定を省略した場合は、デフォルトの1.0となります。
例 5-7. app_name_redirect_preference_listの利用
SELECTクエリのルーティングルールを以下のように設定したい場合：
全てのpsqlクライアントからのSELECTクエリはプライマリバックエンドノードに送る。
全てのmyapp1クライアントからの30%のSELECTクエリはIDが1のバックエンドノードに送る。
全てのmyapp2クライアントからのSELECTクエリはスタンバイバックエンドノードに送る。
app_name_redirect_preference_listは以下のように設定します。
app_name_redirect_preference_list = 'psql:primary,myapp1:1(0.3),myapp2:standby'
注意: app_name_redirect_preference_listは、database_redirect_preference_listよりも優先されます。
たとえば、 database_redirect_preference_list = 'postgres:standby(1.0)'、 app_name_redirect_preference_list = 'myapp1:primary(1.0)' と設定した場合、アプリケーションmyapp1、postgresデータベースでのSELECTはプライマリバックエンドノードに送られます。
注意: app_name_redirect_preference_list及びdatabase_redirect_preference_listの設定では、複数のデータベース名やアプリケーション名にマッチした場合、最初の設定が反映されます。
たとえば、 database_redirect_preference_list = 'postgres:primary,postgres:standby' と設定した場合、postgres:primaryの設定が反映されます。
| 注意 |
JDBCドライバのpostgresql-9.3以前のバージョンでは、JDBCドライバの"ApplicationName" と "assumeMinServerVersion=9.0"オプションを指定してもスタートアップパケットの中にアプリケーション名を含みません。 JDBCからapp_name_redirect_preference_list機能を使用したければ、postgresql-9.4 以降のドライバをお使いください |
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
onに設定すると、Pgpool-IIは負荷分散やクエリキャッシュができるかどうかの判定の際にSQLコメントを無視します。 このパラメータがoffに設定されている場合、クエリのSQLコメントにより、クエリの負荷分散やキャッシュを防止することができます。 （Pgpool-II V3.4より前のバージョンの動作です）。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。 現在のセッションでのパラメータ値は、PGPOOL SETコマンドで変更することもできます。
writeクエリが発行された時の負荷分散の振る舞いを指定します。 このパラメータは、特にストリーミングレプリケーションモードで有効です。 writeクエリがプライマリサーバに送られた時、この変更はスタンバイサーバにも適用されますが、そこには時間差があります。 ですからクライアントが行を更新して同じ行をスタンバイから読むと、その行の最新データを読めないかもしれません。 もしこれが問題になるようなら、クライアントは常にプライマリサーバからデータを読むべきです。 しかし、これは実質的に負荷分散を無効にして、性能低下をもたらします。 このパラメータは、クラスタリングについて考慮しないアプリケーションにおける互換性と、性能の間におけるトレードオフの細かな調整を可能にします。
このパラメータがoffなら、writeクエリが来ても負荷分散が行われます。 この設定では最大の性能を期待できますが、クライアントは古いデータを読むことになるかもしれません。 この設定は、PostgreSQLのパラメータsynchronous_commit = 'remote_apply'が設定されているか、ネィティブレプリケーションモードのときに有用です。 そのような環境ではレプリケーションの遅延が発生しないからです。
このパラメータがtransactionで、明示的なトランザクション中にwriteクエリが来ると、トランザクションが終了するまで負荷分散が行われません。 なお、明示的なトランザクション中ではないreadクエリは、このパラメータの影響を受けないことに注意してください。 この設定は、たいていの場合に最良のバランスを提供するので、この設定から試すことをお勧めします。 これはデフォルトで、Pgpool-II 3.7以前のバージョンと同じ振る舞いです。
このパラメータがtrans_transactionで、明示的なトランザクション中にwriteクエリが来ると、トランザクションが終了するまで負荷分散が行われません。 また、セッションが終了するまで後続の明示的なトランザクション中でも負荷分散が行われません。 この設定は古いアプリケーションにとって安全ですが、transactionよりは性能が低下します。 なお、明示的なトランザクション内にないreadクエリは、このパラメータの影響を受けないことに注意してください。
このパラメータがalwaysで、writeクエリが来ると、明示的なトランザクション中であるかどうかを問わず、セッションが終了するまで負荷分散が行われません。 この設定により、クラスタリングについて考慮しないアプリケーションを使った場合最大の互換性が得られますが、性能は最低になります。