Aw: Re: PostgreSQL replication failover - Mailing list pgsql-admin

From Jan Peters
Subject Aw: Re: PostgreSQL replication failover
Date
Msg-id trinity-e6fa27b2-28d5-45c1-ad43-cec60dd0b089-1611043948302@3c-app-gmx-bap08
Whole thread Raw
In response to Re: PostgreSQL replication failover  (John Wiencek <jwiencek3@comcast.net>)
Responses Re: Re: PostgreSQL replication failover
List pgsql-admin
Hi John,

I can't find any s390 packages for repmgr :-(



> Gesendet: Donnerstag, 14. Januar 2021 um 16:03 Uhr
> Von: "John Wiencek" <jwiencek3@comcast.net>
> An: "Jan Peters" <haseningo@gmx.de>
> Cc: "Ganesh Korde" <ganeshakorde@gmail.com>, "Pepe TD Vo" <pepevo@yahoo.com>, "Pgsql-admin"
<pgsql-admin@lists.postgresql.org>,"Laurenz Albe" <laurenz.albe@cybertec.at> 
> Betreff: Re: PostgreSQL replication failover
>
> Hi
>
> You can use repmgr, which is free,  or EFM which requires a subscription.
>
> John
>
> > On Jan 14, 2021, at 2:16 AM, Jan Peters <haseningo@gmx.de> wrote:
> >
> > Hello,
> >
> > thank you very much for the answers.
> > Can you tell me some tools, but they must be available for s390 ZLinux.
> > For our purposes in redhat linux
> >
> >
> > Gesendet: Mittwoch, 13. Januar 2021 um 19:46 Uhr
> > Von: "Ganesh Korde" <ganeshakorde@gmail.com>
> > An: "Pepe TD Vo" <pepevo@yahoo.com>
> > Cc: "Jan Peters" <haseningo@gmx.de>, pgsql-admin@lists.postgresql.org, "Laurenz Albe" <laurenz.albe@cybertec.at>
> > Betreff: Re: PostgreSQL replication failover
> >
> > You can use different tools which detects if primary fails and automatically promotes standby.
> >
> > To assure all data on standby you should use synchronous replication.
> >
> > On Wed, 13 Jan 2021, 6:54 pm Pepe TD Vo, <pepevo@yahoo.com[mailto:pepevo@yahoo.com]> wrote:
> >
> >>> If you shut down the primary server cleanly, all changes will be replicated,so you should be good.
> >
> >>> During a failover, that is, if the primary suddenly fails, there is always
> > the possibility that you lose some transactions, unless you use synchronous
> > you said above which I don't need to run promote to make it failover as long as I set synchronous on?   The last
coupleof weeks I have a failure on the primary server and can't run on a slave. It picks up as reading mode only. 
> >
> >
> > Bach-Nga
> >
> > No one in this world is pure and perfect.  If you avoid people for their mistakes you will be alone. So judge less,
love,and forgive more. 
> > To call him a dog hardly seems to do him justice though in as much as he had four legs, a tail, and barked, I admit
hewas, to all outward appearances. But to those who knew him well, he was a perfect gentleman (Hermione Gingold) 
> > **Live simply **Love generously **Care deeply **Speak kindly.
> > *** Genuinely rich *** Faithful talent *** Sharing success
> >
> >
> >
> >
> >
> > On Wednesday, January 13, 2021, 06:25:53 AM EST, Laurenz Albe
<laurenz.albe@cybertec.at[mailto:laurenz.albe@cybertec.at]>wrote: 
> >
> >
> >
> > On Wed, 2021-01-13 at 09:27 +0100, Jan Peters wrote:
> >> we are running postgresqlserver on s390 zLinux machines. The distribution
> >>   is RedHat 7 and RedHat 8, so we do not have the many x86 tools available.
> >>
> >> We always run 2 instances with a replication (streaming) async mode, the replica
> >>   is in hot_standby and we use it for read-only accesses. About the setup we have the following question:
> >>
> >> How is an orderly failover accomplished? Our current procedure is.
> >>
> >> 1. primary stop
> >> 2. promote replica to primary
> >> 3. create standby.signal on old primary
> >> 4. change primary_conninfo on old primary
> >> 5. start old primary as new replica
> >>
> >> Is this processing correct? Are there any other steps that simplify a failover?
> >>   How can we be sure that all changes have been transferred from the old master to the replica?
> >
> > What you describe is not a failover, but a switchover.
> >
> > If you shut down the primary server cleanly, all changes will be replicated,
> > so you should be good.
> >
> > During a failover, that is, if the primary suddenly fails, there is always
> > the possibility that you lose some transactions, unless you use synchronous
> > replication.
> >
> > Yours,
> > Laurenz Albe
> > --
> > Cybertec | https://www.cybertec-postgresql.com[https://www.cybertec-postgresql.com]
> >
> >
> >
> >
> >
>
>



pgsql-admin by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: hot standby in Postgresql 12
Next
From: Dominik Lehnen
Date:
Subject: Re: hot standby in Postgresql 12