5.7. 負荷分散

Pgpool-IIのSELECTクエリの負荷分散はマスタースレーブモード(項5.3.1)とレプリケーションモード(項5.3.2)で動作します。 有効時、Pgpool-IIは更新を伴うクエリを、マスタースレーブモードではプライマリノードに、レプリケーションモードでは全てのバックエンドノードに対し送信します。 そして、その他のクエリは全てのバックエンドの間で負荷分散されます。 負荷分散メカニズムが参照クエリをどのノードに送信するかはセッション開始時に決められ、セッションの終了まで変更されません。 唯一の例外は特別なSQLコマンドが発行されたときです。 詳細については以下をご覧ください。

注意: 負荷分散ができないためにプライマリノードまたは全バックエンドノードに送られるクエリもまた、 負荷分散アルゴリズムの考慮に入れられます。

注意: もし負荷分散対象のクエリをPgpool-IIに負荷分散してほしくない場合には、SELECT文の前の/*NO LOAD BALANCE*/コメントを付与することができます。 これにより、そのクエリの負荷分散は無効となり、Pgpool-IIはこれをマスターノード(マスタースレーブモードではプライマリノード)に送信します。

注意: どのDBノードが負荷分散ノードになっているかは、SHOW POOL_NODESを利用して確認できます。

5.7.1. 負荷分散の条件について

クエリが負荷分散されるためには、以下の全ての条件を満たす必要があります:

注意: SELECTクエリの前に任意のコメントを挿入することにより負荷分散を抑制することができます。

    /*REPLICATION*/ SELECT ...
   

SQLコメントの記述が負荷分散に影響を与えないようにするには、allow_sql_commentsをonにします。 replicate_selectも参照してください。

注意: JDBC ドライバにはautocommitオプションがあります。 autocommit を無効にすると、ドライバが内部でBEGINおよびCOMMITコマンドを実行し、明示的なトランザクションが開始されます。 この場合、トランザクション内における上記の負荷分散の制限事項が適用されます。

5.7.2. ストリーミングレプリケーションにおける負荷分散

ストリーミングレプリケーションとHot Standbyを利用している環境では、プライマリノードに送ってよい問い合わせ、スタンバイに送ってもよい問い合わせ、両方に送らなければならない問い合わせを厳密に管理する必要があります。 Pgpool-IIのストリーミングレプリケーションモードは、こうした振り分けを自動的に行ないます。

クエリそのものから、どのクエリがどのノードに送られるべきかを区別します。

明示的なトランザクションでは、以下のようになります。

問い合わせが、拡張問い合わせモードで実行される場合は、問い合わせのparse段階で、問い合わせがスタンバイに送信可能かが決まります。 その際の判断ルールは通常のSQLと同じです。 たとえば問い合わせがINSERTならば、プライマリノードに送られます。 それに後に続くbind, describe, executeも同じくプライマリに送られます。

注意: 負荷分散によりSELECT文のparseがスタンバイノードに送信され、その後INSERTなどのDML文がPgpool-IIに送られた場合、parse済のSELECTはプライマリノードで実行されなければなりません。 そのため、同じSELECTがプライマリノードで再度パースされることになります。

最後に、pgpool-IIのパーサが構文エラーと判断した問い合わせはプライマリノードだけに送られます。

5.7.3. 負荷分散の設定

load_balance_mode (boolean)

onに設定すると、Pgpool-IIは入ってきたSELECTクエリに対する負荷分散を有効にします。 すなわち、クライアントからのSELECTクエリは設定されたPostgreSQLバックエンドに振り分けます。 デフォルトはoffです。

このパラメータはサーバ起動時にのみ設定可能です。

ignore_leading_white_space (boolean)

onに設定すると、負荷分散の際にSQL文行頭の空白を無視します(全角スペースは無視されません)。 これは、DBI/DBD:Pgのように、ユーザの意図に反してに空白を追加するようなAPIを使っているときに有用です。

このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。

white_function_list (string)

データベースに対して更新を行なわない関数名をコンマ区切りで指定します。 このリストに指定されていない関数呼び出しを含むSELECTは負荷分散されません。 これらのクエリはレプリケーションモードにおいてはすべてのDBノードで複製され、マスタースレーブモードにおいてはプライマリノードにのみ送信されます。

関数名のマッチングに正規表現を使うことができます。 正規表現には自動的に^$が付与されます。

例 5-2. 正規表現の使用

もし読み出しのみを行う関数が"get_"あるいは"select_"で始まるようにしてあるのであれば、white_function_listを以下のように設定可能です。

	 white_function_list = 'get_.*,select_.*'
	

注意: Pgpool-IIはリストを参照する際に、暗黙のうちに入力SQLの関数名からスキーマ修飾部分を削除するため、white_function_listでスキーマ修飾を使えません。 その結果、リスト中のスキーマ修飾された関数名は、決して入力SQLの関数と一致しません。

このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。

black_function_list (string)

データベースに対して更新を行う関数名をコンマ区切りで指定します。 このリストに指定された関数呼び出しを含む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_listwhite_function_listは互いに排他的で、2つのリストの内、どちらか一方のみ設定することができます。

例 5-4. nextval()setval()を適切なバックエンドに送る設定

Pgpool-II V3.0より前のバージョンでは、固定でnextval()setval()がデータベースに書き込みを行なう関数であると認識されていました。 以下のようにwhite_function_listblack_function_listを設定することで、それと同じように動作させることができます。

	  white_function_list = ''
	  black_function_list = 'nextval,setval,lastval,currval'
	 

注意: PostgreSQLにはnextval()setval()に加え、lastval()currval()があります。 lastval()currval()は書き込みを行う関数ではありませんが、これらの関数が負荷分散されることで発生するエラーを防ぐため、lastval()currval()を書き込みを行う関数として扱うのが望ましいです。

このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。

database_redirect_preference_list (string)

特定のデータベース接続ではSELECTクエリが特定のバックエンドノードに送信されるように、"データベース名:ノードID"ペアのリストを指定します。 たとえば"test:1"とした場合、"test"データベースへの接続においては、Pgpool-IIは全てのSELECTクエリをIDが1のバックエンドノードに送信します。 複数の"データベース名:ノードID"のペアを カンマ(,)で区切って指定することができます。

データベース名には正規表現を指定することできます。 ノードIDには特別なキーワードを使うことができます。 "primary"が指定された場合にはクエリはプライマリノードに送られます。 また、"standby"が指定された場合はスタンバイノードのうちどれかをウェイトに応じてランダムに選択します。

例 5-5. database_redirect_preference_listの利用

SELECTクエリのルーティングルールを以下のように設定したい場合:

  • 全てのpostgresデータベースにおけるSELECTクエリはプライマリバックエンドノードに送る。

  • 全てのmydb0またはmydb1データベースにおけるSELECTクエリはIDが1のバックエンドノードに送る。

  • 全てのmydb2データベースにおけるSELECTクエリはスタンバイバックエンドノードに送る。

database_redirect_preference_listは以下のように設定します。

	 database_redirect_preference_list = 'postgres:primary,mydb[01]:1,mydb2:standby'
	

このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。

app_name_redirect_preference_list (string)

特定のクライアントアプリケーションの接続ではSELECTクエリが特定のバックエンドノードに送信されるように、"アプリケーション名:ノードID"ペアのリストを指定します。

注意: 「アプリケーション名」とはクライアントがデータベースに接続する時に指定する名称で、PostgreSQL V9.0以降で利用可能です。

たとえば、psqlコマンドのアプリケーション名は"psql"です。

注意: Pgpool-IIは、クライアントから送信されたスタートアップパケットに含まれるアプリケーション名だけを認識します。 クライアントは事後にセッションの中でアプリケーション名を指定できますが、それはPgpool-IIのクエリルーティングでは考慮されません。

app_name_redirect_preference_listの記法はdatabase_redirect_preference_listと同じですので、アプリケーション名には正規表現も使用できます。 同様に特別なキーワード"primary"はプライマリノードを、"standby"はスタンバイサーバのいずれかを意味します。

例 5-6. app_name_redirect_preference_listの利用

SELECTクエリのルーティングルールを以下のように設定したい場合:

  • 全てのpsqlクライアントからのSELECTクエリはプライマリバックエンドノードに送る。

  • 全てのmyapp1クライアントからのSELECTクエリはIDが1のバックエンドノードに送る。

  • 全てのmyapp2クライアントからのSELECTクエリはスタンバイバックエンドノードに送る。

app_name_redirect_preference_listは以下のように設定します。

	 app_name_redirect_preference_list = 'psql:primary,myapp1:1,myapp2:standby'
	

注意: app_name_redirect_preference_listは、database_redirect_preference_listよりも優先されます。

注意

JDBCドライバのpostgresql-9.3以前のバージョンでは、JDBCドライバの"ApplicationName" と "assumeMinServerVersion=9.0"オプションを指定してもスタートアップパケットの中にアプリケーション名を含ません。 JDBCからapp_name_redirect_preference_list機能を使用したければ、postgresql-9.4 以降のドライバをお使いください

このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。

allow_sql_comments (boolean)

onに設定すると、Pgpool-IIは負荷分散やクエリキャッシュができるかどうかの判定の際にSQLコメントを無視します。 このパラメータがoffに設定されている場合、クエリのSQLコメントにより、クエリの負荷分散やキャッシュを防止することができます。 (Pgpool-II V3.4より前のバージョンの動作です)。

このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。 現在のセッションでのパラメータ値は、PGPOOL SETコマンドで変更することもできます。