Moving Database Directory
От | Greg Spiegelberg |
---|---|
Тема | Moving Database Directory |
Дата | |
Msg-id | 3FB3FC17.7020602@cranel.com обсуждение исходный текст |
Ответы |
Re: Moving Database Directory
|
Список | 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@Cranel.com Cranel. Technology. Integrity. Focus.
В списке pgsql-admin по дате отправления: