[pgpool-general: 3132] Re: I published an article about my pgpool2 setup

[Michael Stapelberg]

On Tue, Sep 2, 2014 at 1:28 AM, Tatsuo Ishii <ishii at postgresql.org> wrote:
>> Hey,
>>
>> after setting up pgpool2, I published an article about my setup:
>>
>> http://michael.stapelberg.de/Artikel/replicated_postgresql_with_pgpool
>>
>> I thought it’d be a nice gesture to point you to it, and I’d be happy
>> to correct any factual mistakes that are in the article.
>>
>> Thanks for your work on pgpool2,
>
> You are welcome.
>
> I took a look at your article.
>
> Your setting is interesting since you enable streaming replication of
> PostgreSQL and at the same time you run pgpool-II in replication
Note that I don’t enable streaming replication in PostgreSQL on a
permanent basis, it’s only used when recovering a node.

> mode. Is there any reason you do not use pgpool-II's streaming
> replication mode (which means master_slave_mode = on and
> master_slave_sub_mode = 'stream')?
The reason why I did not go for that mode originally is that I want
the flexibility to add a third node easily, and “master/slave” implied
that there can only be one master and one slave. Thinking about it, I
think this may not actually be true, so it’d be good if you could
clarify in your documentation whether there is a limit on the number
of nodes in that mode.

>
>> In order to recover node 1 (alp in this case), use:
>>
>> pcp_recovery_node 300 localhost 9898 postgres wQgvBEusf1NWDRKVXS15Fc8 1
>>
>> Where 300 is the timeout for the entire recovery, so perhaps you need to increase that.
>
> Actually there will be no effect no matter how you set the timeout. We
> decided to ignore the timeout parameter of pcp command long time
> ago. But for backward compatibility, we still keep on having the
> parameter.
Ah, thank you for clarifying that. I updated the article.

>
> As for timeout of recovery, PostgreSQL's "statement_timeout" is more
> crucial since the recovery process is executed in a C function, which
> runs in a SELECT on the master PostgreSQL. In the git head (including
> master and stable branches), pgpool-II executes "set statement_timeout
> to 0" to disable it and will appear in the next releases (we plan to
> release stable minor releases this week).
>
>> In case the recovery fails, the only thing you’ll get back from
>> pcp_recovery_node is the text “BackendError”, which is not very
>> helpful. The logfile of pgpool2 contains a bit more information, but
>> to debug recovery problems, I typically strace all PostgreSQL
>> processes and see what the scripts are doing/where they are failing.



-- 
Best regards,
Michael