From: John Scalia <jayknowsunix@gmail.com>
To: drum.lucas@gmail.com <drum.lucas@gmail.com>
Cc: Shreeyansh Dba <shreeyansh2014@gmail.com>
Cc: Ian Barwick <ian@2ndquadrant.com>
Cc: pgsql-admin@postgresql.org <pgsql-admin@postgresql.org>
Subject: Re: Recovery - New Slave PostgreSQL 9.2
Date: Sat, 9 Jan 2016 15:33:05 -0600
Message-ID: <0650DA9A-49A7-451B-9FAB-39B576BCB5BF@gmail.com> (raw)
In-Reply-To: <CAE_gQfVzvXRZhL84F9BZes8chixU2ry4kbMvpo0GKKbf_A=ZnA@mail.gmail.com>
References: <CAE_gQfUUJNCN6okfC-qjxeZbaJ7g1ATK8xbWq0G5VM=Eiz3=ew@mail.gmail.com>
<56906451.4010107@2ndquadrant.com>
<CAE_gQfX3Tm0oNASqnXy3USKxtC9_+KrBC2f=oMegrgRG9j0bbw@mail.gmail.com>
<CAE_gQfV-9ehvued+9X7uQzreF34kzpyijCPVRGSrz3tsTufmew@mail.gmail.com>
<CAE_gQfXqL+C2Zft_dpVxcV0mSngZWFptiKRLjSg2qfCDRnzUOQ@mail.gmail.com>
<CAGDYbUMU0D4pRPJJkXBH5+K5SU=9+sqRtD_TL=_ne8r02xUZDg@mail.gmail.com>
<CAE_gQfVPAHRDYuty8MzJ2cufBc18sPcSNKPbR2c2QXGaFKRNBg@mail.gmail.com>
<CAGDYbUN9LQEXB+PJ-yd51ivqXSp=fNiibvUNY7yUoF_xBBdhWA@mail.gmail.com>
<CAE_gQfVhMJ3fs_U-2v-tp7qSva-0_=TqUhwqJVtvwPCGzMfGQw@mail.gmail.com>
<CAGDYbUOo=p9FkPHq1LRy_e0guAPV=mipL=U4VEQEZ9hTRyfCPQ@mail.gmail.com>
<CAE_gQfVzvXRZhL84F9BZes8chixU2ry4kbMvpo0GKKbf_A=ZnA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
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 server, I'm assuming you used pg_basebackup and if you did, did you specify -X s in your command?
Second, the missing history file isn't an issue, in case you're unfamiliar with this. However, yeah, the missing WAL segment is, as well as the bad 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 transaction 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" <drum.lucas@gmail.com> wrote:
>
> Hi, thanks for your reply... I've been working on this problem for 20h =(
>
> # cat postgresql.conf | grep synchronous_standby_names
> #synchronous_standby_names = '' - It's commented
>
> # cat postgresql.conf | grep application_name
> log_line_prefix = '%m|%p|%q[%c]@%r|%u|%a|%d '
> ( %a = 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
>
> kinghost.co.nz
>
>> On 10 January 2016 at 04:22, Shreeyansh Dba <shreeyansh2014@gmail.com> wrote:
>>
>>
>>> On Sat, Jan 9, 2016 at 3:28 PM, drum.lucas@gmail.com <drum.lucas@gmail.com> wrote:
>>> My recovery was like that!
>>> I was already using that way.. I still have the problem =\
>>>
>>> Is there anything I can do?
>>>
>>>
>>>
>>> Lucas Possamai
>>>
>>> kinghost.co.nz
>>>
>>>> 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
>>>> www.shreeyansh.com
>>>>
>>>>
>>>>
>>>>> On 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.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
>>>>>
>>>>>> On 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 MASTER
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Lucas Possamai
>>>>>>>
>>>>>>> kinghost.co.nz
>>>>>>>
>>>>>>>> On 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?
>>>>>>>>
>>>>>>>> Lucas
>>>>>>>>
>>>>>>>>
>>>>>>>> Lucas Possamai
>>>>>>>>
>>>>>>>> kinghost.co.nz
>>>>>>>>
>>>>>>>>> On 9 January 2016 at 14:45, drum.lucas@gmail.com <drum.lucas@gmail.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
>>>>>>>>>
>>>>>>>>>> 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 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
>>
>> Hi Lucas,
>>
>> It looks like application_name parameter that set in recovery.conf may mismatch.
>> Please verify the value to synchronous_standby_names value set in the postgresql.conf of Replica - C and the value that using as application_name in recovery.conf
>>
>> Also, check whether the Async replication works with out using application_name in recovery.conf of replica -C and check the status in pg_stat_replication catalog table.
>>
>>
>> Thanks and regards
>> ShreeyanshDBA Team
>> Shreeyansh Technologies
>> www.shreeyansh.com
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: jayknowsunix@gmail.com, drum.lucas@gmail.com, shreeyansh2014@gmail.com, ian@2ndquadrant.com
Subject: Re: Recovery - New Slave PostgreSQL 9.2
In-Reply-To: <0650DA9A-49A7-451B-9FAB-39B576BCB5BF@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox