Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aI4GZ-0007GN-Fk for pgsql-admin@arkaria.postgresql.org; Sun, 10 Jan 2016 00:53:55 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aI4GZ-0005AE-2K for pgsql-admin@arkaria.postgresql.org; Sun, 10 Jan 2016 00:53:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aI4Eq-0002b5-3D for pgsql-admin@postgresql.org; Sun, 10 Jan 2016 00:52:08 +0000 Received: from mail-oi0-x22b.google.com ([2607:f8b0:4003:c06::22b]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aI4Em-0005TM-3d for pgsql-admin@postgresql.org; Sun, 10 Jan 2016 00:52:07 +0000 Received: by mail-oi0-x22b.google.com with SMTP id w75so1776757oie.0 for ; Sat, 09 Jan 2016 16:52:03 -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=gdXqyznGIKWYil6coaByyP/mP72mXSDXTYobxcdiCuE=; b=LnpCgIHtRi7qHSt1wdhS08VHzWmu2bOm90jrRyy2Tu3/vgilG+5Fm/jcyMzwlX8On/ G+g8db3Ejgfp776qaEBws0KK4U6dCsaXAKymCCPmPgSvLdTlIPUuLO0igzEpKImJCBjx lvNkdK1V05RVS5VrFN+tSh+SGVKhCHioQNkUTrzKBM2+BBksgdYBrx70ZhZzkBc4nAnh 4X1EeoxKorEkmlEjeQurwh/4/XEucDfu8MP4x9V6xkITHoZpkW6/A/93cK6c/Axs/eYV kRz1srcMhqGPU/fnEtpmzE1w2AHpaHhNg0gsEGYoIrkDbb/vNn8EPvqeWbae55s7UkWA cqxw== X-Received: by 10.202.197.18 with SMTP id v18mr83142036oif.116.1452387122405; Sat, 09 Jan 2016 16:52:02 -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 e195sm5129103oic.1.2016.01.09.16.52.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jan 2016 16:52:01 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-6ABDB009-DB97-4557-A146-1BF70CB7F204 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 18:51:59 -0600 Cc: Shreeyansh Dba , Ian Barwick , "pgsql-admin@postgresql.org" Content-Transfer-Encoding: 7bit Message-Id: <5887A4BA-43D4-4A4F-A379-674840CB4DB9@gmail.com> 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-6ABDB009-DB97-4557-A146-1BF70CB7F204 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Not exactly certain what you're asking here, but have you tried pointing you= 're second slave (the one that didn't fail) directly to your existing primar= y, as opposed to cascading like now. Then, if that works (it may not now as i= t's been too long out of sync.) just point the newly built slave at the slav= e that's working. Sent from my iPad > On Jan 9, 2016, at 6:30 PM, "drum.lucas@gmail.com" w= rote: >=20 > Should I point of replication new slave to same DB? >=20 > Lucas >=20 >> On Sunday, 10 January 2016, drum.lucas@gmail.com w= rote: >> John,=20 >>>=20 >>>=20 >>> 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. >>=20 >> Sorry.. I've understood it wrong.=20 >> So you'd recommend to re-run the pg_basebackup with --xlog-method=3Dstrea= m ? >>=20 >> I'd hope that could find another way. As the pg_basebackup takes 30h to c= omplete :( >>=20 >>=20 >>=20 >> Lucas Possamai >>=20 >> kinghost.co.nz >>=20 >> On 10 January 2016 at 12:21, drum.lucas@gmail.com w= rote: >>>> 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, fr= om your current WAL directory listing that you just provided, that's indicat= ing that your server's timelines are far different. >>>=20 >>> I don't think it's necessary to use -X - Check HERE >>>> --xlog >>>=20 >>>> Using this option is equivalent of using -X with method fetch. >>>=20 >>>=20 >>> ------------------------------- >>>=20 >>>> Now, you're saying that one system went down, which is why you're tryin= g to do this, but was the first slave that failed? Or did your primary fail?= That would possibly explain why the timelines are different. If your primar= y failed and this standby assumed command, then its timeline would have incr= emented. So, if you're trying to put this one back as a slave, that's not a r= eally trivial process. You'd have to set the old primary back up a slave to t= he current primary, and then execute another failover, this time back to you= r original primary, and then rebuild all the slaves all over.=20 >>>=20 >>>=20 >>> PAST SCENARIO: >>> master1 -->slave1 -->slave2 >>> -->slave1 -->db-slave0 - this one went down >>>=20 >>> NEW SCENARIO: >>> master1 -->slave1 -->slave2 >>> -->slave1 -->newslave (This is that one I'm setting up) >>>=20 >>>=20 >>>=20 >>> Lucas Possamai >>>=20 >>> kinghost.co.nz >>>=20 >>>> On 10 January 2016 at 12:16, John Scalia wrote= : >>>> 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, fr= om your current WAL directory listing that you just provided, that's indicat= ing that your server's timelines are far different. >>>>=20 >>>> Now, you're saying that one system went down, which is why you're tryin= g to do this, but was the first slave that failed? Or did your primary fail?= That would possibly explain why the timelines are different. If your primar= y failed and this standby assumed command, then its timeline would have incr= emented. So, if you're trying to put this one back as a slave, that's not a r= eally trivial process. You'd have to set the old primary back up a slave to t= he current primary, and then execute another failover, this time back to you= r original primary, and then rebuild all the slaves all over.=20 >>>>=20 >>>> Just saying, >>>> Jay >>>>=20 >>>> Sent from my iPad >>>>=20 >>>>> On Jan 9, 2016, at 3:48 PM, "drum.lucas@gmail.com" wrote: >>>>>=20 >>>>> Hi John, >>>>>=20 >>>>>> First, when you built the slave server, I'm assuming you used pg_base= backup 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= =3Dbb_master --progress --host=3Dlocalhost --port=3D5432 --username=3Dreplic= ator --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 th= e wal 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= with 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 s= ervers with a proper pg_basebackup. >>>>>=20 >>>>> I've already ran the pg_basebackup over than once. And I always get th= e same 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 wro= te: >>>>>> Hi, >>>>>>=20 >>>>>> I'm a little late to this thread, but in looking at the errors you or= iginally posted, two things come to mind: >>>>>>=20 >>>>>> First, when you built the slave server, I'm assuming you used pg_base= backup 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 unfam= iliar with this. However, yeah, the missing WAL segment is, as well as the b= ad timeline 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 the timeline error, that's disturbing to me as it's claiming the primary= is actually a failed over standby. AFAIK, that's the main if not only way t= ransaction timelines increment. >>>>>>=20 >>>>>> I would suggest, in spite of of the 2TB size, rebuilding the standby s= ervers 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 2= 0h =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 wrote: >>>>>>>>=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 Replica (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/= 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.2 port=3D5432 user=3Dre= plicator 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. N= ot from 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-= server-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= =3Dreplicator application_name=3Dreplication_new_slave' >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Lucas Possamai >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> kinghost.co.nz >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 9 January 2016 at 14:37, Ian Barwick wrote: >>>>>>>>>>>>>>>> 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 s= erver... >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > I've recovery the wal files, but now that I configured to= replicate 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= target timeline 1 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Can you post the contents of your recovery.conf file, suita= bly >>>>>>>>>>>>>>>> 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 o= r directory >>>>>>>>>>>> 2016-01-09 14:11:42 IST FATAL: timeline 1 of the primary does n= ot >>>>>>>>>>>> match recovery target timeline 2 >>>>>>>>>>>>=20 >>>>>>>>>>>> It looks like You have a set up A (Master) ---> B (Replica) ---= > C Replica (Base backup from Replica B) >>>>>>>>>>>>=20 >>>>>>>>>>>> It seems you have used recovery.conf (to replicate from master t= o slave) to new replica setup C and there is high probability not changing t= he primary connection info >>>>>>>>>>>> in C's recovery.conf (Replica B's Connection info) >>>>>>>>>>>>=20 >>>>>>>>>>>> During testing providing B's connection info in C's recovery.co= nf resolved the issue. >>>>>>>>>>>>=20 >>>>>>>>>>>> Please verify the Primary connection info parameter in recovery= .conf (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 m= ay mismatch.=20 >>>>>>>> Please verify the value to synchronous_standby_names value set in t= he postgresql.conf of Replica - C and the value that using as application_na= me in recovery.conf >>>>>>>>=20 >>>>>>>> Also, check whether the Async replication works with out using appl= ication_name in recovery.conf of replica -C and check the status in pg_stat_= replication catalog table. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Thanks and regards >>>>>>>> ShreeyanshDBA Team >>>>>>>> Shreeyansh Technologies >>>>>>>> www.shreeyansh.com >>>>>>> Y >=20 >=20 > --=20 >=20 >=20 > Lucas Possamai >=20 > kinghost.co.nz >=20 --Apple-Mail-6ABDB009-DB97-4557-A146-1BF70CB7F204 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Not exactly certain what you're asking= here, but have you tried pointing you're second slave (the one that didn't f= ail) directly to your existing primary, as opposed to cascading like now. Th= en, if that works (it may not now as it's been too long out of sync.) just p= oint the newly built slave at the slave that's working.

Sent from my i= Pad

On Jan 9, 2016, at 6:30 PM, "drum.lucas@gmail.com" <drum.lucas@gmail.com> wrote:

Should I point of replication new slave to same DB?

<= div>Lucas

On Sunday, 10 January 2016, drum.lucas@gmail.com <drum.lucas@gmail.com> wrote:
John, 

I'd recommend that you'd specify -X s, as just specifying -X= or
-xiog give= s you the default value of fetch rather than stream.

Sorry.. I've understood it wrong. 
So you'd r= ecommend to re-run the pg_basebackup with --xlog-method=3Dstream ?

I'd hope that could find another way. As the pg_basebac= kup takes 30h to complete :(



Lucas Poss= amai


On 10 January 2016 at 12:21, drum.luca= s@gmail.com <drum.lucas@gmail.com> wrote:
I'd recommend that you'd specify -X s, as just specifying -X or
-x= iog gives you the default value of fetch rather than stream. Also, from your= current WAL directory listing that you just provided, that's indicating tha= t your server's timelines are far different.

I don't think i= t's necessary to use -X - Check HERE
--xlog
Using this option is equivalent of using -X with met= hod fetch.

----= ---------------------------

<= /div>
Now, you're saying that one system went down, which is why you're t= rying to do this, but was the first slave that failed? Or did your primary f= ail? That would possibly explain why the timelines are different. If your pr= imary failed and this standby assumed command, then its timeline would have i= ncremented. So, if you're trying to put this one back 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 failover, this time back t= o your original primary, and then rebuild all the slaves all over. 

P= AST SCENARIO:
master1 -->slave1 -->slave2
-->slave1 -->db-slave0 - this one went down

NEW SCENARIO:
master1 -->slave1 -->= slave2
-->slave1 -->newslave (= This is that one I'm setting up)



=
Lucas Possamai


On 10 January 2016 at 12:16, John Scalia <jayknowsunix@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex">
I'd recommend that you'd s= pecify -X s, as just specifying -X or
-xiog gives you the default v= alue of fetch rather than stream. Also, from your current WAL directory list= ing that you just provided, that's indicating that your server's timelines a= re far different.

Now, you're saying that one syste= m went down, which is why you're trying to do this, but was the first slave t= hat failed? Or did your primary fail? That would possibly explain why the ti= melines are different. If your primary failed and this standby assumed comma= nd, then its timeline would have incremented. So, if you're trying to put th= is one back as a slave, that's not a really trivial process. You'd have to s= et the old primary back up a slave to the current primary, and then execute a= nother failover, this time back to your original primary, and then rebuild a= ll the slaves all over. 

Just saying,
Jay

Sent from my iPad

O= n Jan 9, 2016, at 3:48 PM, "drum.lucas@gmail.com" <drum= .lucas@gmail.com> wrote:

=
Hi John,

First, 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?

Yep. I ran the pg_basebackup into the new slave= from ANOTHER SLAVE... 
ssh postgres@slave1 'pg_basebackup --pgdata=3D- --format=3Dtar --l= abel=3Dbb_master --progress --host=3Dlocalhost --port=3D5432 --username=3Dre= plicator --xlog | pv --quiet --rate= -limit 100M' | tar -x --no-same-owner

-X =3D --xlog

O= n my new Slave, I've got all the wall archives. (The master copies the wal a= t all the time...)
ls /var/lib/pgsql/9.2/wal_archive:
00= 00000200000C6A0000002D
0000000200000C6A0000002E
=
and not 
../wa= l_archive/0000000400000C68000000C8` not found
../wal_archive/00000005.history` not found

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

I would suggest, in spite of of the 2TB size, rebuilding the standby server= s with a proper pg_basebackup.

I've already ran the pg_basebac= kup over than once. And I always get the same error... :(

=
Is there an= ything else guys? please,, help hehehhe


Lucas Possamai

<= /div>
On 10 January 2016 at 10:33, John Scalia <jayknowsunix@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex">
Hi,

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

First, when y= ou built the slave server, I'm assuming you used pg_basebackup and if you di= d, did you specify -X s in your command?

Second, th= e missing history file isn't an issue, in case you're unfamiliar with this. H= owever, yeah, the missing WAL segment is, as well as the bad timeline error.=   Is that missing segment still on your primary?  You know you cou= ld just copy it manually to your standby and start from that. As far as the t= imeline error, that's disturbing to me as it's claiming the primary is actua= lly a failed over standby. AFAIK, that's the main if not only way transactio= n timelines increment.

I would suggest, in spite of= of the 2TB size, rebuilding 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" <dru= m.lucas@gmail.com> wrote:

Hi, thanks for your reply... I've been working on this pro= blem for 20h =3D(

# cat postgresql.conf | grep synchronous_standby_names
#synchronous_standby_names =3D '' - It's c= ommented 

# cat postgresql.conf | &= nbsp;grep application_name
log_line_prefix =3D '%m|%p|%q[%c]@%r|%u|%a|%d '
( %a =3D application name )
=

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

Is there anything else I can do?
=
Thank you



Lucas Possamai


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


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 reco= very.conf looks good.
H= ope this solve you problem.


Thanks and regards,=
ShreeyanshDBA Team
Shreeyansh Technologies



On Sat, Jan 9, 2016 at 3:07 PM, drum.lucas@gmail.com <= span dir=3D"ltr"><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= :
On Sat, Jan 9, 2016 at 8:29 AM, drum.lucas@gm= ail.com <drum.lucas@gmail.com>= wrote:
* NOTE: I ran the pg_ba= sebackup from another STANDBY SERVER. Not from the MASTER
=



Lucas Possamai


On 9 January 2016 at 15:28, drum.lucas= @gmail.com <drum.lucas@gmail.com> wrote:
Still trying to solve the probl= em...
Anyone can help please?

Lucas
=

Lucas Possamai

<= /div>

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

<= /div>
recovery.conf:
resto=
re_command =3D 'exec nice -n 19 ionice -c 2 -n 7 ../../bin/restore_wal_segme=
nt.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 <ian@2ndquadrant.com> wrote:
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 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>
Y




--


<= /div>Lucas Possamai


= --Apple-Mail-6ABDB009-DB97-4557-A146-1BF70CB7F204--