AW: AW: AW: AW: broken backup trail in case of quickly patroniswitchback and forth - Mailing list pgsql-general

From Zwettler Markus (OIZ)
Subject AW: AW: AW: AW: broken backup trail in case of quickly patroniswitchback and forth
Date
Msg-id 5c019721473149aeabaaf7bd552f7e0d@zuerich.ch
Whole thread Raw
In response to Re: AW: AW: AW: broken backup trail in case of quickly patroni switchbackand forth  ("Brad Nicholson" <bradn@ca.ibm.com>)
Responses Re: AW: AW: AW: AW: broken backup trail in case of quickly patroniswitchback and forth
List pgsql-general

It depends. It is a switchover if Patroni could to a clean shutdown. But, it might start killing processes after a certain period if a normal shutdown after SIGTERM didn't happen. This would not be a switchover anymore. In other words there is no guarantee for a "clean" switchover. This might be the reason why the Patroni guys are always talking about failover only.

 

It's not a Patroni issue but it's triggered by Patroni as it will do "some kind of switchover" on a regular shutdown.

 

 

"Zwettler Markus (OIZ)" <Markus.Zwettler@zuerich.ch> wrote on 2019/11/07 11:32:42 AM:

> From: "Zwettler Markus (OIZ)" <
Markus.Zwettler@zuerich.ch>
> To: Adrian Klaver <adrian.klaver@aklaver.com>, "pgsql-
>
general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
> Date: 2019/11/07 11:33 AM
> Subject: [EXTERNAL] AW: AW: AW: broken backup trail in case of
> quickly patroni switchback and forth

>
> 3)
> Patroni does only failovers.
Also in case of regular shutdown of the
> primary. A failover is a promote of the standby + automatic
> reinstate (pg_rewind or pg_basebackup) of the former primary.


This is not accurate.  Patroni does controlled switchovers as well as failovers.  Controlled switchover issues a fast shutdown to Postgres, hard ones issue an immediate shutdown.  From this point, it's how Postgres responds to those that matter.  

Fast shutdown will attempt to ensure the wal stream is transmitted to the replica and the wal files are archived.  Immediate shutdown will not do any of this.  This issue explains more about when Patroni may choose an immediate shutdown (it might not be totally accurate anymore as it's a year old).

https://github.com/zalando/patroni/issues/837#issuecomment-433686687


I agree with the Patroni folks that this is not a Patroni issue, but simply how Postgres responds to the required shutdown types.

pgsql-general by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: INOUT PARAMETERS WITH RETURN TABLES IN FUNCTION
Next
From: SERHAD ERDEM
Date:
Subject: Re: SQL SERVER migration to PostgreSql