Moving Database Directory

From: Greg Spiegelberg <gspiegelberg(at)cranel(dot)com>
To: Postgres Admin List <pgsql-admin(at)postgresql(dot)org>
Subject: Moving Database Directory
Date: 2003-11-13 21:48:07
Message-ID: 3FB3FC17.7020602@cranel.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hiya,

I have an interesting problem and haven't found an answer yet on
Google.

On systemA we have a LUN from our SAN mounted as /data and one instance
of 7.3.4 with many databases. Each database has it's own PGDATA
directory: /data/dbA1 for dbA1 database. /data/dbA2 for dbA2 and so on.
The default PGDATA for systemA, which pg_hba.conf, template0, etc lives
is /data/systemA.

Via Sistina GFS systemB has the same LUN mounted as /data, runs it's own
7.3.4 database with using /data/systemB for pg_hba.conf, template0, etc
and has databases dbB1 and dbB2 under /data/dbB1 and /data/dbB2
respectively.

This works. Sistina GFS manages block allocation and everything so the
systems don't see anything out of the ordinary.

Here's the curveball / question.

Is there a way to "deport" a database on systemA and "import" it on
systemB without having to do a pg_dump/pg_restore? Basically ask
the database on systemA to stop using dbA1 under /data/dbA1 then tell
systemB to use the database already at /data/dbA1.

I know I could take postgres down completely on systemA and start it
up on systemB but that would migrate all databases, I want to do only
one, and effectively cut my resources in half on systemB.

I figure the answer will be "no" due to OID number issues, but what say
you Admins?

While I'm here, anyone have experience with Sistina GFS? This is
completely theoretical right now and we're looking at Sistina GFS to
consolidate our storage and make better use of the space we have.

TIA,
Greg

--
Greg Spiegelberg
Sr. Product Development Engineer
Cranel, Incorporated.
Phone: 614.318.4314
Fax: 614.431.8388
Email: gspiegelberg(at)Cranel(dot)com
Cranel. Technology. Integrity. Focus.

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message ow 2003-11-13 22:02:41 pg_restore and FK constraints with large dbs
Previous Message Piyush Agarwal 2003-11-13 20:59:45 PG_CONTROL_VERSION ERROR