A.20. リリース 4.1.0

A.20.1. 概要

このバージョンでは、待望のstatement_level_load_balance、auto_failback機能を実装しています。 また、パフォーマンスに関連する分野も強化しています。 PostgreSQL12の新しいSQLパーサを取り込んでいます。

Pgpool-II4.1の主な改善点は以下のとおりです。

• ステートメントレベルの負荷分散に対応しました。 以前のPgpool-IIは、セッションレベルの負荷分散のみ可能でした。 このバージョンでは、statement level load balancingを使用でき、フロントエンドがPgpool-IIに常時接続しているが、存在するスタンバイサーバのリソースを使用したい場合に便利です。

• 自動フェイルバックは、フェイルバックするために十分な安全を考慮しストリーミングレプリケーションのスタンバイサーバを自動的にアタッチできます。

• 多くの領域でのパフォーマンス向上が向上しました。

  • 共有リレーションキャッシュは、セッション間でリレーションキャッシュを再利用でき、PostgreSQLシステムカタログに対する内部的なクエリを減らすことができます。

  • 不必要なパース処理を取り除くためにDML文用にSQLパーサを持ちます。

  • 特定クエリの負荷分散を制御します。

• PostgreSQL12のSQLパーサを取り込みました。

A.20.2. バージョン4.1への移行

バージョン4.1には、以前のバージョンとの互換性に影響するいくつかの変更点が含まれています。 以下の非互換性に注意してください。

• SHOW POOL_NODESおよび同様のコマンドにreplication_stateとreplication_sync_state列を追加しました。(Tatsuo Ishii)

  PostgreSQL 9.1 で利用可能なpg_stat_replication (replication_state_syncも使用します。しかし、9.2以降でのみ利用可能です。)から重要な情報を表示できます。 この目的のために各バックエンドホストの設定パラメータに新しいbackend_application_nameパラメータが追加しました。 pg_stat_replicationはストリーミングレプリケーションの遅延チェックプロセスから呼び出されます。 そのため、sr_check_periodが0の場合、これらの新しい列は利用できません。

  pcp_node_infoおよびpgpool_adm_pcp_node_info関数も変更されています。

• 多数決ルールを設定するenable_consensus_with_half_votesパラメータを追加しました。 (Muhammd Usama, Tatsuo Ishii)

  これは、偶数（すなわち、2, 4, 6...) watchdogクラスタにおけるクォーラムの存在および多数決の決定における振る舞いを変更します。 奇数のクラスタ（3, 5, 7...）は影響を受けません。 このパラメータがオフ（デフォルトです）の場合、2ノードのwatchdogクラスタは、クォーラムを持つためには2ノードの両方が生存している必要があります。 クォーラムが存在しないと、1) VIPが失われます 2) フェイルオーバスクリプトが実行されません 3) watchdogのマスターが存在しなくなります。 特に#2は、既存のPostgreSQLがダウンしても新しいプライマリが存在しなくなるので、困ったことになるでしょう。 おそらく2ノードのwatchdogクラスタユーザはi、このパラメータをオンにして、今までと同様に振る舞まうようにしたいでしょう。 一方4ノード以上の偶数watchdogクラスタユーザはこのパラメータがオフであることにメリットがあります。 なぜなら、半分のwatchdogノードがダウンしてsplit brainになる可能性を防ぐことができるからです。

• RPMs からインストールする場合、デフォルトではpostgresユーザで Pgpool-IIを起動するようになりました。(Bo Peng)

  セキュリティ上の理由で、Pgpool-IIのデフォルトの起動ユーザが postgresユーザに変更されました。

  RPMsからインストールする場合、postgresユーザがパスワードなしに sudoを介してif_up/down_cmd及びarping_cmdを 実行できるように設定されています。 また、if_up/down_cmdやarping_cmdに指定したコマンドが"/"で始まる場合、 フルパスとみなしif_cmd_pathやarping_pathの設定を無視します。

• sent messageモジュールのログをLOGからDEBUG5にダウングレードしました。(Tatsuo Ishii)

A.20.3. 主な改善点

• ステートメントレベルの負荷分散を使うことができます (Bo Peng)

  この機能ではステートメント単位の負荷分散ノードの選択を有効にします。 負荷分散の現在の機能では、負荷分散ノードはセッション開始時に決定され、セッションの終了まで変更されませんでした。 statement_level_load_balance = on に設定すると、負荷分散ノードは参照クエリごとに決定されます。 例えば、コネクションプーリングを使用するアプリケーションでは、セッションは長い時間保持される可能性があり負荷分散ノードはセッションの終了まで変更しないため、バックエンドサーバとのコネクションが開いたまま残ります。 statement_level_load_balanceが有効の場合、セッション毎ではなくクエリ毎に負荷分散ノードを決定することができます。

• auto_failbackを追加しました。(Takuma Hoshiai)

  実際には正常に稼働しているがDOWN状態のバックエンドノードを自動で再アタッチできます。

  この機能を使うためには、PostgreSQLが9.1以降、かつ新しい設定変数 auto_failbackが有効である必要があります。 Pgpool-IIは、sr_checkとhealth_checkが有効なストリーミングレプリケーションモードで動作している必要もあります。 Pgpool-IIは、問題のスタンバイノードが稼動しており、プライマリサーバからレプリケーションストリームを受け取れるか確認するためPostgreSQLプライマリサーバ上のpg_stat_replicationを呼び出します。

  この機能は、一時的なネットワーク障害が原因でスタンバイサーバがフェイルオーバした場合に役立ちます。

• 新しいenable_shared_relcacheを追加しました。(Takuma Hoshiai)

  リレーションキャッシュは、子プロセスのローカルキャッシュに蓄積されるため、すべての子プロセスはリレーションキャッシュを取得するために同じクエリを実行していました。 enable_shared_relcacheがonの場合は、リレーションキャッシュがメモリキャッシュに蓄積され全ての子プロセスで共有します。 同じクエリが実行されることによる負荷の軽減が期待できます。

• 一時テーブルを確認するための新しいパラメータcheck_temp_tableを追加しました。(Tatsuo Ishii)

  一時テーブルの確認はシステムカタログを参照する必要があるため遅いです。 システムカタログの参照を除外するため、CREATE TEMP TABLE/DROP TABLEをトレースする新しい方式が追加されました。 新しい方式を使用するためには、check_temp_tableをtraceに設定してください。

  関数やトリガ内で作られたテーブルをトレースすることができないことに注意してください。 この場合、従来の方式を使用すべきです。

• システムカタログに対する内部クエリを減らしました。(Tatsuo Ishii)

  現在、リレーションキャッシュモジュールは、PostgreSQLから様々な情報を取得するために7つ以上のクエリを発行しています。 これらのいくつかは、 Pgpool-IIがPostgreSQLの複数のバージョンで動作するために必要となります。 このような内部クエリを削減するためには、どんな種類のクエリが必要とされているかを知るためにPostgreSQLバージョンを取得します。 例えばpg_namespaceが存在するか知る必要がある場合、この目的のためにpg_classにクエリを送ります。 しかし、pg_namespaceはPostgreSQL 7.3で導入されていることを知っていれば、pg_classを調べる必要はありません。

• 大規模なINSERTとUPDATE文のパフォーマンスの強化。(Muhammd Usama)

  Pgpool-IIでは、特にINSERTとUPDATE文のクエリをどこに送る必要があるか決定するためにとても小さな情報だけを必要とします。 例えば、マスタースレーブモードでINSERT文の場合、Pgpool-IIは列の値と他のパラメータについては気にせずステートメント内で参照されるリレーション名だけを必要とします。 しかし、Pgpool-IIで使うパーサーは、PostgreSQLのソースから取り込んだものなので、値のリストを含む完全なクエリを構文解析します。小さいステートメントでは無害と考えられますが、INSERTとUPDATEで多くの列値と値の中に巨大なデータがある場合、かなりの時間を消費します。

  このアイデアは、必要な情報を確認したら直ちにINSERTやUPDATE文の構文解析を省くことです。 この目的のため、マスタースレーブモード内で呼び出される二つ目の小さなパーサーを追加し、巨大なINSERTやUPDATE文に関するパフォーマンスを引き出そうとしています。

  二つ目のパーサの追加とは別に、パフォーマンスの強化に向けた変更も含まれています。 詳細は、commitを参照してください。

• PostgreSQL 12 beta2の新しいパーサを取り込みました。(Bo Peng)

  PostgreSQL12のパーサの主な改善点は以下のとおりです。

  • 新しいVACUUMのオプション: SKIP_LOCKED、INDEX_CLEANUP、TRUNCATEの対応

  • COMMIT AND CHAINとROLLBACK AND CHAINコマンドの対応

  • WHERE句のCOPY FROMの対応

  • CREATE OR REPLACE AGGREGATEコマンドの対応

  • CREATE STATISTICSのMCV(most-common-value)対応

  • REINDEXのCONCURRENTLYオプションの対応

  • EXPLAINのSETTINGSオプションの対応

• リレーションキャッシュのクエリを負荷分散ノードに送ることができます。(Tatsuo Ishii)

  リレーションキャッシュ項目を作るためのクエリは、常にマスタ(プライマリ)ノードに送られていました。 レプリケーションの遅延による悪い影響を取り除けるため、これは通常適しています。 しかしながら、もしマスタノードの負荷を下げたい場合、マスタノード以外の他ノードにそのクエリを送ることができるので便利です。 このパッチは、新しいパラメータrelcache_query_targetを導入します。 もしload_balance_nodeに設定した場合、リレーションキャッシュのクエリは負荷分散ノードに送られるでしょう。 もしmasterに設定した場合、クエリは今迄と同様にマスタノードに送られます(これがデフォルトです)。

• black function listで指定された、もしくはwhite function listで指定されていない関数を持つSELECT後の負荷分散を無効化します。(Bo Peng)

  Pgpool-II4.0以前では、disable_load_balance_on_write = transactionに設定することで明確なトランザクション内で更新を伴うクエリが発行されたとき、後続のクエリはレプリケーション遅延を避けるためにトランザクションが終了するまでプライマリのみに送られるべきです。 しかしながら、black_function_listで指定された、もしくはwhite_function_listで指定されていない 更新を伴う関数は、white queryとは見なされず、後続の参照クエリはまだ負荷分散します。 このcommitは、black function listで指定された、もしくはwhite function listで指定されていない関数を持つSELECT後の負荷分散を無効化します。

• フロントエンドからの新しい接続を許可しないための新しい機能を実装しました。(Tatsuo Ishii)

  Pgpool-IIは、最大num_init_childrenフロントエンドまでを許可し、子プロセスの1つが解放されるまで多くの接続要求をキューします。 これはほとんどの場合うまく動作しますが、各セッションで長い時間が掛かるとキューが長くなり、システム全体が円滑に動作しなくなります。 問題は克服するため、フロントエンドからの多くの接続要求を処理する新しい方式を実装しました。 reserved_connectionsを1以上に設定すると、クライアントからの現在の接続数が(num_init_children - reserved_connections)以上になった場合、ブロックするのではなくクライアントからの後続の接続は受理されずエラーメッセージ"Sorry, too many clients already"を返します。

• 必要のないselect(2)システムコールを取り除くことによりパフォーマンスを向上しました。(Tatsuo Ishii, Jesper Pedersen)

• フロントエンドへメッセージを送信している間のパフォーマンスを向上しました。(Tatsuo Ishii)

  フロントエンドへメッセージを送信するSimpleForwardToFrontend()は、'D'もしくは'd'の場合のみバッファに書き込みます。 その他のメッセージ種類は即座にソケットに書き込まれます。 しかし、実際にはこれは必要ではありませんでした。 そのため、致命的でないメッセージだけバッファに書き込むようにしました。 これによって10～17%のパフォーマンス向上が見られます。

• 必要のない警告もしくはエラーメッセージの解析を回避しました。(Tatsuo Ishii)

  バックエンドへクエリを送信後、Pgpool-IIはいつもper_node_error_log()によってpool_extract_error_message()を呼び出していました。 エラーもしくは警告メッセージがバックエンドから返された場合も、関数内でメモリの割り当てが実行されていました。 CPUサイクルの消費を避けるため、メッセージの種類を確認し、エラーもしくは警告メッセージでなければpool_extract_error_message()の呼び出しを避けます。

• CopyDataメッセージ操作のパフォーマンスを向上しました

  COPY XX FROM STDINが実行されるとき(代表的なクライアントはpg_dump)、それぞれのコピー行データは、CopyDataメッセージを用いてPgpool-IIからフロントエンドに送られます。 以前は、一つのCopyDataメッセージに続いてフラッシュをしており、多大なコストがかかっていました。 代わりに、現在はコマンドの完了、警告メッセージもしくはエラーメッセージの後にフラッシュされます。 簡易テストでは、この変更により2.5倍速度が向上することが分かりました。

• health_check_passwordおよびsr_check_password内でMD5ハッシュパスワードが使用できます。(Tatsuo Ishii)

• SSLでのEDDHキー交換に対応しました。(Takuma Hoshiai)

• "pgpool show backend"グループにbackend_application_nameを追加しました。(Tatsuo Ishii)

• PostgreSQL 12に対応しました。(Tatsuo Ishii)

  recovery.confは今後使用されません。 スタンバイのリカバリ設定は現在postgresql.conf内となります。 "standby.signal"ファイルもまた、スタンバイサーバとしてpostmasterを起動するためにPostgreSQLデータベースクラスタディレクトリ内で必要となります。

  HeapTupleGetOid()はPostgreSQL12では今後使用できません。 GETSTRUCT()を使用し、Form_pg_procのoid列を参照します。

  pgpool_admエクステンションを変更します。 現在は、 oidが無くなったため、CreateTemplateTupleDesc()の定義が変更されました。

• バックエンドが全てダウンしている際、フェイルオーバの速度が向上しました。(Tatsuo Ishii)

  すべてのバックエンドがダウン状態であっても、Pgpool-IIはsearch_primary_node_timeoutの期限までプライマリノードを探します。 これは時間の浪費だけではなく、プライマリノードの検索中はフェイルオーバプロセスが一時中断され、Pgpool-IIの全ての子プロセスが機能していない状態になるため、Pgpool-IIはハングしているように見えます。従って、クライアントからの接続要求を受け入れるプロセスがありません。 プライマリ検索のデフォルト値は300秒であるため、これは通常300秒間維持します。 これはユーザにって快適ではありません。

  この修正では、もしすべてのバックエンドがダウン状態であれば、search_primary_node_timeoutに関係なくプライマリノードを探すことを即時に諦めフェイルオーバプロセスが即時に終了します

• プライマリバックエンドノードがqurantine状態になるのであれば、マスタwatchdogノードを辞退します。(Muhammd Usama)

  こうすることで、プライマリPostgreSQLサーバが存在しない状況を避けることができます。 この実装のためには、隔離されたプライマリノードのフェイルオーバに関する合意の取得に失敗する場合、マスタ/コーディネータのwatchdogノードはその状態からFAILOVER_COMMAND_FINISH_TIMEOUT(15)秒以内に辞退します。

  隔離されたプライマリノードのためにwatchdogのマスタが辞退する場合、wd_priorityが-1に減少するため、マスタ/コーディネータノード選択のための次の選挙で最も低い優先度となるはずです。 そして一度選挙で完了されると、ノードのwd_priorityは元の設定値に戻ります。

  スタンバイノードのフェイルオーバの合意に失敗した場合、何もしません。

• 多数決ルールの計算方法を設定するenable_consensus_with_half_votesパラメータを追加しました。(Muhammd Usama, Tatsuo Ishii)

  Pgpool-IIはwatchdogクラスタが偶数のノードで構成されている場合、ちょうど50%の賛成を得られたときにクォーラムの存在とフェイルオーバの合意を決定します。 enable_consensus_with_half_votesパラメータにより、ユーザはPgpool-IIに対して、偶数ノードのクラスタにおける分散合意が(n/2)なのか、((n/2) +1)なのかを設定できます。 奇数ノードのクラスタ(3, 5, 7...)は、影響を受けません。 2ノードのクラスタでは特別な注意が必要です。 詳細は項A.20.2をご覧ください。

• pool_passwdに絶対パスを指定できるようになりました。(Bo Peng)

  パッチはDanylo Hlynskyiにより提供されました。

• フェイルオーバ、オンライリカバリで実行される各種サンプルスクリプトを追加しました。(Bo Peng)

  failover.sh.sample、follow_master.sh.sample、recovery_1st_stage.sample、recovery_2nd_stage.sample、 pgpool_remote_start.sampleのサンプルスクリプトを配布別に含めるようにします。

• ドキュメントを強化しました。

  • パフォーマンスの章(第7章)を追加しました。(Tatsuo Ishii)

  • "チュートリアル"の"さあ始めましょう"と"Watchdog"、および"サーバ管理"のいくつかの節を強化しました。(takuma hoshiai)

  • 設定の例の"Pgpool-II + Watchdogの構築の例"を更新しました。(bo peng)

  • white/black_function_listでスキーマ修飾が使用出来ないことを記述しました。(tatsuo Ishii)

  • failover_commandとfollow_master_commandについて説明を強化しました。(tatsuo Ishii)

  • detach_false_primary設定パラメータの注釈を追加しました。(tatsuo ishii)

  • follow_master_commandに説明を追加しました。(tatsuo ishii)

  • watchdog/pgpool-IIの例を強化しpg_monitorロールについて記述しました。(tatsuo ishii)

  • マルチステートメントクエリがプライマリノードにのみ送られることを記述しました。(tatsuo ishii)

  • 負荷分散の説明を追加しました。(tatsuo ishii)

  • pcpのリファレンスページにpcp.confの作成方法に役立つリンクを追加しました。(tatsuo ishii)

  • pcp_node_infoのマニュアルの説明を追加しました。(tatsuo ishii)

  • pg_md5のマニュアルページにpool_paswd文字列の表現の仕方の説明を追加しました。(tatsuo ishii)

  • クライアント認証のドキュメントを強化しました。(tatsuo ishii)

  • クォーラムによるフェイルオーバに関するドキュメントを強化しました。(tatsuo ishii)

  • rawモードもしくはload_balance_mode = offの場合のリレーションキャッシュについて記述しました。(tatsuo ishii)

  • フェイルオーバについての一般的な説明を追加しました。(tatsuo ishii)

A.20.4. バグ修正

• このリリースではPgpool-II 4.0.7 と同様のバグ修正が既に適用されています。 修正の詳細は項A.39を参照してください。