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

[Joey]

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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20140812/ba224954/attachment.html>