Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kzg8G-0000fc-5x for pgsql-admin@arkaria.postgresql.org; Wed, 13 Jan 2021 13:24:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kzg8F-000474-34 for pgsql-admin@arkaria.postgresql.org; Wed, 13 Jan 2021 13:24:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kzg8E-00046x-L0 for pgsql-admin@lists.postgresql.org; Wed, 13 Jan 2021 13:24:14 +0000 Received: from sonic302-2.consmr.mail.bf2.yahoo.com ([74.6.135.41]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kzg8B-0008Bb-Gv for pgsql-admin@lists.postgresql.org; Wed, 13 Jan 2021 13:24:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610544248; bh=C7ixj4mtIX1Rhqr2dMAxp83E+HnuBoryq96xTlEMtsw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=O8VGH6VPfii0J5fFULzW4CYsmNTAZ/H5g1CRDTMNv06XM05rLmMv+7HYUEOax4jwRPDEKFLAHyGqgY2nsTTubspiYZ/EWDUGNKENAsa8LMTpFxdb/kxz5ARUASIPysD7+8eHZwGrY4ldvLS8MMMW430PctFHr4kfgVDxaUhvw7mgfjrCY36Q58eXvSRND+vnqdHtpCbfn2bwX+dF8SijXcEaL64sI+vYugoKFIkINihVz+vyVuddYwvSxdxNaSVgJ9wicB8oQHt0KPldiryJXuS9sIy6f5Mx/rwDeI/cLLt9i8Xl5Xec9KIJh04EMxwG4Bv1daC7dsMYHHb8pu6cTQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610544248; bh=1WMfn+9FlP2qmfNyfT07A65y0FRXYiOatYysGnNZW1t=; h=Date:From:To:Subject:From:Subject:Reply-To; b=NUOogaWFNL9oWFF+DzQcX9FnOdzHnpCIjAN/IP/YF3OkFyVN+UhwCyxkUwhKuz+iUD2PAMkU17+4jMH1yKqIlhCXJWaVZ2ABEgZUoeao+nBrGD7EMCsJ1zeoWWgSKscHyD+tc43v4X2Dj533TIiDMzaLYR06zuRcDHJ8zQZa4YqpmhffpCsHhoeUeB/gf0y5UFxsSZRNdgW8mw5qDtDnbtsDnYHJ01nYCTmPaxT2BFWOshbONQdgKjL6jFjx+SOFZYHgSrKjVBhLbbiU4NB8M9Z1iQ3JsodaN0LCqBqj73f5wXLZGwc6DbYCNiOv2M/dhTliDFE78QQiOHcM/Ontiw== X-YMail-OSG: tx16qGYVM1kSlBVSBkXrbbyV3rVsoxHEIV2fjiwRvrxg0I_CBb9_pW.ymitQhJA PmpfeVALKmBCAZEh78spq9yyzhAnEOJMzIm4Wg98UZ8S0_6aYGhoXW_IWZahRgfAPcb3N95upBRB 3zGdd3UHILRU2YK2n5x7Sbx4HDzNr.ScHzbkSFc3ttJOIqRTOhBZUMAZvztnmMS.6.mePtS3KFYc JJlLSPUXD8Ec2j6jughulLQEDvHpdFR1ZoB6.gPJH4Nx79PUutvwkcspw8lBF9R1pOUSVQXbjUDh mSH9JW.geDKh5nPqKf_JNAH6F3gl0PXcC5pmOQBOcl6k9.sy6BGOY8pncUq8582EYJTeq6Rgfpfl dMxd4bcg_DK.XLRZM7WAJqgzT47deUXFVxH9gKsh_fPduXu_wW6X69I0EKm.iBuKSDNnYfJaDLvb R20A4UMvW1V2HNLR3ZdjaniLjrEDXvw96Aerm2JDUgljONAxCp6OQw5qgX8r7PGtZh9yM.ewOjRj oMtG26TkNuGNRgHrOKCTMiPIrkHuuG0z748iX6NEDkwDtT7v6kWlBWq.V8s1ACDVUOQXp.czRZCe Ujs05Pgb.AJdSP4HjzTMGwWQ.eRLY0u_M2KMpE9SBsmnACza.YjonzxTftsP8CUHyRBBowuxnvM_ JIVzwnW2opZMly3c3apvqwdnsh2B6rF3UB2TiVlmsOXg1RrWNwpFRTFVGfSj_PS6O2pGbFrRSb5h fi6XTat5yQDY9gXuOFxl3uKzrJEAQo42jxVbSOx.iuBVENzmc1g5UuUD_u9uu.i_qZhdcvsFd8iQ rzWj20bhW2O_pbIY1XT_ok7KTEY_RIFb.wi9hfGjbT2wjujCTY5Um7sR7nSPL4obIGzbCLyHyap6 iXYNdTWjOADDAtMST.m0P7I9QZoff3vZfAeGEMssrmEWKpZAMeFxl4ClFgUZA7Np39g8Fr12UlFm TA4PxdMCfa9fzOp3reoIPUlsgVxkwgozaIFK.XbeSqDiy3uc77XSvT1BTdo9sToVkIqpkbmUvdQh FNj9i9bB_fUNtN6_9V9F_GhyoybDQlHPUMqqZ3Sf6lFqZuMh9Ze1HpuUKEUMc0I9AAP7im6u24SE wmPpDPb5hlppAMmyy9emnlzXlU6YWQNiHFe567VRwKq5Ysgs7UBdo2nnCs3GF3MWKNsdb_FB8Pq9 I4VJE6kY3IRJlpbkXgSzgzKHmq7dmWLdKZEVMqA68Cy4qfK.RHk5ubSUzzlK5snf8wIMVyoc_dlH o1j64X1vZgcsahlK8CPfDEnpFg2J5PTNj9mGwos.csBbIfigwPdEaeR69j2pR2hQTrXlv1Xq6KQ2 p7_Na1.KN5WuF.P9oiVeTgCCOuEpGSzc5dqy0wNSgdEMab_Y9H1hXAxjMBq1wTwAJiqa65JP8J4p zmG5qpu9OvLbmEXywds9CpwxBpDidJ97akWq4JAdVP1PPoaITvxIXiJ_hUYV539qg5i9qHMSDT1F tlaRm6t5FmnbHUaTidGspCClnIySyMaqY1XjavMUEpzUtOx7oi.K7gACzpmVqA.I6xeg9wNbrE.e BmwZQDM1KyxM4c3CbbKTlwW41EqHsZBEbplJfJPbgGOcDV1yszL88xbbuyjN3FBBdkJ3n65S_EbW fPH8TDI2zRpA9StuA4Nvvr7AdsswXsvMO2VvSMFMjVZTiG.im74yYkET1nThNM4NKxlCnsdMxKk2 CsAkYzhszP.s.FAhG_KUQ2lK1Hl00423HA9GHeCMHSohdeRXZk9vXXHWfolPBScUEzheYSGGONXq 3AIBrYu6rYtgB2wOEJzflh8wNR3unDagep99Fsmo0ms1dMbnjynllESutQAJiXfgVsTpgafzHlIF 2Bn6sXSA2iN9voKY1f.hTYw4vPMijrFIuMKMsnLdGAjHegtyT4T5j4Bouz9YpJvZwk_stFWGbM12 Mu8CqS8CUnfixs6Ob0hzumR1.JMn7EKL0AhoKC0pJxiQSeZoRdYUOsLAxOEkAz0ha.uYKNN9eY8J lGM7CT5agWJOmGbGJKDtHQr9SxSqY.E_LxZ1GOP3FJ0qBFrAGVpvUveAneO0ukeStQbQSBR8bX6J Rsi5M_Ub6r4uYCfsPildCEVhlHyY3Qwv.LR1.TQ7d5.43xbah8H9.BqbrbwouQpTx90OauCu3zXi lUD5SD_Iscbh0oUldcxUNMsrTKzFSPg6wBBaFJcQY22vEB10KTt2W0iggwoxDl5cJHi3IOjir1fL fEGDixuVsfawx2kbTz3io_alsdL76WPNNDez2OrUbhp_6k2hl_mCKAMe1iyUjYxTfvw5578ElTeT vhO8NMtEEzj8SdfkHzAUY7Q13ZaostgVOG4qYoSKrvvBXGNHQOLYFRwZXBGIcgAqyhOS8Fgfm1M3 .flefRDNDOwTVtvuv_vRnboQfJMM2w5KCcwokrUkh3kGFCzvVECHedWjsUEdJLefs8w5DeTYM9ai yqG8pNHydYVvBOn45gHFVD.Ccauaey0lfCAIUOLYZ.uLS9OPxy81KNB8.01WRQhMWZ6u42aZD7IY XcrJthtfs5VnLIK8BjyBhijBjrx5SIirz8Lha_.xGm7uP49Oz5m9yLKM6lxTP6e1ECkQIWWPieOk fBqQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Wed, 13 Jan 2021 13:24:08 +0000 Date: Wed, 13 Jan 2021 13:24:03 +0000 (UTC) From: Pepe TD Vo Reply-To: Pepe TD Vo To: Jan Peters , "pgsql-admin@lists.postgresql.org" , Laurenz Albe Message-ID: <526397214.877472.1610544243527@mail.yahoo.com> In-Reply-To: <976875a5adf1c1cda0d55e6da0313f30dc8059f6.camel@cybertec.at> References: <976875a5adf1c1cda0d55e6da0313f30dc8059f6.camel@cybertec.at> Subject: Re: PostgreSQL replication failover MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_877471_1161059163.1610544243525" X-Mailer: WebService/1.1.17501 YMailNorrin Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 Content-Length: 10410 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------=_Part_877471_1161059163.1610544243525 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >>If you shut down the primary server cleanly, all changes will be replicat= ed,so you should be good. >>During a failover, that is, if the primary suddenly fails, there is alway= s 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 lon= g as I set synchronous on?=C2=A0 =C2=A0The last couple of weeks=C2=A0I have= a failure on the primary server and can't run on a slave. It picks up as r= eading mode only. Bach-Nga No one in this world is pure and perfect.=C2=A0 If you avoid people for the= ir mistakes you will be alone. So judge less, love, and forgive more.To cal= l him a dog hardly seems to do him justice though in as much as he had four= legs, a tail, and barked, I admit he was, 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 =20 On Wednesday, January 13, 2021, 06:25:53 AM EST, Laurenz Albe wrote: =20 =20 On Wed, 2021-01-13 at 09:27 +0100, Jan Peters wrote: > we are running postgresqlserver on s390 zLinux machines. The distribution >=C2=A0 is RedHat 7 and RedHat 8, so we do not have the many x86 tools avai= lable. >=20 > We always run 2 instances with a replication (streaming) async mode, the = replica >=C2=A0 is in hot_standby and we use it for read-only accesses. About the s= etup we have the following question: >=20 > How is an orderly failover accomplished? Our current procedure is. >=20 > 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 >=20 > Is this processing correct? Are there any other steps that simplify a fai= lover? >=C2=A0 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 --=20 Cybertec | https://www.cybertec-postgresql.com =20 ------=_Part_877471_1161059163.1610544243525 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>If you shut down the primary server cleanly, all ch= anges will be replicated,so you should be good.
<= br clear=3D"none" style=3D"font-family: Helvetica Neue, Helvetica, Arial, s= ans-serif;">>>During a failover, that is, if the primary suddenly fai= ls, there is always
the possibility that you lose some t= ransactions, 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?&nbs= p;  The last couple of weeks I have a failure on the primar= y 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.3D"Emoji"3D"Emoji"3D"Emoji"
To call him a dog hardly seems to do him justice th= ough in as much as he had four legs, a tail, and barked, I admit he was, to= all outward appearances. But to those who knew him well, he was a perfect = gentleman (Hermione Gingold)

<= span style=3D"color:rgb(128, 0, 255);" id=3D"ydpf8dd9bc5yui_3_13_0_rc_1_1_1= 381789421038_7867">**Live simply **Love generously **Care deeply **Speak ki= ndly.
*** Genuinely rich *** Faithful talen= t *** Sharing success




=20
=20
On Wednesday, January 13, 2021, 06:25:53 AM EST, Lauren= z Albe <laurenz.albe@cybertec.at> wrote:


On Wed, 2021-01-13 at 09:27 +0100, Ja= n Peters wrote:
> we are running postgresqlserver on s= 390 zLinux machines. The distribution
>  is RedHa= t 7 and RedHat 8, so we do not have the many x86 tools available.
>
> We always run 2 instances with a rep= lication (streaming) async mode, the replica
>  i= s in hot_standby and we use it for read-only accesses. About the setup we h= ave the following question:
>
> = How is an orderly failover accomplished? Our current procedure is.
>
> 1. primary stop
&g= t; 2. promote replica to primary
> 3. create standby.s= ignal on old primary
> 4. change primary_conninfo on o= ld primary
> 5. start old primary as new replica
>
> Is this processing correct? Are t= here any other steps that simplify a failover?
> = How can we be sure that all changes have been transferred from the old mas= ter to the replica?

What you describe = is not a failover, but a switchover.

I= f 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 alw= ays
the possibility that you lose some transactions, unle= ss you use synchronous

replication.


Yours,=
Laurenz Albe
--
Cyb= ertec | https://www.cybertec-postgresql.com




------=_Part_877471_1161059163.1610544243525--