[pgpool-general: 3007] Re: pcp_promote_node usecase?

[James Sewell]

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_nodecommand.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20140707/87a27457/attachment-0001.html>