Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)
Дата
Msg-id CAHGQGwG-gXQmT_LnOeV4SQ9wN5WkC1embU995u8j388CR+RZTA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)
Список pgsql-hackers
On Fri, Oct 24, 2014 at 10:05 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> On 10/23/2014 11:09 AM, Heikki Linnakangas wrote:
>>
>> At least for master, we should consider changing the way the archiving
>> works so that we only archive WAL that was generated in the same server.
>> I.e. we should never try to archive WAL files belonging to another
>> timeline.
>>
>> I just remembered that we discussed a different problem related to this
>> some time ago, at
>>
>> http://www.postgresql.org/message-id/20131212.110002.204892575.horiguchi.kyotaro@lab.ntt.co.jp.
>> The conclusion of that was that at promotion, we should not archive the
>> last, partial, segment from the old timeline.
>
>
> So, this is what I came up with for master. Does anyone see a problem with
> it?

What about the problem that I raised upthread? This is, the patch
prevents the last, partial, WAL file of the old timeline from being archived.
So we can never PITR the database to the point that the last, partial WAL
file has. Isn't this problem? For example, please imagine the
following scenario.

1. The important data was deleted but no one noticed that. This deletion was   logged in last, partial WAL file.
2. The server crashed and DBA started an archive recovery from old backup.
3. After recovery, all WAL files of the old timeline were recycled.
4. Finally DBA noticed the loss of important data and tried to do PITR
to the point   where the data was deleted.

HOWEVER, the WAL file containing that deletion operation no longer exists.
So DBA will never be able to recover that important data ....

Regards,

-- 
Fujii Masao



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Tomas Vondra"
Дата:
Сообщение: Re: proposal: CREATE DATABASE vs. (partial) CHECKPOINT
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: alter user set local_preload_libraries.