[pgpool-general-jp: 1361] Re: エラー時に無応答のケースについて

[近藤]

こちらで詳細に調査を行ってみました。システム内の仕様のズレが原因と思います。

レプリケーション load_balance  ON    replicate_select OFF の場合です。

・select クエリの行き先を決める場所

トランザクション内部でも、条件を満たせばロードバランス、満たさなければマスターのみに送付。


・エラー発生時の処理

トランザクション内部の場合かつ select
の場合、他のノードでもトランザクション処理を失敗させるためにエラーになる処理を実行。しかし、その際の他のノードの決定方法が、「マスターノード以外」になっています。

POOL_STATUS raise_intentional_error_if_need(POOL_CONNECTION_POOL *backend)
{
（中略）

        if (REPLICATION &&
                TSTATE(backend, REAL_MASTER_NODE_ID) == 'T' &&
                !pool_config->replicate_select &&
                query_context &&
                is_select_query(query_context->parse_tree,
query_context->original_query))
        {
                pool_setall_node_to_be_sent(query_context);
                for (i = 0; i < NUM_BACKENDS; i++)
                {
                        if (VALID_BACKEND(i) && REAL_MASTER_NODE_ID != i)
                        {
                                /*
                                 * We must abort transaction to sync
transaction state.
                                 * If the error was caused by an Execute
message,
                                 * we must send invalid Execute message to
abort
                                 * transaction.
                                 *
                                 * Because extended query protocol ignores
all
                                 * messages before receiving Sync message
inside error state.
                                 */

（後略）


そのため、begin後にマスター以外にselect が送られて、何らかのエラーとなった場合、間違った宛先にエラー処理が起動され、無応答となります。


以上
-------------- next part --------------
HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
URL: <http://www.sraoss.jp/pipermail/pgpool-general-jp/attachments/20150309/fee10f1f/attachment-0001.html>