Re: The quickest way to migrate database within the same cluster

["Zheng, Wendy" <wendy.zheng@xxxxxxx>]

The tables have the same schema, but in different DB. Because I create the table in the new DB, so the table of the same name in different DB have different filenode too. For example, the data file of old DB is under /pgsql/data/base/16384/, while the data file of new DB is under /dbdata/uemcp_tblspc/PG_9.1_201105231/16481 (I created the new table in a table space). Then the filenode for my table user_information in old DB is 34576, and that in the new DB is 45663. Then I perform the following to switch the data files:

mv /dbdata/uemcp_tblspc/PG_9.1_201105231/16481/45663 /dbdata/uemcp_tblspc/PG_9.1_201105231/16481/45663_bak

mv /pgsql/data/base/16384/34576 /dbdata/uemcp_tblspc/PG_9.1_201105231/16481/45663

mv /dbdata/uemcp_tblspc/PG_9.1_201105231/16481/45663_bak /pgsql/data/base/16384/34576

mv /dbdata/uemcp_tblspc/PG_9.1_201105231/16481/45663_fsm /dbdata/uemcp_tblspc/PG_9.1_201105231/16481/45663_fsm_bak

mv /pgsql/data/base/16384/34576_fsm /dbdata/uemcp_tblspc/PG_9.1_201105231/16481/45663_fsm

mv /dbdata/uemcp_tblspc/PG_9.1_201105231/16481/45663_fsm_bak /pgsql/data/base/16384/34576_fsm

 

I do that for all of my tables. Looks like I can still query and insert records.

 

Thanks,

Wendy

 

From: Rosser Schwarz [mailto:rosser.schwarz@xxxxxxxxx]
Sent: Sunday, January 04, 2015 3:19 PM
To: Zheng, Wendy
Cc: pgsql-admin@xxxxxxxxxxxxxx
Subject: Re: [ADMIN] The quickest way to migrate database within the same cluster

 

On Sat, Jan 3, 2015 at 10:52 PM, Zheng, Wendy <wendy.zheng@xxxxxxx> wrote: 

I’m working on a task to move tables from on database to another within the same cluster and same server...

 

Your second idea, of copying the underlying disk files, probably won't work unless you're also copying all the relevant records from all of the system catalog tables (a non-trivial task, itself), and likely not even then. (For instance, if two tables in the different databases have the same 'relfilenode', you're going to overwrite that table in the second when you perform the copy, and because those tables probably have different structures, you'll then see "unexpected" behavior.)

 

You might instead try piping the output of a "COPY ($query) TO STDOUT" in a psql session against the source database into a "COPY table FROM STDIN" command in a psql session against the destination. That would filter on the source side, but would require you to have empty tables of the expected structure on the destination to receive the data.

 

rls

 

--

:wq