Re: Patch for fail-back without fresh backup - Mailing list pgsql-hackers

From Sawada Masahiko
Subject Re: Patch for fail-back without fresh backup
Date
Msg-id CAD21AoDD29+qfU5WwLUCfMA8=-KDkHmoXoi6S1_uahaAcAt_HQ@mail.gmail.com
Whole thread Raw
In response to Re: Patch for fail-back without fresh backup  (Amit kapila <amit.kapila@huawei.com>)
Responses Re: Patch for fail-back without fresh backup
List pgsql-hackers
On Sun, Jun 16, 2013 at 2:00 PM, Amit kapila <amit.kapila@huawei.com> wrote:
> On Saturday, June 15, 2013 8:29 PM Sawada Masahiko wrote:
> On Sat, Jun 15, 2013 at 10:34 PM, Amit kapila <amit.kapila@huawei.com> wrote:
>>
>> On Saturday, June 15, 2013 1:19 PM Sawada Masahiko wrote:
>> On Fri, Jun 14, 2013 at 10:15 PM, Amit Kapila <amit.kapila@huawei.com> wrote:
>>> On Friday, June 14, 2013 2:42 PM Samrat Revagade wrote:
>>>> Hello,
>>>
>>>>>> We have already started a discussion on pgsql-hackers for the problem of
>>>>>> taking fresh backup during the failback operation here is the link for that:
>>>>>>
>>>>>>
>>>>>> http://www.postgresql.org/message-id/CAF8Q-Gxg3PQTf71NVECe-6OzRaew5pWhk7yQtb
>>>>>> JgWrFu513s+Q@mail.gmail.com
>>>>>>
>>>>>> Let me again summarize the problem we are trying to address.
>>>>>>
>>>>>>
>>>>>   How will you take care of extra WAL on old master during recovery. If it
>>>>> plays the WAL which has not reached new-master, it can be a problem.
>>
>>>> you means that there is possible that old master's data ahead of new
>>>> master's data.
>>
>>>   I mean to say is that WAL of old master can be ahead of new master. I understood that
>>>   data files of old master can't be ahead, but I think WAL can be ahead.
>>
>>>> so there is inconsistent data between those server when fail back. right?
>>>> if so , there is not possible inconsistent. because if you use GUC option
>>>> as his propose (i.g., failback_safe_standby_mode = remote_flush),
>>>> when old master is working fine, all file system level changes aren't
>>>> done  before WAL replicated.
>>
>>> Would the propose patch will take care that old master's WAL is also not ahead in some way?
>>> If yes, I think i am missing some point.
>
>> yes it will happen that old master's WAL ahead of new master's WAL as you said.
>> but I think that we can solve them by delete all WAL file when old
>> master starts as new standby.
>
> I think ideally, it should reset WAL location at the point where new master has forrked off.
> In such a scenario it would be difficult for user who wants to get a dump of some data in
> old master which hasn't gone to new master. I am not sure if such a need is there for real users, but if it
> is there, then providing this solution will have some drawbacks.
I think that we can dumping data before all WAL files deleting.  All
WAL files deleting is done when old master starts as new standby.


Regards,

-------
Sawada Masahiko



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [9.4 CF 1] Commit Fest has started
Next
From: Josh Berkus
Date:
Subject: Re: [RFC] Minmax indexes