「TODO」の版間の差分

提供: pgpool Wiki
移動先: 案内、 検索
(→‎Cursor statements are not load balanced, sent to all DB nodes in replication mode)
(マルチステートメントクエリ実装上の問題を追記。)
 
(3人の利用者による、間の18版が非表示)
1行目: 1行目:
 
__FORCETOC__
 
__FORCETOC__
  
−
== Pgpool-II TODO list ==
+
== Pgpool-II TODO リスト ==
  
−
=== Ability to load balance based on Client IP ===
+
=== クライアント IP に基づいたロードバランスができるようにしてほしい ===
−
: From bugid 26:  I have recently moved a database from Mysql to postgresql 9.1.5 which is behind a pgpool-II-3.1.4 . Everything went fine until i observed that some "tickets" are not created correctly by the application (OTRS) that populate the database.
+
:bugtrack #26:  私は最近 Mysql から pgpool-II-3.1.4 を利用した PostgreSQL 9.1.5 にデータベースを移行しました。データベースにデータを投入するアプリケーション (OTRS) が、ある「チケット」を正確に作成していないことを私が発見をするまで、全てはうまくいっていました。
−
: After some debugging i found/guess that the problem is the following:
+
: いくつかのデバッグの後、私は問題は以下の通りであると推測しました。
−
: when a cron job wants to create a ticket he has to insert info in abut 10 tables, and i guess that the 2-nd, 3-rd ... inserts depends on the first. The problem was that this operation is not performed transactionally so after the first insert, when the app tries to perform the other inserts, first tries to select "the first insert", but this first insert is still not propagated to all nodes, and the error occurs.
+
: cron ジョブがチケットを作成しようとすると、そのジョブは 10 前後のテーブルに情報をインサートする必要があります。そして、私は 2 番目、 3 番目以降のインサートは、 1 番目の処理に依存しているのではないかと思います。問題は、この操作がトランザクションに則していないないということです。そのため、 1 番目のインサートの後にアプリケーションが残りのインサートを実行しようと試みた時に、はじめに「1 番目のインサート」を参照しようとします。しかし、 1 番目のインサートはまだすべてのノードに伝搬しておらず、エラーが発生するのです。
−
: I`m aware of the fact that if this entire operation would be performed transactionally (only on master) the issue is solved, but unfortunately i cannot modify the app.
+
: そこで、私は pgpool に対して、「この IP からはどんなリクエストもロードバランスしない」といったような何らかの伝達手段があるかどうか知りたいです。
−
: So i want to know if there is any way that i can tell to pgpool something like :
+
: 追伸、一時的に私は荷重因子を 2 番目と 3 番目の PostgreSQL サーバに設定しました。マスターのみから読み書きが行われるので問題なく動作しています。
−
: any request from this ip do not load balance.
 
  
−
: PS. temporary i have set the weight factor to 0 to the 2-nd and 3-rd postgresql slaves and it behaves ok, because reads and writes only from master.
+
=== ストリーミングレプリケーションの master/slave モードの設定でノードを自動的に再アタッチしてほしい ===
 +
:bugtrack #17: ストリーミングレプリケーションの master/slave モードの設定に、ノートがマスターの最新状態 (0 bytes behind) であったら、自動的にノードが再アタッチできるようなオプションがあると良いかもしれません。小規模ネットワークの停止によって、スレーブノードが pgpool から切り離されたままスレーブノードがマスターと同期して最新状態になっていることがよくあります。pgpool はすでにマスターの背後に何台のスレーブが存在するか分かっているので、それほど困難な改良ではないと思われますが？
  
−
=== Restart watchdog process when it abnormaly exits ===
+
=== クライアントエンコーディングが使えるようにしてほしい ===
−
: It would be nice for pgpool main to restart watchdog process when it dies abormaly.
+
: pgpool に接続するクライアントが PostgreSQL サーバと異なるエンコーディングを使えたら嬉しいです。
−
: (Nagata is working on this for pgpool-II 3.3)
+
: この改良を行うためには、パーサーが Shift_JIS のような安全でないエンコーディングを扱えるようにする必要があります。psql は各マルチバイト文字の 2 バイト目を変換してパーサーに渡しています。私達はこの戦略を利用することができます。
  
−
=== Automatically reattach a node in streaming master/slave configuration ===
+
=== フェイルオーバー後であっても、参照クエリをスタンバイのみに送信できるようにしてほしい ===
−
:In streaming master/slave configuration there could be an option to automatically reattach a node if it's up-to-date with the master (0 bytes behind). It often happens that due to minor network outage a slave node is dropped off from pgpool and stays down even if the the node has resumed replication with master and is up-to-date.pgpool already knows how much slave is behind master so i guess this wouldn't be too difficult to implement? (from bugtrack #17)
+
: 私達は pgpool-II が参照クエリをプライマリに送信しないように設定できます。しかしながら、フェイルオーバー後では、ノードの役割が変わってしまうことがあります。
 +
: この問題を解決するには、フェイルオーバーの発生に関係なく、スタンバイに参照クエリを送信するようにする新しいフラグが必要です ([pgpool-general: 1621] backend weight after failover) 。
  
−
=== Synchronize backend nodes information with watchdog when standby pgpool starts up ===
+
=== マルチステートメントなクエリを認識してほしい ===
−
: For example, when a certain node is detached from active pgpool and then standby pgpool starts up, the standby pgpool can't recognized that the node is detached. Standby pgpool should get information about node information from other pgpool.
+
: ドキュメントによると、 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 を分解しただけではうまく処理できません。
  
−
=== Avoid multiple pgpools from executing failover.sh simultaneously. ===
+
===  レプリケーションモード時に、カーソルの宣言がロードバランスされずに全ての DB ノードに送信される ===
−
: In master-slave mode with watchdog, when a backend DB is down, all pgpools execute failover.sh. It might cause something wrong.
+
: レプリケーションモード時に DECLARE..FETCH が全ての DB ノードに送信されます。これは SELECT 文に FOR UPDATE/FOR SHARE が付いているからでしょう。
−
: (Nagata is working on this for pgpool-II 3.3)
+
: pgpool-II が SELECT 文に FOR UPDATE/FOR SHARE が使われているかどうかを確認し、使われてなければロードバランスを行う（もしくはロードバランスを使用不可にしていたらマスターノードのみに送信する）ようになると嬉しいです。
 +
: psql を含んだアプリケーションは SELECT 文にカーソルを使うことができることに注意してください。例えば、PostgreSQL 8.2 からは "\set FETCH_COUNT n" が実行されると psql は無条件に "_psql_cursor" というカーソルを使います。
  
−
=== Allow to use client encoding ===
+
=== IPV6 ネットワークをサポートしてほしい ===
−
:It would be nice if pgpool client could use encoding which different from PostgreSQL server encoding.
+
: これは当然のリクエストです。
−
: To implement this, the parser should be able to handle "unsafe" encodings such as Shift_JIS. psql replaces second byte of each multibyte character to fool the parser. We could hire similar strategy.
 
  
−
=== Send read query only to standbys even after fail over ===
+
=== PostgreSQL の例外処理をインポートしてほしい ===
−
: We can configure pgpool-II to not send read queries to the primary. However after a fail over, the role of the node could be changed.
+
: PostgreSQL の例外処理 (elog family) は、コードをシンプルで頑強にできるとても良いツールです。 pgpool もこれが使えるようになると嬉しいです。
−
: To solve the problem, we need new flag to specify that read queries always are sent to standbys regardless the fail over ([pgpool-general: 1621] backend weight after failover).
 
  
−
=== Recognize multi statemnet queries ===
+
=== watchdog 有効時は仮想 IP インターフェースの不正ダウンに対応してほしい ===
−
: As stated in the document, pgpool-II does not recognize multi statement queries correctly (BEGIN;SELECT 1;END). Pgpool-II only parses the first element of the query ("BEGIN" in this case) and decides how to behave.
+
: 仮想 IP インターフェースが手動の ifconfig などによって不正に終了すると、VIP を操作することができなくなり、クライアントは pgpool-II に接続できなくなります。アクティブな pgpool の watchdog はインターフェースか VIP を監視し、不正な終了に対応すべきです。
−
: Of course this will bring various problems. It would be nice if we could understand the each part of the multi statement queries.
 
  
−
=== Cursor statements are not load balanced, sent to all DB nodes in replication mode ===
+
=== オンディスを用いたクエリキャッシュを削除してほしい ===
−
: DECLARE..FETCH are sent to all DB nodes in replication mode. This is because the SELECT might come with FOR UPDATE/FOR SHARE.
+
: ディスクを用いたクエリキャッシュはほとんど誰も使っておらず、キャッシュの無効化が自動でないといった厳しい制限があります。オンメモリクエリキャッシュが実装されたので、この機能はもはや時代遅れです。私達はこの機能を削除すべきです (これは git のマスターブランチに存在しており、 3.4.0 でも現れるでしょう）。
−
: It would be nice if pgpool-II checks if the SELECT uses FOR UPDATE/FOR SHARE and if not, enable load balance (or only sends to the master node if load balance is disabled).
 
−
: Note that some applications including psql could use CURSOR for SELECT. For example, from PostgreSQL 8.2, if "\set FETCH_COUNT n" is executed, psql unconditionaly uses a curor named "_psql_cursor".
 
  
−
=== Support IPV6 network ===
+
=== 特定の場合では、トランザクション内で作成されたクエリキャッシュを無効にすべきではない ===
−
: This is an obvious requirement.
+
: あるトランザクション内で作成されたテーブル 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 インスタンスを扱えるようにしなければいけません。

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 インスタンスを扱えるようにしなければいけません。
「https://pgpool.net/mediawiki/jp/index.php?title=TODO&oldid=576」から取得