[pgpool-general: 3019] Re: pcp_promote_node usecase?
nagata at sraoss.co.jp
Fri Jul 11 16:23:17 JST 2014
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:
> I have some clients who are currently using pcp_promote_node with
> 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.
> 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>
More information about the pgpool-general