Re: [External] Re: WAL Replication query

On Tue, Nov 1, 2022 at 7:26 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:

> On Tue, 2022-11-01 at 08:49 -0500, Ron wrote:
> > Primary has crashed, according to OP; it's not coming back any time
> soon. And thus you promote
> > Secondary to be New Primary, and go about your work. When the Old
> Primary comes back up
> > (hours or days later), you do a pg_basebackup to make it the New
> Secondary.
>
> There was no word about failover or "not coming back any time soon"
> (that's why I asked for
> clarification in my answer). In fact, PostgreSQL will often undergo crash
> recovery and come
> back up automatically. See the parameter "restart_after_crash", which
> defaults to "on".
>
> Sorry, It was my mistake not to mention the failover to the Standby
required.

I mean when the Primary Server crashes due to a H/W failure or whatever
other reason, Then in my case I am forced to promote the Standby
server as Primary until the old primary server H/W vendor replaces the
hardware component( it may vary from hours to days as pre SLA terms with
H/W vendor).

In this scenario any transactions happened in crashed Primary server
which were not transferred due to the delay in transfer to the Standby
server. But I am in need to promote the Standby to Primary and it will
run for another one day or two, until my Old crashed server failed
component is replaced with a new H/W part.

So there will be an inconsistency in the data between the current
Primary ( promoted standby) and my recovered /repaired old server ( which
was primary before the crash).

How to handle this data inconsistency or what best mechanism needs to be
implemented if you were me in this use case scenario?

> Yours,
> Laurenz Albe
>
>
>