この記事はPgpool-II 4.1の紹介【第1回】の中のWatchdogの機能強化について詳しく紹介します。今回でPgpool-II 4.1の紹介は最後になります。
Watchdogとは
具体的にPgpool-II 4.1のwatchdogの機能強化について説明する前に、watchdogとは何かについておさらいしておきましょう。Watchdogは、Pgpool-IIのオプション機能の一つで、Pgpool-II自体の可用性を高めるものです。Pgpool-IIでは、以下の図のようにすべてのクライアントからのアクセスがPgpool-IIを経由してPostgreSQLに送られるので、もしもPgpool-IIがダウンしてしまうと、データベースがまったく使えなくなってしまいます。
そこでPgpool-IIを複数台用意し、万が一Pgpool-IIがダウンしてしまった時にもう1台のPgpool-IIに切り替えて処理を続行するのがwatchdogの役割です。
Pgpool-IIが切り替わっても、クライアントは引き続き同じVIP (Virtual IP)でPgpool-IIに接続することにより、Pgpool-IIが切り替わったことを意識せずにデータベースシステム全体の利用を継続することができます。この図ではPgpool-IIは2つですが、実際にはいくつでもPgpool-IIをもっと設置することも可能で、Pgpool-IIは3台以上の奇数台数を設置することが推奨されています。この理由については後で説明します。
なお、wathdog機能は実際にはPgpool-IIから起動される別プロセスで実装されていますが、概念的にはPgpool-II = watchdogと考えて差し支えありません。そこで、以下の説明ではPgpool-IIの代わりにwatchdogという用語を用います。
Watchdogの改善点その1 – マスタwatchdogノードの自動辞退
上の図で、VIPを持つwatchdogとVIPを持たないwatchdogの2つが出てきました。VIPを持つwatchdogは「マスタwatchodg」と呼ばれ、watchdogがいくつあっても、クラスタ内には1台のみ存在するのが原則です。マスタwatchdogはクラスタシステム起動時にパラメータ「wd_priority」パラメータが大きいwatchdogがその役割を担います。マスタ以外のwatchdogは「スタンバイ」と呼ばれます。
さて、昨今ではPostgreSQLはストリーミングレプリケーションで構成するのが一般的です。これにより、可用性や参照負荷分散などのメリットをユーザは享受できます。以下はPgpool-IIコミュニティによって推奨される本格的なクラスタシステムで、Pgpool-IIが3台、PostgreSQLが2台で構成されています。
（具体的なセットアップ方法はマニュアルに詳しく記載されています）
この図の中で点線が各Pgpool-IIからPostgreSQLに出ていますが、これは「ヘルスチェック」という、Pgpool-IIがPostgreSQLデータベースの健全性をチェックする機能を表しています。これにより、たとえばプライマリPostgreSQLがダウンしても、スタンバイPostgreSQLを自動昇格させてデータベースシステムとしての運用を継続することができます。
Pgpool-II同士で意見が合わない？
PostgreSQLの健全性の確認は、ネットワークを通じてPgpool-IIがPostgreSQLに接続することにより行われます。ネットワークが正常ならば、どのPgpool-IIから見てもPostgreSQLが正常かどうかの見解は変わらないはずです。しかし、今マスタPgpool-IIとプライマリPostgreSQLの間のネットワークだけに故障が発生したらどうでしょう？この場合、マスタPgpool-IIはプライマリPostgreSQLを故障と判断、スタンバイPgpool-IIは健全と判断し、意見が別れてしまいます。そこでwatchdogはお互いに意見を交換して多数決で判断を下し、マスタPgpool-IIの「故障」判断は却下されます。（Pgpool-IIが偶数だと多数決が下せないので、困ったことになります。これが奇数台のPgpool-IIを設置することが推奨される理由です)
判断が却下されたプライマリPgpool-IIはプライマリPostgreSQLを「隔離(quarantine)」状態にします。隔離状態にあるPostgreSQLにはPgpool-IIは問い合わせを送信せず、スタンバイPostgreSQLに問い合わせを送ることになります。しかし相変わらずVIPはそのマスタPgpool-IIにアサインされており、クライアントからの更新問い合わせもスタンバイに送られます。スタンバイのPostgreSQLでは更新処理が実行できないので、そうした問い合わせはすべてエラーになってしまします。
watchdogマスタが自主降格して問題を回避
そこでPgpool-II 4.1では、こうした場合にマスタwatchdogは自主的に自分を降格して他のPgpool-IIにマスタの役割を移譲するようになりました。もちろんVIPも新しいPgpool-IIにアサインされるので、引き続き更新処理も正常に実行することができます。
多数決原則はPgpool-IIダウン時にも適用
ちなみに、Pgpool-IIが多数決でものごとを決める仕組みは、Pgpool-II自体のダウン時にも適用されます。Pgpool-IIはお互いに通信しながら互いの生死を確認しており、たとえば以下の図のように、Pgpool-IIの1,2はお互いに通信できるが、3は他のPgpool-IIと通信できない状態になっても、Pgpool-II 3は過半数の投票を得られないため、勝手にPgpool-II 3がマスタに昇格してしまうことを防ぐことができます。これはいわゆる「スプリットブレイン」状態の防止につながります。
Watchdogの改善点その2 – 新しいパラメータenable_consensus_with_half_votes
前述のように、Pgpool-IIでは多数決でものごとを決められるように、設置台数を奇数台にすることが推奨されています。しかし世の中にはリソースを節約するために2台でシステムを更正している例も多く、従来はPgpool-II台数が偶数の場合にはその半分、すなわち1台だけの賛成が得られても多数決の合意が得られるとしていました。しかしこれでは、たとえば台数が4台の時に2台の賛成で合意が得られることになり、おかしなことになります。そこでPgpool-II 4.1では、デフォルトで過半数の合意を得るためにPgpool-II台数の過半数の賛成が必要となりました。しかしPgpool-II台数が2台のときには、これだとPgpool-IIが1台ダウンした時に決して過半数が得られなくなってしまうため、救済のために新しいパラメータenable_consensus_with_half_votesが追加されました。このパラメータがonなら、Pgpool-II台数が2台のときには、1台のPgpool-IIの賛成のみで合意が得られます。ただし、Pgpool-IIが2台構成の時は、お互いの監視ネットワークがダウンした時にお互いに自分だけが生きていると思い込むスプリットブレイン状態になることを防ぐことができない点は変わりません。
終わりに
9回に渡ってPgpool-II 4.1の新機能をご紹介しました。Pgpool-IIはバージョンごとに機能が充実しており、適用できる案件が増えてきていると思います。今回のリリースでは、すぐに利用できるインストール方法とともに、各種雛形設定ファイルも配布物に同梱されています。この機会にPgpool-IIを使ったPostgreSQLクラスタシステムの構築にチャレンジしてみてはいかがでしょう。
Pgpool-II 4.1の紹介【第1回】
Pgpool-II 4.1 新機能: ステートメントレベルの負荷分散【第2回】
Pgpool-II 4.1 新機能: reserved_connections【第3回】
Pgpool-II 4.1 新機能:自動フェイルバック 【第4回】
Pgpool-II 4.1 新機能:PostgreSQL 12への対応【第5回】
Pgpool-II 4.1 新機能:2拠点に分かれたレプリケーション構成への対応【第6回】
Pgpool-II 4.1 新機能: シェアードリレーションキャッシュ【第7回】
Pgpool-II 4.1 新機能: Pgpool-II によって発行される内部クエリの改善【第8回】
Pgpool-II 4.1 新機能: Watchdogの機能強化【第9回】