Re: Help with data transfer please - Mailing list pgsql-general

From Alan
Subject Re: Help with data transfer please
Date
Msg-id 007801c210f3$1bf2f5c0$6601a8c0@AlanJWayne
Whole thread Raw
In response to Re: Help with data transfer please  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-general
Sorry for my stupidity, can you tell me where
the default base directory of $PGDATA is on
RH Linux (most recent version)? And perhaps
what tar options are necessary to follow the tree's
branches?

Thanks for any help,
ajw

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Andrew Sullivan" <andrew@libertyrms.info>
Cc: "'pgsql-general'" <pgsql-general@postgresql.org>
Sent: Monday, June 10, 2002 9:00 PM
Subject: Re: [GENERAL] Help with data transfer please


> Andrew Sullivan <andrew@libertyrms.info> writes:
> > On Mon, Jun 10, 2002 at 04:30:26PM -0400, terry@greatgulfhomes.com
wrote:
> >> It is my understanding that copying the files that reside in the data
> >> directory are not sufficient for a backup/restore, (because there are
file
> >> pointers within the data files I believe, pointers which are no longer
valid
> >> on a different server because different blocks get assigned to
different
> >> files).  Therefore it follows that an rsync would not be sufficient to
keep
> >> the database in sync.
>
> > Hmm.  That sounds plausible.  But you can tar up a data directory,
> > and restore it later on a different physical device, and it will
> > work.  Or, at least, it has worked for me.  This, only if the
> > postmaster is shut down.  But maybe my case was just a fluke.
>
> Andrew is correct: you can tar a complete $PGDATA tree and move it to
> another machine (of the same architecture anyway --- differences in
> endianness, datatype alignment requirements, or floating-point
> representation can still mess you up).
>
> What people keep trying to do that *does not* work is to copy only a
> subset of the $PGDATA tree, such as $PGDATA/base/somedb/.  This does not
> work because only part of the system state is in the data files --- the
> rest is in the transaction status log (pg_clog/ directory in 7.2, pg_log
> table in older releases).  You can't get away with copying a data file
> into another installation that has different contents of pg_clog,
> because the transaction numbers will be out of sync.
>
> Ordinarily you need to copy the pg_xlog/ contents that go with the
> data files too.  For data transfer purposes (not disaster recovery)
> you could omit that subdirectory in favor of running pg_resetxlog
> at the destination; but I doubt it's worth the trouble.
>
> And yes, you'd better have the postmaster shut down, because otherwise
> tar is likely to collect pg_clog entries that are out of step with the
> data files --- not to mention the prospect that there are unwritten
> modifications still in memory.
>
> As far as the original question goes --- I suppose you could shut down
> the postmaster and run rsync to keep a remote backup copy up-to-date,
> as long as the backup was just a cold-storage duplicate.  Don't try to
> start a postmaster in it till you want to make it your primary (else
> transaction numbers will get out of sync).
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html


pgsql-general by date:

Previous
From: "Alan"
Date:
Subject: Re: Help with data transfer please
Next
From: Curt Sampson
Date:
Subject: Re: size of units in postgresql.conf