pgpool-IIの3.6以降におけるフェイルオーバー時のクライアントセッション

postgresql
この記事は約5分で読めます。

pgpool-II 3.6以降のフェイルオーバー時のクライアントセッションについての検証。

ストリーミングレプリケーションモードにおいて、pgpool2では、データベース障害が発生した場合、障害の起きたデータベースサーバの切り替え(プライマリ)又は切り離し(スタンバイ)を行なってくれる。3.5より前は、pgpool2の子プロセスは全て再起動されるため、クライアントのセッションも全て切断されていた。しかし、3.6以降はセッションの切断の影響を最小限にするための改良が行われているようで、障害の起きたデータベースサーバがスタンバイである且つセッションで負荷分散対象先でない場合において、クライアントセッションは切断されないようになった(他の改善点などは、以下リリースノートを参照)。

リリース 3.6

ということで、この挙動について理解を深めるべく検証してみる。

環境構築

今回は、pgpool_setupコマンドを使って、同一ノード上でPostgreSQLのプライマリ及びセカンダリノード、pgpool2を動かした状態で確認した。以下環境である。

  • Mac OS X
  • pgpool2 3.6.6
  • PostgreSQL 9.5.6

psコマンドで確認しやすいよう、num_init_childrenは1、max_poolは2とした。

負荷分散先のスタンバイサーバがダウンした場合

まずプロセスツリーを確認しておく。

クライアント接続

同一ノード上からpsqlコマンドで接続した。JDBCのようなドライバでは拡張プロトコルとなるが、拡張プロトコルでは、show pool_nodesコマンドが使えない。よって、psqlコマンドを使用している。

psqlから接続した状態は以下である。showコマンドで負荷分散先が表示される。負荷分散先は、load_balance_nodetrueとなっていることがわかる。このセッションでは、PostgreSQLのセカンダリサーバが負荷分散先となっていることがわかる。

プロセスの状態は以下のようになっている。プライマリ、セカンダリサーバのそれぞれにデータベースコネクション接続があることがわかる。

スタンバイサーバダウン

上記の状態でスタンバイサーバをダウンさせる。

シャットダウン直後のプロセスツリーは以下。データベースのバックエンドプロセスは消えている。また、子プロセスは再起動され、プロセスIDが新しくなっていることが確認できる(1つは子プロセス、あとはPCPとworker)。

クライアントのセッションは切断されている、リトライでは成功する。

負荷分散先でないスタンバイサーバがダウンした場合

プロセスツリーの確認。

クライアント接続

続いて、クライアントセッションの負荷分散先を確認し、トランザクション開始。

スタンバイサーバダウン

以下のコマンドで、スタンバイサーバの即時停止。

スタンバイサーバダウン直後のプロセスツリー。pgpool2の子プロセス(PID:47185)は残っており、またプライマリサーバのバックエンドプロセスも残ったままとなっていることが確認できる。

クエリも引き続き実行でき、クライアントセッションは切断されていない。

クライアントのセッションが終了すると、該当する子プロセスは再起動される。

プライマリサーバがダウンした場合

この場合は、負荷分散先に関わらずクライアントのセッションは切断される。

プロセス状態。

クライアント接続

負荷分散先をセカンダリサーバにした状態で行なう。

プライマリサーバダウン

プライマリサーバダウン後の切り替え後のプロセス状態。pgpool2の子プロセスは再起動されている。

クライアントセッションは切断されるが、リトライで成功する。

まとめ

以上まとめると、以下のようになっている。(と思われる、3.6以降)

プライマリ セカンダリ
障害発生 ダウン ダウン
負荷分散対象 ✖️
クライアントセッション ✖️ ✖️

参考リンク

コメント

タイトルとURLをコピーしました