Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aI2lw-0003Yx-QF for pgsql-admin@arkaria.postgresql.org; Sat, 09 Jan 2016 23:18:13 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aI2lv-0006BP-UZ for pgsql-admin@arkaria.postgresql.org; Sat, 09 Jan 2016 23:18:11 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aI2kF-0004KT-C5 for pgsql-admin@postgresql.org; Sat, 09 Jan 2016 23:16:27 +0000 Received: from mail-oi0-x229.google.com ([2607:f8b0:4003:c06::229]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aI2kB-0006Tj-OS for pgsql-admin@postgresql.org; Sat, 09 Jan 2016 23:16:26 +0000 Received: by mail-oi0-x229.google.com with SMTP id k206so31730394oia.1 for ; Sat, 09 Jan 2016 15:16:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FY2La1XQs92X8DRhwGzFR5KfcvvRvVYlQASbC554lRQ=; b=JjI76R6dudvTa+YMXydzvoswvgP+SC1/Pm6b4EQ/vFszbchkrxHP4W7rh3q85uus3a A1wHdd4VQID0GiW6dqpNQcxbfU1ZyxPmVuxc7IGWYw8jNUvNhSIMXf5ykwMTjYtxyALg SU+4VV61+q50rJf3OFufMtnGZ0NZxuAiYyK3ZjkOAAVA+tewa4aLlov55dcIQ+YATLZC TOCdXoF8uTiYLrbek8CbMUHnd/0vLZ0DWwbgrhnQq+wcPyh8GIvaGaAeM97CI5Q9ZU6L pI/7RxbYByjVuMg4fGCKjnLgAc++qEiAr6q5xzukXdJAYDhjj3yrfvHDPlCclmzX9cEM HFtA== X-Received: by 10.202.171.144 with SMTP id u138mr74578877oie.104.1452381383075; Sat, 09 Jan 2016 15:16:23 -0800 (PST) Received: from [192.168.0.2] (cpe-72-182-26-34.austin.res.rr.com. [72.182.26.34]) by smtp.gmail.com with ESMTPSA id s7sm47406693obk.17.2016.01.09.15.16.22 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jan 2016 15:16:22 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-4C192EED-08F8-4285-A0C3-8FCE24DE5BC9 Mime-Version: 1.0 (1.0) Subject: Re: Recovery - New Slave PostgreSQL 9.2 From: John Scalia X-Mailer: iPad Mail (13C75) In-Reply-To: Date: Sat, 9 Jan 2016 17:16:21 -0600 Cc: Shreeyansh Dba , Ian Barwick , "pgsql-admin@postgresql.org" Content-Transfer-Encoding: 7bit Message-Id: References: <56906451.4010107@2ndquadrant.com> <0650DA9A-49A7-451B-9FAB-39B576BCB5BF@gmail.com> To: "drum.lucas@gmail.com" X-Pg-Spam-Score: -0.4 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org --Apple-Mail-4C192EED-08F8-4285-A0C3-8FCE24DE5BC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'd recommend that you'd specify -X s, as just specifying -X or -xiog gives you the default value of fetch rather than stream. Also, from yo= ur current WAL directory listing that you just provided, that's indicating t= hat your server's timelines are far different. Now, you're saying that one system went down, which is why you're trying to d= o this, but was the first slave that failed? Or did your primary fail? That w= ould possibly explain why the timelines are different. If your primary faile= d and this standby assumed command, then its timeline would have incremented= . So, if you're trying to put this one back as a slave, that's not a really t= rivial process. You'd have to set the old primary back up a slave to the cur= rent primary, and then execute another failover, this time back to your orig= inal primary, and then rebuild all the slaves all over.=20 Just saying, Jay Sent from my iPad > On Jan 9, 2016, at 3:48 PM, "drum.lucas@gmail.com" w= rote: >=20 > Hi John, >=20 >> First, when you built the slave server, I'm assuming you used pg_baseback= up and if you did, did you specify -X s in your command? >=20 > Yep. I ran the pg_basebackup into the new slave from ANOTHER SLAVE...=20 > ssh postgres@slave1 'pg_basebackup --pgdata=3D- --format=3Dtar --label=3Db= b_master --progress --host=3Dlocalhost --port=3D5432 --username=3Dreplicator= --xlog | pv --quiet --rate-limit 100M' | tar -x --no-same-owner >=20 > -X =3D --xlog >=20 > On my new Slave, I've got all the wall archives. (The master copies the wa= l at all the time...) > ls /var/lib/pgsql/9.2/wal_archive: > 0000000200000C6A0000002D > 0000000200000C6A0000002E >=20 > and not=20 > ../wal_archive/0000000400000C68000000C8` not found > ../wal_archive/00000005.history` not found >=20 > Remember that I'm trying to do a cascading replication (It was working wit= h another slave. But the server went down and I'm trying to set up a new one= ) >=20 >> I would suggest, in spite of of the 2TB size, rebuilding the standby serv= ers with a proper pg_basebackup. >=20 > I've already ran the pg_basebackup over than once. And I always get the sa= me error... :( >=20 > Is there anything else guys? please,, help hehehhe >=20 >=20 >=20 > Lucas Possamai >=20 > kinghost.co.nz >=20 >> On 10 January 2016 at 10:33, John Scalia wrote: >> Hi, >>=20 >> I'm a little late to this thread, but in looking at the errors you origin= ally posted, two things come to mind: >>=20 >> First, when you built the slave server, I'm assuming you used pg_baseback= up and if you did, did you specify -X s in your command? >>=20 >> Second, the missing history file isn't an issue, in case you're unfamilia= r with this. However, yeah, the missing WAL segment is, as well as the bad t= imeline error. Is that missing segment still on your primary? You know you= could just copy it manually to your standby and start from that. As far as t= he timeline error, that's disturbing to me as it's claiming the primary is a= ctually a failed over standby. AFAIK, that's the main if not only way transa= ction timelines increment. >>=20 >> I would suggest, in spite of of the 2TB size, rebuilding the standby serv= ers with a proper pg_basebackup. >> -- >> Jay >>=20 >> Sent from my iPad >>=20 >>> On Jan 9, 2016, at 2:19 PM, "drum.lucas@gmail.com" wrote: >>>=20 >>> Hi, thanks for your reply... I've been working on this problem for 20h =3D= ( >>>=20 >>> # cat postgresql.conf | grep synchronous_standby_names >>> #synchronous_standby_names =3D '' - It's commented=20 >>>=20 >>> # cat postgresql.conf | grep application_name >>> log_line_prefix =3D '%m|%p|%q[%c]@%r|%u|%a|%d ' >>> ( %a =3D application name ) >>>=20 >>> I can't resyc all the DB again, because it has 2TB of data :( >>>=20 >>> Is there anything else I can do? >>> Thank you >>>=20 >>>=20 >>>=20 >>> Lucas Possamai >>>=20 >>> kinghost.co.nz >>>=20 >>>> On 10 January 2016 at 04:22, Shreeyansh Dba w= rote: >>>>=20 >>>>=20 >>>>> On Sat, Jan 9, 2016 at 3:28 PM, drum.lucas@gmail.com wrote: >>>>> My recovery was like that! >>>>> I was already using that way.. I still have the problem =3D\ >>>>>=20 >>>>> Is there anything I can do? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Lucas Possamai >>>>>=20 >>>>> kinghost.co.nz >>>>>=20 >>>>>> On 9 January 2016 at 22:53, Shreeyansh Dba = wrote: >>>>>>=20 >>>>>> Hi Lucas, >>>>>>=20 >>>>>> Yes , now recovery.conf looks good. >>>>>> Hope this solve you problem. >>>>>>=20 >>>>>>=20 >>>>>> Thanks and regards, >>>>>> ShreeyanshDBA Team >>>>>> Shreeyansh Technologies >>>>>> www.shreeyansh.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On Sat, Jan 9, 2016 at 3:07 PM, drum.lucas@gmail.com wrote: >>>>>>> Hi there! >>>>>>>=20 >>>>>>> Yep, it's correct:=20 >>>>>>> It looks like You have a set up A (Master) ---> B (Replica) ---> C R= eplica (Base backup from Replica B) >>>>>>>=20 >>>>>>> Master (A): 192.168.100.1 >>>>>>> Slave1 (B): 192.168.100.2 >>>>>>> Slave2 (C): 192.168.100.3 >>>>>>>=20 >>>>>>> My recovery.conf in slave2(C) is: >>>>>>> restore_command =3D 'exec nice -n 19 ionice -c 2 -n 7 ../../bin/rest= ore_wal_segment.bash "../wal_archive/%f" "%p"' >>>>>>> archive_cleanup_command =3D 'exec nice -n 19 ionice -c 2 -n 7 ../../= bin/pg_archivecleaup_mv.bash -d "../wal_archive" "%r"' >>>>>>> recovery_target_timeline =3D 'latest' >>>>>>> standby_mode =3D on >>>>>>> primary_conninfo =3D 'host=3D192.168.100.2 port=3D5432 user=3Dreplic= ator application_name=3Dreplication_slave02' >>>>>>> So, seems to be right to me... Is that u mean? >>>>>>>=20 >>>>>>> Thanks >>>>>>>=20 >>>>>>>=20 >>>>>>> Lucas Possamai >>>>>>>=20 >>>>>>> kinghost.co.nz >>>>>>>=20 >>>>>>>> On 9 January 2016 at 22:25, Shreeyansh Dba wrote: >>>>>>>>> On Sat, Jan 9, 2016 at 8:29 AM, drum.lucas@gmail.com wrote: >>>>>>>>> * NOTE: I ran the pg_basebackup from another STANDBY SERVER. Not f= rom the MASTER >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Lucas Possamai >>>>>>>>>=20 >>>>>>>>> kinghost.co.nz >>>>>>>>>=20 >>>>>>>>>> On 9 January 2016 at 15:28, drum.lucas@gmail.com wrote: >>>>>>>>>> Still trying to solve the problem... >>>>>>>>>> Anyone can help please? >>>>>>>>>>=20 >>>>>>>>>> Lucas >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Lucas Possamai >>>>>>>>>>=20 >>>>>>>>>> kinghost.co.nz >>>>>>>>>>=20 >>>>>>>>>>> On 9 January 2016 at 14:45, drum.lucas@gmail.com wrote: >>>>>>>>>>> Sure... Here's the total information: >>>>>>>>>>> http://superuser.com/questions/1023770/new-postgresql-slave-serv= er-error-timeline >>>>>>>>>>>=20 >>>>>>>>>>> recovery.conf: >>>>>>>>>>> restore_command =3D 'exec nice -n 19 ionice -c 2 -n 7 ../../bin/= restore_wal_segment.bash "../wal_archive/%f" "%p"' >>>>>>>>>>> archive_cleanup_command =3D 'exec nice -n 19 ionice -c 2 -n 7 ..= /../bin/pg_archivecleaup_mv.bash -d "../wal_archive" "%r"' >>>>>>>>>>> recovery_target_timeline =3D 'latest' >>>>>>>>>>> standby_mode =3D on >>>>>>>>>>> primary_conninfo =3D 'host=3D192.168.100.XX port=3D5432 user=3Dr= eplicator application_name=3Dreplication_new_slave' >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Lucas Possamai >>>>>>>>>>>=20 >>>>>>>>>>> kinghost.co.nz >>>>>>>>>>>=20 >>>>>>>>>>>> On 9 January 2016 at 14:37, Ian Barwick w= rote: >>>>>>>>>>>> On 16/01/09 9:23, drum.lucas@gmail.com wrote: >>>>>>>>>>>> > Hi all! >>>>>>>>>>>> > >>>>>>>>>>>> > I've done the pg_basebackup from the live to a new slave serv= er... >>>>>>>>>>>> > >>>>>>>>>>>> > I've recovery the wal files, but now that I configured to rep= licate from the master (recovery.conf) I got this error: >>>>>>>>>>>> > >>>>>>>>>>>> > ../wal_archive/0000000400000C68000000C8` not found >>>>>>>>>>>> > ../wal_archive/00000005.history` not found >>>>>>>>>>>> > >>>>>>>>>>>> > FATAL: timeline 2 of the primary does not match recovery tar= get timeline 1 >>>>>>>>>>>>=20 >>>>>>>>>>>> Can you post the contents of your recovery.conf file, suitably >>>>>>>>>>>> anonymised if necessary? >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards >>>>>>>>>>>>=20 >>>>>>>>>>>> Ian Barwick >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi Lucas, >>>>>>>>=20 >>>>>>>> I followed your question I generated the same error: >>>>>>>>=20 >>>>>>>> cp: cannot stat `/pgdata/arch/00000003.history': No such file or di= rectory >>>>>>>> 2016-01-09 14:11:42 IST FATAL: timeline 1 of the primary does not >>>>>>>> match recovery target timeline 2 >>>>>>>>=20 >>>>>>>> It looks like You have a set up A (Master) ---> B (Replica) ---> C R= eplica (Base backup from Replica B) >>>>>>>>=20 >>>>>>>> It seems you have used recovery.conf (to replicate from master to s= lave) to new replica setup C and there is high probability not changing the p= rimary connection info >>>>>>>> in C's recovery.conf (Replica B's Connection info) >>>>>>>>=20 >>>>>>>> During testing providing B's connection info in C's recovery.conf r= esolved the issue. >>>>>>>>=20 >>>>>>>> Please verify the Primary connection info parameter in recovery.con= f (C replica) might resolve your problem. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Thanks and regards, >>>>>>>> ShreeyanshDBA Team >>>>>>>> Shreeyansh Technologies >>>>>>>> www.shreeyansh.com=20 >>>>=20 >>>> Hi Lucas, >>>>=20 >>>> It looks like application_name parameter that set in recovery.conf may m= ismatch.=20 >>>> Please verify the value to synchronous_standby_names value set in the p= ostgresql.conf of Replica - C and the value that using as application_name i= n recovery.conf >>>>=20 >>>> Also, check whether the Async replication works with out using applicat= ion_name in recovery.conf of replica -C and check the status in pg_stat_repl= ication catalog table. >>>>=20 >>>>=20 >>>> Thanks and regards >>>> ShreeyanshDBA Team >>>> Shreeyansh Technologies >>>> www.shreeyansh.com >=20 --Apple-Mail-4C192EED-08F8-4285-A0C3-8FCE24DE5BC9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'd recommend that you'd specify -X s,= as just specifying -X or
-xiog gives yo= u the default value of fetch rather than stream. Also, from your current WAL= directory listing that you just provided, that's indicating that your serve= r's timelines are far different.

Now, you're saying that one system went do= wn, which is why you're trying to do this, but was the first slave that fail= ed? Or did your primary fail? That would possibly explain why the timelines a= re different. If your primary failed and this standby assumed command, then i= ts timeline would have incremented. So, if you're trying to put this one bac= k as a slave, that's not a really trivial process. You'd have to set the old= primary back up a slave to the current primary, and then execute another fa= ilover, this time back to your original primary, and then rebuild all the sl= aves all over. 

Just saying,
Jay

Sent from my iPad

On Jan= 9, 2016, at 3:48 PM, "drum.lucas@gm= ail.com" <drum.lucas@gmail.co= m> wrote:

Hi John,

Fir= st, when you built the slave server, I'm assuming you used pg_basebackup and= if you did, did you specify -X s in your command?
<= br>
Yep. I ran the pg_basebackup into the new slave from ANOTHER S= LAVE... 
ssh p= ostgres@slave1 'pg_basebackup --pgdata=3D- --format=3Dtar --label=3Dbb_maste= r --progress --host=3Dlocalhost --port=3D5432 --username=3Dreplicator --xlog | pv --quiet --rate-limit 100M' | ta= r -x --no-same-owner

-X =3D --xlog

On my new Slave, I'= ve got all the wall archives. (The master copies the wal at all the time...)=
ls /var/lib/pgsql/9.2/wal_archive:
0000000200000C6A0000= 002D
0000000200000C6A0000002E

and= not 
../wal_archive/00000004= 00000C68000000C8` not found
../wal_= archive/00000005.history` not found

Remember that I'm trying to do a= cascading replication (It was working with another slave. But the server we= nt down and I'm trying to set up a new one)

I would sugge= st, in spite of of the 2TB size, rebuilding the standby servers with a prope= r pg_basebackup.

I've already ran the pg_basebackup over than o= nce. And I always get the same error... :(

Is there anything else guy= s? please,, help hehehhe



Lucas Possamai


On 10 January 2016 at 10:33, John Scalia <jayknowsunix@gmail.com> wrote:
Hi,

I'm a little late to= this thread, but in looking at the errors you originally posted, two things= come to mind:

First, when you built the slave serv= er, I'm assuming you used pg_basebackup and if you did, did you specify -X s= in your command?

Second, the missing history file i= sn't an issue, in case you're unfamiliar with this. However, yeah, the missi= ng WAL segment is, as well as the bad timeline error.  Is that missing s= egment still on your primary?  You know you could just copy it manually= to your standby and start from that. As far as the timeline error, that's d= isturbing to me as it's claiming the primary is actually a failed over stand= by. AFAIK, that's the main if not only way transaction timelines increment.<= /div>

I would suggest, in spite of of the 2TB size, rebui= lding the standby servers with a proper pg_basebackup.
--
Jay

Sent from my iPad

On Jan 9= , 2016, at 2:19 PM, "drum.lucas@gmail.com" <drum.lucas@gmail.com> wrote:

Hi, thanks for your reply... I've been wo= rking on this problem for 20h =3D(

# cat postgresql.co= nf | grep synchronous_standby_names
#synchronous_standby_nam= es =3D '' - It's commented 

# cat p= ostgresql.conf |  grep application_name
log_line_prefix =3D '%m|%p|%q[%c]@%r|%u|%a|%d '
( %a =3D application n= ame )

I can't resyc all the DB again, because i= t has 2TB of data :(

<= /span>
Is there anything else I c= an do?
Thank you



Lucas Possamai


On 10 January 2016 at 04:22, Shreeyansh Dba <= span dir=3D"ltr"><shreeyansh2014@gmail.com> wrote:


On Sat, Jan 9, 2016 at 3:28 PM, drum.lucas@gmail.com <drum.lucas= @gmail.com> wrote:
My recover= y was like that!
I was already using that way.. I still have the problem= =3D\

Is there anything I can do?


<= /div>

Lucas Possamai

<= /div>

On 9 January 2016 at 22:53, Shreeyansh Dba <shreeyansh2014@gmail.com> wrote:

Hi Lucas,=

= Yes , now recovery.conf looks good.
Hope this solve you problem= .


Thanks and regards,
ShreeyanshDBA Team
Shreeyansh Technologies



On Sat, Jan 9, 2= 016 at 3:07 PM, dr= um.lucas@gmail.com <drum.lucas@gmail.com> wrote:
Hi there!

Yep, it's correct:=  
It looks like You have a set up A (Master) ---> B (Replica) -= --> C Replica (Base backup from Replica B)

Master (A): 192.168.100.1
Slave1 (B): 192.168.100.2
Slave2 (C): 192.168.100.3

My recovery.conf= in slave2(C) is:
restore_comman=
d =
=3D 'exec nice -n 19 ionice -c 2 -n 7 ../../bin/restore_wal_segment.bash "../w=
al_archive/%f" "%p"'
archive_cleanup_command =3D 'exec nice -n 19 ionice -c 2 -n 7 ../../bin/pg_archi=
vecleaup_mv.bash -d "../wal_archive" "%r"'
recovery_target_timeline =3D 'latest'
standby_mode =3D on
primary_conninfo =3D 'host=3D192.168.100.2 port=3D5432 user=3Dreplicator applica=
tion_name=3Dreplication_slave02'
So, seems to b= e right to me... Is that u mean?

Thanks
<= br>

Lucas Possamai

<= div>

On 9 January 2016 at 22:25, Shreeyansh Dba <shreeyansh2014@gmail.com> wrote:
O= n Sat, Jan 9, 2016 at 8:29 AM, drum.lucas@gmail.com <drum.lucas@gmail.com> wrote:
* NOTE: I ran the pg_b= asebackup from another STANDBY SERVER. Not from the MASTER



Lucas Possamai


On 9 January 2016 at 15:28, drum.lucas@gmail.com <drum.luc= as@gmail.com> wrote:
Still t= rying to solve the problem...
Anyone can help please?

Lucas


Lucas Possamai


On 9 January 2016 at 14:45, drum.lucas@gmail.com <drum.luc= as@gmail.com> wrote:
Sure..= . Here's the total information:

recovery.conf:
restore_command =3D 'exec nice -n 19 ionice -c 2 -n 7 .=
./../bin/restore_wal_segment.bash "../wal_archive/%f" "%p"'
archive_cleanup_command =3D 'exec nice -n 19 ionice -c 2 -n 7 ../../bin/pg_a=
rchivecleaup_mv.bash -d "../wal_archive" "%r"'
recovery_target_timeline =3D 'latest'
standby_mode =3D on
primary_conninfo =3D 'host=3D192.168.100.XX port=3D5432 user=3Dreplicator ap=
plication_name=3Dreplication_new_slave'



Lucas Possamai


On 9 January 2016 at 14:37, Ian Barwick <ia= n@2ndquadrant.com> wrote:
On 16/01/09 9= :23, drum.lucas@gm= ail.com wrote:
> Hi all!
>
> I've done the pg_basebackup from the live to a new slave server...
>
> I've recovery the wal files, but now that I configured to replicate fro= m the master (recovery.conf) I got this error:
>
> ../wal_archive/0000000400000C68000000C8` not found
> ../wal_archive/00000005.history` not found
>
> FATAL:  timeline 2 of the primary does not match recovery target t= imeline 1

Can you post the contents of your recovery.conf file, suitably
anonymised if necessary?

Regards

Ian Barwick


Hi Lucas,

<= /font>
I followed your questio= n I generated the same error:

cp: cannot s= tat `/pgdata/arch/00000003.history': No such file or directory
<= div>2016-01-09 14:11:42 IST FATAL:  = ;timeline 1 of the primary does not
match recovery target timeline 2

It looks like You have a set up A (Master) ---> B (Replica) ---> C= Replica (Base backup from Replica B)

It s= eems you have used recovery.conf (to replicate from master to slave) to new r= eplica setup C and there is high probability not changing the primary connec= tion info
in C's recove= ry.conf (Replica B's Connection info)

Dur= ing testing providing B's connection info in C's recovery.conf resolved the i= ssue.

=
Please verify the Primary connectio= n info parameter in recovery.conf (C replica) might resolve your problem.



Tha= nks and regards,
Shreey= anshDBA Team
Shreeyansh= Technologies





Hi Lucas= ,

It looks like applicat= ion_name parameter that set in recovery.conf may mismatch. 
Please verify the= value to synchronous_standby_names  value set in the postgresql.conf o= f Replica - C and the value that using as application_name in recovery.conf<= /span>

Also, check whether the Async replication works wit= h out using application_name in recovery.conf of replica -C and check the st= atus in pg_stat_replication catalog table.

Thanks and regards
ShreeyanshDBA Team
Shreeyansh Technologies<= /div>


= --Apple-Mail-4C192EED-08F8-4285-A0C3-8FCE24DE5BC9--