Re: WAL archive is lost

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: WAL archive is lost
Дата
Msg-id CAMkU=1zAeWh7jdFmHw5R9sjJpzq9fKwMxiYp1-m+JOY2Bi1rsg@mail.gmail.com
обсуждение исходный текст
Ответ на WAL archive is lost  ("matsumura.ryo@fujitsu.com" <matsumura.ryo@fujitsu.com>)
Ответы RE: WAL archive is lost  ("matsumura.ryo@fujitsu.com" <matsumura.ryo@fujitsu.com>)
Список pgsql-hackers
On Fri, Nov 22, 2019 at 8:04 AM matsumura.ryo@fujitsu.com <matsumura.ryo@fujitsu.com> wrote:
Hi all

I find a situation that WAL archive file is lost but any WAL segment file is not lost.
It causes for archive recovery to fail. Is this behavior a bug?

example:

  WAL segment files
  000000010000000000000001
  000000010000000000000002
  000000010000000000000003

  Archive files
  000000010000000000000001
  000000010000000000000003

  Archive file 000000010000000000000002 is lost but WAL segment files
  is continuous. Recovery with archive (i.e. PITR) stops at the end of
  000000010000000000000001.

Will it not archive  000000010000000000000002 eventually, like at the conclusion of the next restartpoint?  or does it get recycled/removed without ever being archived?  Or does it just hang out forever in pg_wal?
 


How to reproduce:
- Set up replication (primary and standby).
- Set [archive_mode = always] in standby.
- WAL receiver exits (i.e. because primary goes down)
  after receiver inserts the last record in some WAL segment file
  before receiver notifies the segement file to archiver(create .ready file).

Do you have a trick for reliably achieving this last step?

Cheers,

Jeff

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: dropdb --force
Следующее
От: Joe Conway
Дата:
Сообщение: Re: add a MAC check for TRUNCATE