[pgpool-general: 6571] Re: Pgpool Info Required

[Lakshmi Raghavendra]

1. failover_command : this will usually be a shell script. The script will
do a standby promote on new master, so there is no reason that it would
fail and I believe it is over-engineering to do more than that. But since
this is a script, you are free to put what you want in it : if you want to
check the result of the standby promote and if it fails try on the third
node, it is possible. >* Yep understood thanks. But i was looking for more
of an automatic retry. *So if pgpool cannot promote a new postgres master
for some resaon and failover failed, i was expecting it to promote other
nodes that are avialable in the quorum 2. pgpool does not support
switch-over, you would have to stop the primary postgres database and let
pgpool trigger the failover and then run a pcp_recovery on the old primary
postgres >* Ok. So the reason behind the ask was if pgpool is not going to
retry the *promote on other nodes, I was thinking i can just trigger a
force promote there by failover and follow master will be run by pgpool
itself and i dont have to do a failover by myself and run pcp_recovery on
all the nodes Regarding 5. It's normal. Don't worry. When a standby
PostgreSQL node is added, existing connections to Pgpool-II are kept (thus
do not use the new standby for load balacing). After the session ends,
Pgpool-II child process checks whether the failback has happend. If
happend, exits itself so that new process is spwan to reflect the fact that
new standby node has been added (thus it can use the new standby for load
balancing). >* Thanks. Per my understanding, So restart happens only when a
new standby *is added is it. Because i see this frequent restarts happening
even when there is no fallback. Also could you please share some light on
when the failback_command gets executed? I have never seen the command
being called. Thanks And Regards, Lakshmi Y M

On Thu, May 23, 2019 at 10:03 AM Tatsuo Ishii <ishii at sraoss.co.jp> wrote:

> > Answers to some questions (just my ideas )
> > 1. failover_command : this will usually be a shell script. The script
> will do a standby promote on new master, so there is no reason that it
> would fail and I believe it is over-engineering to do more than that. But
> since this is a script, you are free to put what you want in it : if you
> want to check the result of the standby promote and if it fails try on the
> third node, it is possible.
> > 2. pgpool does not support switch-over, you would have to stop the
> primary postgres database and let pgpool trigger the failover and then run
> a pcp_recovery on the old primary postgres
> > 3. The VIP point to the pgpool master not to the postgres master. So
> application connects to pgpool, not to postgres.
> > 4. No, pgpool will not do anything when a failed standby comes back,
> this must be done manually or you could develop a script and schedule it
> via cron for example (it is a bit complex and it might be risky)
> > 5. No idea, sorry
> > Pierre
>
> Regarding 5. It's normal. Don't worry.
>
> When a standby PostgreSQL node is added, existing connections to
> Pgpool-II are kept (thus do not use the new standby for load
> balacing). After the session ends, Pgpool-II child process checks
> whether the failback has happend. If happend, exits itself so that new
> process is spwan to reflect the fact that new standby node has been
> added (thus it can use the new standby for load balancing).
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20190524/607ef76a/attachment-0001.html>