Re: PITR Archival

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: PITR Archival
Дата
Msg-id 1087318564.12015.44.camel@stromboli
обсуждение исходный текст
Ответ на PITR Archival  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: PITR Archival  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-patches
On Tue, 2004-06-15 at 16:34, Simon Riggs wrote:
> I enclose a working set of context diff patches and new files to make
> PITR archiving work, as of cvstip (NOW).
>
> You'll see the new options in the postgresql.conf...though you may wish
> to use archive_debug = true as well, when testing.
>
> There is one bug: shutdown doesn't work quite right. I haven't fixed
> this because I've spent too long trying to decipher how pgstat did a
> clean shutdown, discovering now that it didn't and that has now been
> patched...something similar is required for pgarch, but I'm out of time
> now...leaving time for discussion of this lot...
>

The patch creates a further child process of postmaster, the archiver.

Archiver code is similar, but not the same, as pgstat.c, and by analogy
lives in src/backend/postmaster/pgarch.c with a matching pgarch.h in
src/include (just as with pgstat.h)

At various points, 5 processes are involved, all of which are identified
clearly in the debugging messages...
- backend: sends signal to postmaster to say xlog is ready to archive
- postmaster: catches and resends to archiver
- archiver: then calls system(3) to invoke a user-defined archival task
- bgwriter: later cleans up archive_status at checkpoint time

Please note: you will need to initdb to make this work

Also note: archive_mode is not designed to be turned on/off frequently.
It is possible to confuse it if you turn it on, then restart with it
off, then turn it on again. That is likely to create a "hole" in the
archive history of xlogs and you will not be able to recover correctly.

You may also note that the design has changed substantially from many
earlier design postings...all of this is based on community input to
rationalise behaviour and to streamline code.

If you wish to test recovery, you should:
- do a full physical backup of DataDir, while postmaster is UP
- archive all xlogs

when disaster strikes
- restore backup of DataDir
- restore all archived xlogs to pg_xlog
- startup postmaster (and watch...)

Further work is still required to make it STOP recovering at a
predetermined point in time....

Best regards, Simon Riggs


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Fix for erroneous warning on Shutdown
Следующее
От: Andreas Pflug
Дата:
Сообщение: Re: stderr & win32 admin check