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

Yugo Nagata nagata at sraoss.co.jp
Wed Aug 20 20:38:37 JST 2014


Hi Joey,

Thank you for sending the patch. However, we can't accept this
due to the folowing reasons.

- For backward compatibility, we can't change behavior of
  pcp_promote_command directly.
- trigger_failover_command() can't assure that the specified node becomes
  primary, since it is depended on the failover script.
- When watchdog is used, failover command must be inter-locked between
  pgpools.

Best regards,

On Tue, 12 Aug 2014 08:13:19 +0200
Joey <joey at binbash.org> wrote:

> Hi Yugo,
> 
>  
> 
>  
>  
> 
> In my case I use pcp_promote_node to also manage/failover my Postgres master-slave streaming-replication cluster backend nodes.
> 
>  
> 
> I wrote a small patch to accomplish this:
> 
>  
> 
>  
>  
> 
> --- main.c.orig 2014-08-06 11:23:28.407919835 +0200
> 
> 
>  
> 
> +++ main.c  2014-08-06 11:25:34.034290079 +0200
> 
>  
> 
> @@ -1820,6 +1820,9 @@
> 
>  
> 
>             pool_log("starting promotion. promote host %s(%d)",
> 
>  
> 
>                      BACKEND_INFO(node_id).backend_hostname,
> 
>  
> 
>                      BACKEND_INFO(node_id).backend_port);
> 
>  
> 
> +
> 
>  
> 
> +           trigger_failover_command(PRIMARY_NODE_ID, pool_config->failover_command, 
> 
>  
> 
> +                                       MASTER_NODE_ID, node_id, PRIMARY_NODE_ID);
> 
>  
> 
>         }
> 
>  
> 
>         else
> 
>  
> 
>         {
> 
>  
> 
>  
>  
> 
> This patch is build against pgpool-II-pg93 version 3.3.2 (I'm using the rpm's from the postgres.org yum repos and patched the source rpm).
> 
>  
> 
>  
>  
> 
> As you can see it only creates the trigger file on the new master node. My slave is configured as a hot-standby so it's read-only and needs to be set in the master (read/write) state.
> 
>  
> 
>  
>  
> 
> So I think it's nice to include this in a future version of pgpool and make it configurable in pgpool.conf?
> 
>  
> 
>  
>  
> 
> Kind regards,
> 
>  
> 
>  
>  
> 
> Joey Loman
> 
>  
> 
>  
>  
> 
>>  
> 
> > 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>
> 


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


More information about the pgpool-hackers mailing list