Re: [HACKERS] Point in Time Recovery

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Point in Time Recovery
Date: 2004-07-19 03:14:10
Message-ID: 200407190314.i6J3EAJ07392@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers pgsql-patches


What is the process of logging to tape? Ideally we could just do 'dd'
to the tape drive in append mode; however we need a way of signalling
that we want to change tapes.

The only method I can think of is to have PITR dump the files into a
holding directory, and have a daemon that scans the directory and writes
files to tape when they are completely copied (how do we detect that?
Use 'mv' after the copy? Seems like a good use for our new %
parameters). Then we need a control program to signal the daemon to
stop archiving to tape, have it set a flag file so we know it is
suspended tape writes, report that back to the client, change tapes,
then tell it to restart.

I am asking to make sure we don't need a PITR pause mode that prevents
WAL files from being archived but also prevents them from being
recycled. If we did that, we could probably append to tape directly,
but then we need to go into 'pause archive" mode in the PITR process,
and such switching seems like a pain and the wrong place to do it.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > So you want to merge them all into a single command string. That does
> > seem less error-prone. I see a few variables that turn off
> > when set to '' like unix_socket_*. How would this command string work?
> > How do you specify the WAL file name to transfer?
>
> No different from before, necessarily. However I did not like the
> restriction to a single %s in the submitted implementation. What I
> have in my local copy is
> %p -> full path of XLOG file to be archived
> %f -> base name of XLOG file to be archived
> and the suggested example becomes
> archive_command = 'cp %p /mnt/server/pgarchive/%f'
>
> Note that this example immediately eliminates one of the failure modes
> Simon enumerates in his README, which is to try 'cp %s /foo' where /foo
> isn't a directory. More generally, though, *only* a cp-to-directory
> solution is likely to be very happy with not being able to get at the
> base file name. Yes you can make a shellscript and use basename,
> but I don't think you should have to do that if it could otherwise
> be a one-liner.
>
> (In case it's not obvious from the above, I am hacking with intent to
> commit soon. Maybe tomorrow, if my wife doesn't make me paint the
> bathroom instead...)
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Bruce Momjian 2004-07-19 03:21:31 Re: [HACKERS] Point in Time Recovery
Previous Message Tom Lane 2004-07-19 03:13:50 Re: [HACKERS] Point in Time Recovery

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-07-19 03:21:31 Re: [HACKERS] Point in Time Recovery
Previous Message Tom Lane 2004-07-19 03:13:50 Re: [HACKERS] Point in Time Recovery

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2004-07-19 03:21:31 Re: [HACKERS] Point in Time Recovery
Previous Message Tom Lane 2004-07-19 03:13:50 Re: [HACKERS] Point in Time Recovery