Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aI4E9-0007DJ-3I for pgsql-admin@arkaria.postgresql.org; Sun, 10 Jan 2016 00:51:25 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aI4E8-0002aT-40 for pgsql-admin@arkaria.postgresql.org; Sun, 10 Jan 2016 00:51:24 +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 1aI4CR-0000dR-2l for pgsql-admin@postgresql.org; Sun, 10 Jan 2016 00:49:39 +0000 Received: from mail-ob0-x22a.google.com ([2607:f8b0:4003:c01::22a]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aI4CN-0005NW-0Y for pgsql-admin@postgresql.org; Sun, 10 Jan 2016 00:49:38 +0000 Received: by mail-ob0-x22a.google.com with SMTP id py5so6547440obc.2 for ; Sat, 09 Jan 2016 16:49:34 -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=QISd1qKZgYnxxe9PWypS8SZtNMCtNhbD2GwJyrFwoYM=; b=Uu1F9ethF9v3cvId6Nkw5XdUhfgQ1yvWw5YAjVL0TUhduXyreKJ+NZxmuYnRffund4 7a/mK2gsff4lJ5xH+8w3LclEcPqEKDaI0H464/bD0XOSwglZG1O8QsmqF1U77H4q4Hwu w80gLndPN/tn/vaGP/9XywvYkNChys7EUDsvwXt790towRCPIpdCXQjW0vfEBgvrYi20 hk2AwM/K9uMzJsqJAZv1DQRaZZYee233b55noVnTQ96rdvZ61zRZkJBrG7B7ukHQjiQI gjTrGV5Gs7+5D8HoVFgBEkUWXicP3pLMV3T/xCNWXoMIlNRMxmt3aRrRsWuA/3o/LNGG fLpA== X-Received: by 10.182.68.66 with SMTP id u2mr521685obt.49.1452386972820; Sat, 09 Jan 2016 16:49:32 -0800 (PST) Received: from ?IPv6:2605:6000:f686:8500:609a:64d0:3f22:93b4? ([2605:6000:f686:8500:609a:64d0:3f22:93b4]) by smtp.gmail.com with ESMTPSA id v142sm3162303oie.28.2016.01.09.16.49.31 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jan 2016 16:49:31 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-DA8E1A6E-15DA-48D9-AA76-173A71E429D1 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:49:29 -0600 Cc: Shreeyansh Dba , Ian Barwick , "pgsql-admin@postgresql.org" Content-Transfer-Encoding: 7bit Message-Id: <402F1C92-BE63-422E-BE17-AC6C158A6943@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-DA8E1A6E-15DA-48D9-AA76-173A71E429D1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Unfortunately, yes. Depending on how long you're retaining WAL files, not us= ing the stream setting could mean that several files may have been removed b= efore your pg_basebackup completed. Sent from my iPad > On Jan 9, 2016, at 5:29 PM, "drum.lucas@gmail.com" w= rote: >=20 > 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=3Dstream= ? >=20 > I'd hope that could find another way. As the pg_basebackup takes 30h to co= mplete :( >=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, fro= m your current WAL directory listing that you just provided, that's indicati= ng 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 trying= to do this, but was the first slave that failed? Or did your primary fail? T= hat would possibly explain why the timelines are different. If your primary f= ailed and this standby assumed command, then its timeline would have increme= nted. So, if you're trying to put this one back as a slave, that's not a rea= lly trivial process. You'd have to set the old primary back up a slave to th= e current primary, and then execute another failover, this time back to your= 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, fro= m your current WAL directory listing that you just provided, that's indicati= ng that your server's timelines are far different. >>>=20 >>> Now, you're saying that one system went down, which is why you're trying= to do this, but was the first slave that failed? Or did your primary fail? T= hat would possibly explain why the timelines are different. If your primary f= ailed and this standby assumed command, then its timeline would have increme= nted. So, if you're trying to put this one back as a slave, that's not a rea= lly trivial process. You'd have to set the old primary back up a slave to th= e current primary, and then execute another failover, this time back to your= 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_baseb= ackup 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=3D= bb_master --progress --host=3Dlocalhost --port=3D5432 --username=3Dreplicato= r --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= 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 w= ith another slave. But the server went down and I'm trying to set up a new o= ne) >>>>=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 the= 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 wrot= e: >>>>> Hi, >>>>>=20 >>>>> I'm a little late to this thread, but in looking at the errors you ori= ginally posted, two things come to mind: >>>>>=20 >>>>> First, when you built the slave server, I'm assuming you used pg_baseb= ackup 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 unfami= liar with this. However, yeah, the missing WAL segment is, as well as the ba= d timeline error. Is that missing segment still on your primary? You know y= ou could just copy it manually to your standby and start from that. As far a= s the timeline error, that's disturbing to me as it's claiming the primary i= s actually a failed over standby. AFAIK, that's the main if not only way tra= nsaction 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 20= h =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/r= estore_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=3Drep= licator 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. No= t 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-s= erver-error-timeline >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> recovery.conf: >>>>>>>>>>>>>> restore_command =3D 'exec nice -n 19 ionice -c 2 -n 7 ../../b= in/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=3D= replicator 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 r= eplicate 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 t= arget timeline 1 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Can you post the contents of your recovery.conf file, suitab= ly >>>>>>>>>>>>>>> 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= 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.con= f 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 appli= cation_name in recovery.conf of replica -C and check the status in pg_stat_r= eplication catalog table. >>>>>>>=20 >>>>>>>=20 >>>>>>> Thanks and regards >>>>>>> ShreeyanshDBA Team >>>>>>> Shreeyansh Technologies >>>>>>> www.shreeyansh.com >=20 --Apple-Mail-DA8E1A6E-15DA-48D9-AA76-173A71E429D1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Unfortunately, yes. Depending on how l= ong you're retaining WAL files, not using the stream setting could mean that= several files may have been removed before your pg_basebackup completed.
Sent from my iPad

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

John, 

<= span style=3D"color:rgb(80,0,80);font-size:12.8px">I'd recommend that you'd s= pecify -X s, as just specifying -X or
-xiog gives you the default value of fetch rather th= an stream.

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

I'd hope that could f= ind another way. As the pg_basebackup takes 30h to complete :(



Lucas Possamai

On 10 January 2016 at 12:21, drum.lucas@gmail.com <drum.lucas@gmail.com> wrote:
I'd recommend that you'd specify -X s, as just spec= ifying -X or
-xiog gives you the default value of fetch rather than strea= m. Also, from your current WAL directory listing that you just provided, tha= t's indicating that your server's timelines are far different.
<= div style=3D"font-size:12.8px">
Using this option is equivalent o= f using -X with method fetch.
Now, you're saying that one system we= nt down, which is why you're trying to do this, but was the first slave that= failed? Or did your primary fail? That would possibly explain why the timel= ines are different. If your primary failed and this standby assumed command,= then its timeline would have incremented. So, if you're trying to put this o= ne back as a slave, that's not a really trivial process. You'd have to set t= he old primary back up a slave to the current primary, and then execute anot= her failover, this time back to your original primary, and then rebuild all t= he slaves all over. 


On 10 January 2016 at 12:16, John Scalia <jayknowsunix@gmail.com> wrote:
I'd recommend that you'd specify -X s, as just sp= ecifying -X or
-xiog gives you the default value of fetch rather t= han stream. Also, from your current WAL directory listing that you just prov= ided, that's indicating that your server's timelines are far different.

Now, you're saying that one system went down, which is w= hy you're trying to do this, but was the first slave that failed? Or did you= r primary fail? That would possibly explain why the timelines are different.= If your primary failed and this standby assumed command, then its timeline w= ould have incremented. 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 t= ime back to your original primary, and then rebuild all the slaves all over.=  

Just saying,
Jay
<= br>Sent from my iPad

On Jan 9, 2016, at 3:48 P= M, "drum.lucas@gma= il.com" <dr= um.lucas@gmail.com> wrote:

Hi John,

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

Yep. I ran the pg_basebackup into the new slav= e 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:
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 working on thi= s problem for 20h =3D(

# cat postgresql.conf | grep&nb= sp;synchronous_standby_names
#synchronous_standby_names =3D '' - I= t's commented 
# cat postgresql.con= f |  grep application_name
log_line_prefix =3D '%m|%p|%q[%c]@%r|%u|%a|%d '
( %a =3D application name )<= /div>

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

Is there anything else I can do?<= /div>
Thank you


<= /div>

Lucas Possamai

<= /div>

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-DA8E1A6E-15DA-48D9-AA76-173A71E429D1--