Re: Recovery - New Slave PostgreSQL 9.2 - Mailing list pgsql-admin
From | drum.lucas@gmail.com |
---|---|
Subject | Re: Recovery - New Slave PostgreSQL 9.2 |
Date | |
Msg-id | CAE_gQfVhMJ3fs_U-2v-tp7qSva-0_=TqUhwqJVtvwPCGzMfGQw@mail.gmail.com Whole thread Raw |
In response to | Re: Recovery - New Slave PostgreSQL 9.2 (Shreeyansh Dba <shreeyansh2014@gmail.com>) |
Responses |
Re: Recovery - New Slave PostgreSQL 9.2
|
List | pgsql-admin |
My recovery was like that!
I was already using that way.. I still have the problem =\
Is there anything I can do?
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 TeamShreeyansh TechnologiesOn Sat, Jan 9, 2016 at 3:07 PM, drum.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.1Slave1 (B): 192.168.100.2Slave2 (C): 192.168.100.3My 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?ThanksOn 9 January 2016 at 22:25, Shreeyansh Dba <shreeyansh2014@gmail.com> wrote:On Sat, Jan 9, 2016 at 8:29 AM, drum.lucas@gmail.com <drum.lucas@gmail.com> wrote:* NOTE: I ran the pg_basebackup from another STANDBY SERVER. Not from the MASTEROn 9 January 2016 at 15:28, drum.lucas@gmail.com <drum.lucas@gmail.com> wrote:Still trying to solve the problem...Anyone can help please?LucasOn 9 January 2016 at 14:45, drum.lucas@gmail.com <drum.lucas@gmail.com> wrote:Sure... Here's the total information: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'
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 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 BarwickHi Lucas,I followed your question I generated the same error:cp: cannot stat `/pgdata/arch/00000003.history': No such file or directory2016-01-09 14:11:42 IST FATAL: timeline 1 of the primary does notmatch recovery target timeline 2It 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 infoin 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 TeamShreeyansh Technologies
pgsql-admin by date: