<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 5, 2021 at 5:38 PM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> Hi all,<br>
> <br>
> I'm busy upgrading to postgres 13 and pgpool 4.1.4, and as part of that<br>
> reworking some of our scripts and improving some of our operational<br>
> procedures.<br>
> <br>
> I'd like to have a way to promote a specific backend to primary, and have<br>
> the old primary use pg_rewind, then connect to the new primary.<br>
> <br>
> I'm using scripts largely based on the samples, though without<br>
> pg_basebackup as a fallback to pg_rewind - our thinking is if pg_rewind<br>
> fails, we want to leave it in the current state and investigate, then<br>
> restore manually.<br>
> <br>
> I can run pcp_detach_node to almost achieve this controlled primary<br>
> failover, but it doesn't let me specify which primary to fail over to.<br>
> pcp_promote_node explicitly says it's only about internal pgpool state, and<br>
> it runs follow_master_command, but not failover_command.<br>
> <br>
> Is there a way to achieve this in pgpool at the moment?<br>
<br>
I think what you can do for that today is:<br>
<br>
1) create a file telling which node to be promoted when currect primary goes down.<br>
<br>
2) failover_command reads the file and promotes the specified node.<br>
<br>
Of course this is kind of a quick and dirty way. I think we would want<br>
to have better way.<br></blockquote><div><br></div><div>Ah - I had not thought of this option. However, doesn't failover_command get told what the new primary will be, rather than being able to decide this itself (%m %H %r %R)? Or, are you thinking that failover_command can run pcp_promote_node and override whatever failover_command is told to do? Can you run pcp_promote_node etc. while a backend failover is in progress?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> If not, could we<br>
> put together a new feature / command to achieve this? (Happy to contribute<br>
> code, if this is something that would be useful).<br>
> Thinking:<br>
> 1) Detach old primary<br>
> 2) Run failover_command on the new primary<br>
> 3) Run follow_master_command on the standbys (including the old primary,<br>
> which gets reattached by the script)<br>
> <br>
> Perhaps this is an extra flag on pcp_promote_node which causes<br>
> failover_command to run?<br>
<br>
I think an ability to tell failover_command to promote specific<br>
standby is more flexible because this way, both pcp_detach_node and<br>
failover (caused by node down) can use the information.  For this<br>
purpose we could have a new pcp command or new pgpool.conf<br>
parameter.<br>
<br>
With this change you can do:<br>
<br>
1) explicitly specify the new primary node<br>
<br>
2) run pcp_detach_node against the current primary and the current<br>
   primary nodes goes into down status<br>
<br>
3) failover_command will run to make the specified standby node to be<br>
   new primary<br>
<br>
4) follow_primary_command will run on rest of standbys and the old<br>
   primary to follow the new primary</blockquote><div><br></div><div>I think this would work yes - which is very close to what I was suggesting with a flag on pcp_promote_node. If this requires 2 commands (pcp_set_next_primary or something, then pcp_detach_node) I would wrap them in a single script which runs both in order to keep things simple and fast for our operations team.</div><div><br></div><div>--</div><div>Nathan Ward</div></div></div>