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: