「TODO」の版間の差分

2014年1月28日 (火) 02:18時点における最新版

Pgpool-II TODO リスト

クライアント IP に基づいたロードバランスができるようにしてほしい

bugtrack #26: 私は最近 Mysql から pgpool-II-3.1.4 を利用した PostgreSQL 9.1.5 にデータベースを移行しました。データベースにデータを投入するアプリケーション (OTRS) が、ある「チケット」を正確に作成していないことを私が発見をするまで、全てはうまくいっていました。

いくつかのデバッグの後、私は問題は以下の通りであると推測しました。

cron ジョブがチケットを作成しようとすると、そのジョブは 10 前後のテーブルに情報をインサートする必要があります。そして、私は 2 番目、 3 番目以降のインサートは、 1 番目の処理に依存しているのではないかと思います。問題は、この操作がトランザクションに則していないないということです。そのため、 1 番目のインサートの後にアプリケーションが残りのインサートを実行しようと試みた時に、はじめに「1 番目のインサート」を参照しようとします。しかし、 1 番目のインサートはまだすべてのノードに伝搬しておらず、エラーが発生するのです。

そこで、私は pgpool に対して、「この IP からはどんなリクエストもロードバランスしない」といったような何らかの伝達手段があるかどうか知りたいです。

追伸、一時的に私は荷重因子を 2 番目と 3 番目の PostgreSQL サーバに設定しました。マスターのみから読み書きが行われるので問題なく動作しています。

ストリーミングレプリケーションの master/slave モードの設定でノードを自動的に再アタッチしてほしい

bugtrack #17: ストリーミングレプリケーションの master/slave モードの設定に、ノートがマスターの最新状態 (0 bytes behind) であったら、自動的にノードが再アタッチできるようなオプションがあると良いかもしれません。小規模ネットワークの停止によって、スレーブノードが pgpool から切り離されたままスレーブノードがマスターと同期して最新状態になっていることがよくあります。pgpool はすでにマスターの背後に何台のスレーブが存在するか分かっているので、それほど困難な改良ではないと思われますが？

クライアントエンコーディングが使えるようにしてほしい

pgpool に接続するクライアントが PostgreSQL サーバと異なるエンコーディングを使えたら嬉しいです。

この改良を行うためには、パーサーが Shift_JIS のような安全でないエンコーディングを扱えるようにする必要があります。psql は各マルチバイト文字の 2 バイト目を変換してパーサーに渡しています。私達はこの戦略を利用することができます。

フェイルオーバー後であっても、参照クエリをスタンバイのみに送信できるようにしてほしい

私達は pgpool-II が参照クエリをプライマリに送信しないように設定できます。しかしながら、フェイルオーバー後では、ノードの役割が変わってしまうことがあります。

この問題を解決するには、フェイルオーバーの発生に関係なく、スタンバイに参照クエリを送信するようにする新しいフラグが必要です ([pgpool-general: 1621] backend weight after failover) 。

マルチステートメントなクエリを認識してほしい

ドキュメントによると、 pgpool-II はマルチステートメントなクエリ (BEGIN;SELECT 1;END) を認識しません。 Pgpool-II は最初のクエリ（この場合は "BEGIN"）だけをパースし、処理を決定します。

もちろん、これは様々の問題を引き起こすでしょう。pgpool-II がマルチステートメントなクエリの各要素を理解できるようになると嬉しいです。

実装上の問題は、マルチステートメントのバックエンドでの扱いにあります。たとえば、BEGIN;SELECT 1;ENDに対してバックエンドは、BEGIN、SELECT、ENDに対してそれぞれCommand Completeを返しますが、Ready for queryは最後に1度しか返しません。したがって、psqlのように単純にBEGIN, SELECT 1, END を分解しただけではうまく処理できません。

レプリケーションモード時に、カーソルの宣言がロードバランスされずに全ての DB ノードに送信される

レプリケーションモード時に DECLARE..FETCH が全ての DB ノードに送信されます。これは SELECT 文に FOR UPDATE/FOR SHARE が付いているからでしょう。

pgpool-II が SELECT 文に FOR UPDATE/FOR SHARE が使われているかどうかを確認し、使われてなければロードバランスを行う（もしくはロードバランスを使用不可にしていたらマスターノードのみに送信する）ようになると嬉しいです。

psql を含んだアプリケーションは SELECT 文にカーソルを使うことができることに注意してください。例えば、PostgreSQL 8.2 からは "\set FETCH_COUNT n" が実行されると psql は無条件に "_psql_cursor" というカーソルを使います。

IPV6 ネットワークをサポートしてほしい

これは当然のリクエストです。

PostgreSQL の例外処理をインポートしてほしい

PostgreSQL の例外処理 (elog family) は、コードをシンプルで頑強にできるとても良いツールです。 pgpool もこれが使えるようになると嬉しいです。

watchdog 有効時は仮想 IP インターフェースの不正ダウンに対応してほしい

仮想 IP インターフェースが手動の ifconfig などによって不正に終了すると、VIP を操作することができなくなり、クライアントは pgpool-II に接続できなくなります。アクティブな pgpool の watchdog はインターフェースか VIP を監視し、不正な終了に対応すべきです。

オンディスを用いたクエリキャッシュを削除してほしい

ディスクを用いたクエリキャッシュはほとんど誰も使っておらず、キャッシュの無効化が自動でないといった厳しい制限があります。オンメモリクエリキャッシュが実装されたので、この機能はもはや時代遅れです。私達はこの機能を削除すべきです (これは git のマスターブランチに存在しており、 3.4.0 でも現れるでしょう）。

特定の場合では、トランザクション内で作成されたクエリキャッシュを無効にすべきではない

あるトランザクション内で作成されたテーブル t1 のクエリキャッシュが、同一トランザクション内で t1 を対象とした DML 文を含んでコミットされた時に削除されます。明らかに、特定の場合にはこれはやり過ぎです。:

BEGIN;
INSERT INTO t1 VALUES(1);
SELECT * FROM t1;
COMMIT;

これを修正するには、私達は DML と SELECT の順序を pgpool-II に教える必要があります。

pool_config.c のメモリリークを修正してほしい

pgpool.conf のパース処理を担っているモジュールにメモリリークがあります。大抵の場合、 pgpool は起動時に一度 pgpool.conf を読み込み、これはそれほど大きな問題ではありません。しかしながら、 pgpool.conf の再読み込みはメモリリークを起こし、これは間違いなく問題です。 valgrind などのメモリチェックツールを使った場合ももまた、多くのエラーメッセージを誘発し、非常に煩わしいです。したがって、将来的にこの問題が修正されると嬉しいです。

SET コマンドを追加してほしい

Pgpool の特定の SET コマンドが役に立つと思います。例えば、"SET debug = 1" を使うとオンザフライで、あるセッションのデバック情報を生み出すといったような。

一つのヘッダファイルにエラーコードの定義をまとめてほしい

今のところ、pool_send_{error,fatal}_message() など (例えば "XX000", "XX001", "57000") で使われている大部分のエラーコードは、異なるソースにハードコードされている。これらは一つのヘッダーにまとめて定数として定義されるべきです。

ヘルスチェックプロセスを別プロセスにしてほしい

メインプロセスをさらに安定させるために、ヘルスチェックの役割を持ったプロセスを分割してくれたら嬉しいです。

すでに完了した TODO

watchdog プロセスが不正に終了したら再起動してほしい

pgpool の main が、watchdog プロセスが不正に終了した場合に watchdog プロセスを再起動してくれると嬉しいです。

スタンバイの pgpool 起動時に watchdog でバックエンドノードの情報を同期してほしい

例えば、あるノードがアクティブな pgpool から切り離されてからスタンバイの pgpool が起動した場合、スタンバイの pgpool はノードが切り離されたことに気が付きません。スタンバイの pgpool は他の pgpool からノード情報を取得すべきです。

failover.sh が複数の pgpool から実行されるのを避けるようにしてほしい

watchdog を用いたマスタースレーブモードにおいて、バックエンド DB がダウンした時に全ての pgpool が failover.sh を実行します。これはおそらく何か悪いことを引きこすかもしれません。

プライマリノード検索のタイムアウト時間を設定する新しいパラメータを追加してほしい

pgpool-II はフェイルオーバーの後でプライマリノードを検索するために "recovery_timeout" を使います。これは設定値の乱用なので、私達はプライマリノード検索用の新しいパラメータを追加すべきです。

レプリケーションモード時に、明示的なトランザクションであってもロードバランスしてほしい

今のところ、明示的なトランザクションのロードバランスはマスタースレーブモードでしかできません。レプリケーションモードもできるべきです。

テストフレームワークを追加してほしい

PostgreSQL はすばらしいリグレッションテストスイートを持っています。pgpool-II も同様のテストスイートがあると嬉しいです。問題は、そのようなスイートは pgpoo-II 自身だけでなく複数の PostgreSQL インスタンスも含めるべきなので、とても複雑なシステムになってしまうということです。watchdog のことも忘れてはいけません。そのようなテストスイートであっても、複数の pgpool-II インスタンスを扱えるようにしなければいけません。

@@ 24行目: / 24行目: @@
 : ドキュメントによると、 pgpool-II はマルチステートメントなクエリ (BEGIN;SELECT 1;END) を認識しません。 Pgpool-II は 最初のクエリ（この場合は "BEGIN"）だけをパースし、処理を決定します。
 : もちろん、これは様々の問題を引き起こすでしょう。pgpool-II がマルチステートメントなクエリの各要素を理解できるようになると嬉しいです。
+: 実装上の問題は、マルチステートメントのバックエンドでの扱いにあります。たとえば、BEGIN;SELECT 1;ENDに対してバックエンドは、BEGIN、SELECT、ENDに対してそれぞれCommand Completeを返しますが、Ready for queryは最後に1度しか返しません。したがって、psqlのように単純にBEGIN, SELECT 1, END を分解しただけではうまく処理できません。
 ===  レプリケーションモード時に、カーソルの宣言がロードバランスされずに全ての DB ノードに送信される ===