<div dir="ltr">Right, so I may have been too fast to give up. I set maintenance mode back on and promoted ph-sql-04 manually. Unfortunately I don't have the logs of ph-sql-03 anymore because I reinitialized it. <div><br></div><div>You mention that demote timeout should be start timeout + stop timeout. Start/stop are 60s, so that would mean 120s for demote timeout? Or 30s for start/stop?</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 14 Jun 2019 at 15:55, Jehan-Guillaume de Rorthais <<a href="mailto:jgdr@dalibo.com">jgdr@dalibo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 14 Jun 2019 13:18:09 +0200<br>
Tiemen Ruiten <<a href="mailto:t.ruiten@rdmedia.com" target="_blank">t.ruiten@rdmedia.com</a>> wrote:<br>
<br>
> Thank you, useful advice!<br>
> <br>
> Logs are attached, they cover the period between when I set<br>
> maintenance-mode=false till after the node fencing.<br>
<br>
Switchover started @ 09:51:43<br>
<br>
In fact, the action that timed out was the demote action, not the stop<br>
action:<br>
<br>
  pgsqld_demote_0:31997 - timed out after 30000ms<br>
<br>
As explained, the demote is doing a stop/start because PgSQL doesn't support hot<br>
demotion. So your demote action should be stop timeout+start timeout. I would<br>
recommend 60s there instead of 30s.<br>
<br>
After Pacemaker decide what to do next, you had some more timeouts. I supose<br>
PgSQL logs should give some more explanation of what happen during these long<br>
minutes<br>
<br>
  pgsqld_notify_0:37945 - timed out after 60000ms<br>
  ...<br>
  pgsqld_stop_0:7783 - timed out after 60000ms<br>
<br>
It is 09:54:16. Now pengine become angry and want to make sure pgsql is stopped<br>
on node 03:<br>
<br>
  pengine:  warning: unpack_rsc_op_failure:   Processing failed stop of pgsqld:1<br>
    on ph-sql-03: unknown error | rc=1<br>
  ...<br>
  pengine:  warning: pe_fence_node:   Cluster node ph-sql-03 will be fenced:<br>
    pgsqld:1 failed there<br>
  ...<br>
  pengine:  warning: stage6:  Scheduling Node ph-sql-03 for STONITH<br>
  ...<br>
  pengine:   notice: native_stop_constraints: Stop of failed resource pgsqld:1<br>
    is implicit after ph-sql-03 is fenced<br>
<br>
<br>
>From there node 03 is down for 9 minutes, it comes back at 10:02:59.<br>
<br>
Meanwhile, @ 09:54:29, node 5 took over the DC role and decided to promote pgsql<br>
on node 4 as expected.<br>
<br>
The pre-promote notify actions are triggered, but at 09:55:24, the<br>
transition is canceled because of maintenance mode:<br>
<br>
  Transition aborted by cib-bootstrap-options-maintenance-mode doing modify<br>
   maintenance-mode=true<br>
<br>
Soon after, both notify actions timed out on both nodes:<br>
<br>
  warning: child_timeout_callback:  pgsqld_notify_0 process (PID 38838) timed<br>
  out<br>
<br>
Not sure what happen on your side that could explain these timeouts, but<br>
because the cluster was in maintenance mode, there was a human interaction<br>
ingoing anyway.<br>
<br>
<br>
<br>
<br>
<br>
<br>
> On Fri, 14 Jun 2019 at 12:48, Jehan-Guillaume de Rorthais <<a href="mailto:jgdr@dalibo.com" target="_blank">jgdr@dalibo.com</a>><br>
> wrote:<br>
> <br>
> > Hi,<br>
> ><br>
> > On Fri, 14 Jun 2019 12:27:12 +0200<br>
> > Tiemen Ruiten <<a href="mailto:t.ruiten@rdmedia.com" target="_blank">t.ruiten@rdmedia.com</a>> wrote:  <br>
> > > I setup a new 3-node PostgreSQL cluster with HA managed by PAF. Nodes are<br>
> > > named ph-sql-03, ph-sql-04, ph-sql-05. Archive mode is on and writing<br>
> > > archive files to an NFS share that's mounted on all nodes using  <br>
> > pgBackRest.  <br>
> > ><br>
> > > What I did:<br>
> > > - Create a pacemaker cluster, cib.xml is attached.<br>
> > > - Set maintenance-mode=true in pacemaker  <br>
> ><br>
> > This is not required. Just build your PgSQL replication, shut down the<br>
> > instances, then add the PAF resource to the cluster.<br>
> ><br>
> > But it's not very important here.<br>
> >  <br>
> > > - Bring up ph-sql-03 with pg_ctl start<br>
> > > - Take a pg_basebackup on ph-sql-04 and ph-sql-05<br>
> > > - Create a recovery.conf on ph-sql-04 and ph-sql-05:<br>
> > ><br>
> > > standby_mode = 'on'<br>
> > > primary_conninfo = 'user=replication password=XXXXXXXXXXXXXXXX<br>
> > > application_name=ph-sql-0x host=10.100.130.20 port=5432 sslmode=prefer<br>
> > > sslcompression=0 krbsrvname=postgres target_session_attrs=any'<br>
> > > recovery_target_timeline = 'latest'<br>
> > > restore_command = 'pgbackrest --stanza=pgdb2 archive-get %f "%p"'  <br>
> ><br>
> > Sounds fine.<br>
> >  <br>
> > > - Bring up ph-sql-04 and ph-sql-05 and let recovery finish<br>
> > > - Set maintenance-mode=false in pacemaker<br>
> > > - Cluster is now running with ph-sql-03 as master and ph-sql-04/5 as  <br>
> > slaves  <br>
> > > At this point I tried a manual failover:<br>
> > > - pcs resource move --wait --master pgsql-ha ph-sql-04<br>
> > > Contrary to my expectations, pacemaker attempted to stop psqld on<br>
> > > ph-sql-03.  <br>
> ><br>
> > Indeed. PostgreSQL doesn't support hot-demote. It has to be shut downed and<br>
> > started as a standby.<br>
> >  <br>
> > > This took longer than the configured timeout of 60s (checkpoint<br>
> > > hadn't completed yet) and the node was fenced.  <br>
> ><br>
> > 60s of checkpoint during a maintenance window? That's important indeed. I<br>
> > would<br>
> > command doing a manual checkpoint before triggering the move/switchover.<br>
> >  <br>
> > > Then I ended up with<br>
> > > ph-sql-04 and ph-sql-05 both in slave mode and ph-sql-03 rebooting.<br>
> > ><br>
> > >  Master: pgsql-ha<br>
> > >   Meta Attrs: notify=true<br>
> > >   Resource: pgsqld (class=ocf provider=heartbeat type=pgsqlms)<br>
> > >    Attributes: bindir=/usr/pgsql-11/bin pgdata=/var/lib/pgsql/11/data<br>
> > > recovery_template=/var/lib/pgsql/recovery.conf.pcmk<br>
> > >    Operations: demote interval=0s timeout=30s (pgsqld-demote-interval-0s)<br>
> > >                methods interval=0s timeout=5 (pgsqld-methods-interval-0s)<br>
> > >                monitor interval=15s role=Master timeout=10s<br>
> > > (pgsqld-monitor-interval-15s)<br>
> > >                monitor interval=16s role=Slave timeout=10s<br>
> > > (pgsqld-monitor-interval-16s)<br>
> > >                notify interval=0s timeout=60s (pgsqld-notify-interval-0s)<br>
> > >                promote interval=0s timeout=30s  <br>
> > (pgsqld-promote-interval-0s)  <br>
> > >                reload interval=0s timeout=20 (pgsqld-reload-interval-0s)<br>
> > >                start interval=0s timeout=60s (pgsqld-start-interval-0s)<br>
> > >                stop interval=0s timeout=60s (pgsqld-stop-interval-0s)<br>
> > ><br>
> > > I understand I should at least increase the timeout of the stop operation<br>
> > > for psqld, though I'm not sure how much. Checkpoints can take up to 15<br>
> > > minutes to complete on this cluster. So is 20 minutes reasonable?  <br>
> ><br>
> > 20 minutes is not reasonable for HA. 2 minutes is for manual procedure.<br>
> > Timeout are here so the cluster knows how to react during unexpected<br>
> > failure.<br>
> > Not during maintenance.<br>
> ><br>
> > As I wrote, just add a manual checkpoint in your switchover procedure<br>
> > before<br>
> > the actual move.<br>
> >  <br>
> > > Any other operations I should increase the timeouts for?<br>
> > ><br>
> > > Why didn't pacemaker elect and promote one of the other nodes?  <br>
> ><br>
> > Do you have logs of all nodes during this time period?<br>
> ><br>
> >  <br>
> <br>
<br>
<br>
<br>
-- <br>
Jehan-Guillaume de Rorthais<br>
Dalibo<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Tiemen Ruiten<br>Systems Engineer<br>R&D Media<br></div></div>