[pgpool-hackers: 582] Re: [pgpool-general: 2973] pcp_promote_node usecase?

[Yugo Nagata]

Hello, 

Thanks for yor information!

Ok, pcp_promote_node is used with other cluster software and
DISALLOW_TO_FAILOVER. Failover is not managed by pgpool-II
but pcp_promote_node is used for fencing the old master,
since this can detach nodes even when DISALLOW_TO_FAILOVER is used.

In this case, is follow_master command used or not and how if used?

On Mon, 7 Jul 2014 16:45:06 +1000
James Sewell <james.sewell at lisasoft.com> wrote:

> Hello,
> 
> I have some clients who are currently using pcp_promote_node with
> DISALLOW_TO_FAILOVER.
> 
> They have a two node PostgreSQL cluster which is managed by EnterpriseDB's
> PPFM (Postgres Plus Failover Manager). This is a requirement.
> 
> When a failover happens and PPFM promotes the new slave it fences the old
> master with the pcp_promote_node command.
> 
> This is desirable because
> 
>    1. It detaches the old master
>    2. It promotes the promotion target to master
>    3. It does not block while searching for the new master (as would occur
>    with pcp_detach_node)
> 
> After pcp_promote_node is called, the PostgreSQL failover occurs. This does
> mean a short period in which the pgpool master is not promoted, but this
> seems to be tolerated by the software.
> 
> Cheers,
> 
> 
> 
> James Sewell,
> PostgreSQL Team Lead / Solutions Architect
> ______________________________________
> 
> 
>  Level 2, 50 Queen St, Melbourne VIC 3000
> 
> *P *(+61) 3 8370 8000  *W* www.lisasoft.com  *F *(+61) 3 8370 8099
> 
> 
> 
> On Thu, Jun 26, 2014 at 4:54 PM, Yugo Nagata <nagata at sraoss.co.jp> wrote:
> 
> > Hi all,
> >
> > Are you using pcp_promote_node? If so, please tell me your usecase!
> >
> > pgpool-II has pcp_promote_node command, which change specified backend
> > nodes status to 'primary', but this has some problems.
> > So, if there is no users of pcp_promote_node, we consider to remove
> > this from pgpool-II. Or not, I want to know usecases and fix
> > pcp_promote_node to be more usefull and suitable for the usecase.
> >
> > The current pcp_promote_node works as below;
> >
> > (0) This is enabled only in master-slave / streaming-replication mode.
> >
> > (1) This changes pgpool-II's internal status and set the specified
> >     node to primary. The internal status is used in online-recovery
> >     and loadbalancing etc..
> > ** Note that this doesn't control the backend nodes themselves.**
> >
> > (2) All nodes other than the new primary are detached from pgpool-II.
> >
> > (3) pgpool-II execute follow_master command for all the detached nodes.
> >     follow_master command is mainly used for auto-recovery of standbys
> >     from the new primary.
> >
> > Here, I found the some problems:
> >
> > (a) Even when DISALLOW_TO_FAILOVER is used, backends node are detached
> >     at step (2).
> > (b) If pcp_recovery_node is executed in follow_master command at step (3),
> >     recovery can fail because pgpool-II's internal status can be different
> >     from the acutual backend status of primary/standby.
> >
> > I want to fix about (a), if there is any user of pcp_promote_node.
> > I think the design would be:
> >  - When DISALLOW_TO_FAILOVER is used, pcp_promote_node is disabled
> >    because this command can detach some backend nodes.
> >  - or, pcp_promote_node change primary node status, but doesn't detach
> >    any nodes. (In this case, some trick would be required so that
> >    primary node should be unique.)
> >
> > About (b), I think this is a restriction of pgpool-II. User have
> > to note that internal status can be different from the acutual backend
> > status of primary/standby, after using pcp_promote_node. If you know
> > other idea, please tell me.
> >
> > Any comment and suggestion?
> >
> >
> > Best regards,
> > --
> > Yugo Nagata <nagata at sraoss.co.jp>
> > _______________________________________________
> > pgpool-general mailing list
> > pgpool-general at pgpool.net
> > http://www.pgpool.net/mailman/listinfo/pgpool-general
> >
> 
> -- 
> 
> 
> ------------------------------
> The contents of this email are confidential and may be subject to legal or 
> professional privilege and copyright. No representation is made that this 
> email is free of viruses or other defects. If you have received this 
> communication in error, you may not copy or distribute any part of it or 
> otherwise disclose its contents to anyone. Please advise the sender of your 
> incorrect receipt of this correspondence.


-- 
Yugo Nagata <nagata at sraoss.co.jp>