Re: Recovery - New Slave PostgreSQL 9.2

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_command = 'exec nice -n 19 ionice -c 2 -n 7
../../bin/restore_wal_segment.bash "../wal_archive/%f" "%p"'
archive_cleanup_command = 'exec nice -n 19 ionice -c 2 -n 7
../../bin/pg_archivecleaup_mv.bash -d "../wal_archive" "%r"'
recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=192.168.100.2 port=5432 user=replicator
application_name=replication_slave02'

So, seems to be right to me... Is that u mean?

Thanks

Lucas Possamai

kinghost.co.nz
<http://forum.kinghost.co.nz/memberlist.php?mode=viewprofile&u=2&sid=e999f8370385657a65d41d5ff60b0b38>

On 9 January 2016 at 22:25, Shreeyansh Dba <shreeyansh2014(at)gmail(dot)com> wrote:

> On Sat, Jan 9, 2016 at 8:29 AM, drum(dot)lucas(at)gmail(dot)com <drum(dot)lucas(at)gmail(dot)com
> > wrote:
>
>> ** NOTE: I ran the pg_basebackup from another STANDBY SERVER. Not from
>> the MASTER*
>>
>>
>>
>> Lucas Possamai
>>
>> kinghost.co.nz
>> <http://forum.kinghost.co.nz/memberlist.php?mode=viewprofile&u=2&sid=e999f8370385657a65d41d5ff60b0b38>
>>
>> On 9 January 2016 at 15:28, drum(dot)lucas(at)gmail(dot)com <drum(dot)lucas(at)gmail(dot)com>
>> wrote:
>>
>>> Still trying to solve the problem...
>>> Anyone can help please?
>>>
>>> Lucas
>>>
>>>
>>> Lucas Possamai
>>>
>>> kinghost.co.nz
>>> <http://forum.kinghost.co.nz/memberlist.php?mode=viewprofile&u=2&sid=e999f8370385657a65d41d5ff60b0b38>
>>>
>>> On 9 January 2016 at 14:45, drum(dot)lucas(at)gmail(dot)com <drum(dot)lucas(at)gmail(dot)com>
>>> wrote:
>>>
>>>> Sure... Here's the total information:
>>>>
>>>> http://superuser.com/questions/1023770/new-postgresql-slave-server-error-timeline
>>>>
>>>> recovery.conf:
>>>>
>>>> restore_command = 'exec nice -n 19 ionice -c 2 -n 7 ../../bin/restore_wal_segment.bash "../wal_archive/%f" "%p"'
>>>> archive_cleanup_command = 'exec nice -n 19 ionice -c 2 -n 7 ../../bin/pg_archivecleaup_mv.bash -d "../wal_archive" "%r"'
>>>> recovery_target_timeline = 'latest'
>>>> standby_mode = on
>>>> primary_conninfo = 'host=192.168.100.XX port=5432 user=replicator application_name=replication_new_slave'
>>>>
>>>>
>>>>
>>>>
>>>> Lucas Possamai
>>>>
>>>> kinghost.co.nz
>>>> <http://forum.kinghost.co.nz/memberlist.php?mode=viewprofile&u=2&sid=e999f8370385657a65d41d5ff60b0b38>
>>>>
>>>> On 9 January 2016 at 14:37, Ian Barwick <ian(at)2ndquadrant(dot)com> wrote:
>>>>
>>>>> On 16/01/09 9:23, drum(dot)lucas(at)gmail(dot)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
>>>>> 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
>>>>>
>>>>> Can you post the contents of your recovery.conf file, suitably
>>>>> anonymised if necessary?
>>>>>
>>>>> Regards
>>>>>
>>>>> Ian Barwick
>>>>>
>>>>
>
> Hi Lucas,
>
> I followed your question I generated the same error:
>
> 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 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 seems you have used recovery.conf (to replicate from master to slave)
> to new replica setup C and there is high probability not changing the
> primary connection info
> in C's recovery.conf (Replica B's Connection info)
>
> During testing providing B's connection info in C's recovery.conf resolved
> the issue.
>
> Please verify the Primary connection info parameter in recovery.conf (C
> replica) might resolve your problem.
>
>
>
> Thanks and regards,
> ShreeyanshDBA Team
> Shreeyansh Technologies
> www.shreeyansh.com
>
>