Re: Streaming replication and WAL archive interactions

On Tue, Apr 21, 2015 at 4:38 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

> On 04/21/2015 09:53 AM, Michael Paquier wrote:
>
>> On Thu, Apr 16, 2015 at 8:57 PM, Heikki Linnakangas wrote:
>>
>>> Oh, hang on, that's not necessarily true. On promotion, the standby
>>>
>> archives
>>
>>> the last, partial WAL segment from the old timeline. That's just wrong
>>> (http://www.postgresql.org/message-id/52FCD37C.3070806@vmware.com), and
>>> in
>>> fact I somehow thought I changed that already, but apparently not. So
>>>
>> let's
>>
>>> stop doing that.
>>>
>>
>> Er. Are you planning to prevent the standby from archiving the last
>> partial
>> segment from the old timeline at promotion?
>>
>
> Yes.
>
> I thought from previous discussions that we should do it as master
>> (be it crashed, burned, burried or dead) may not have the occasion to
>> do it. By preventing its archiving you close the door to the case
>> where master did not have the occasion to archive it.
>>
>
> The current situation is a mess:
>
> 1. Even though we archive the last segment in the standby, there is no
> guarantee that the master had archived all the previous segments already.
>
2. If the master is not totally dead, it might try to archive the same file
> with more WAL in it, at the same time or just afterwards, or even just
> before the standby has completed promotion. Which copy do you keep in the
> archive? Having to deal with that makes the archive_command more
> complicated.
>
> Note that even though we don't archive the partial last segment on the
> previous timeline, the same WAL is copied to the first segment on the new
> timeline. So the WAL isn't lost.
>

But if the failed master has archived those segments safely, we may need
them, no? I am not sure we can ignore a user who would want to do a PITR
with recovery_target_timeline pointing to the one of the failed master.

>
> People may be surprised that a base backup taken from a node that has
>> archive_mode = on set (that's the case in a very large number of cases)
>> will not be able to work as-is as node startup will fail as follows:
>> FATAL: archive_mode='on' cannot be used in archive recovery
>> HINT: Use 'shared' or 'always' mode instead.
>>
>
> Hmm, good point.
>
> One idea would be to simply ignore the fact that archive_mode = on on
>> nodes
>> in recovery instead of dropping an error. Note that I like the fact that
>> it
>> drops an error as that's clear, I just point the fact that people may be
>> surprised that base backups are not working anymore now in this case.
>>
>
> By "ignore", what behaviour do you mean? Would "on" be equivalent to
> "shared", "always", or something else?
>

I meant something backward-compatible, with files marked as .done when they
are finished replaying... But now my words *are* weird as on != off ;)

Or we could keep the current behaviour with archive_mode=on (except for the
> last segment thing, which is just wrong), where the standby only archives
> the new timeline, and nothing from the previous timelines.
>

I guess this would solve the issue here then, which is not a bad thing in
itself:
http://www.postgresql.org/message-id/20140918180734.361021e1@erg
We would need to check if the situation improves with the 'always' mode btw.

> Are the use cases where you'd want that, rather than the new "shared"
> mode? I wanted to keep the 'on' mode for backwards-compatibility, but if
> that causes more problems, it might be better to just remove it and force
> the admin to choose what kind of a setup he has, with "shared" or "always".
>

The 'on' mode is still useful IMO to get a behavior a maximum close to what
previous releases did.
Regards,
--
Michael