On Wed, May 02, 2007 at 11:15:55AM -0600, Cameron, Jacob wrote:
> Rather than totally mess up what I have, I figured it'd be quicker to
> ask here.  I have to move my postgres database for DSpace to another
> data disk and I don't want to lose the data.  Can anyone give me a
> recommended way of doing that?  I've never done this before.

I've never done exactly that, but....

The PosgreSQL monitor ('postmaster') is the only part of the system
that knows the location of the database in the filesystem.  You
*should* be able to just shut down the monitor, move the PGDATA (or
-D) directory tree to its new home, and restart the monitor specifying
the new PGDATA path.  Precise details will vary according to how your
PostgreSQL installation is started.  In any case DSpace won't know
that anything has changed -- it deals with the database through a
network connection, and that isn't changing.

I don't think I'm gutsy enough to just 'mv' a database cluster, but
'cp -a' should serve, and then the old copy can be deleted when you're
sure you like the new one.  If something went wrong, you can just
point 'postmaster' at the old location again.

I've assumed here that you want to move the entire database cluster
(all of the databases overseen by a single startup of 'postmaster').
If you're trying to move a database from one cluster to another, you
need to dump/restore, and if you're trying to split a cluster into two
then you'll also need to initialize ('initdb') the new one and start a
'postmaster' for each (on different ports).  If you're only running
PostgreSQL to support one instance of DSpace and nothing else, forget
this whole paragraph. :-)

DO be sure you have a good dump of the database first!  I'd use
pg_dumpall rather than pg_dump, since pg_dumpall will also save PG's
own user credentials tables.  If you should have to recreate the
database, you need the users restored before restoring tables that
refer to them (ownership, GRANTs, and the like).

You *should* already have a script or a cron job or something making
periodic dumps for disaster recovery (unless you've found a system
backup product whose makers aren't studiously ignoring PostgreSQL) and
can look at that to recall the details of dumping your database.

I'm anticipating a similar move, but it isn't scheduled yet so I can't
say when I'll have experience to report.  But what I've said above is
how I plan to do it.

-- 
Mark H. Wood, Lead System Programmer   [EMAIL PROTECTED]
Typically when a software vendor says that a product is "intuitive" he
means the exact opposite.

Attachment: pgp97iu18J76k.pgp
Description: PGP signature

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Reply via email to