Hi Mark, This method worked perfectly. I copied my entire DSpace instance over to the new data drive, copied the postgres database, did a clean build to update the changes, copied the war files back into place and started up. Nothing wrong, everything worked perfectly. The only thing I had to do was update the log4j.properties and log4j-handle.plugin.properties files to update the new dspace location so the logs could be appended. I haven't seen any other problems since that. Thanks for the advice, works perfectly!
Jake -- Jake Cameron, BCSc(UNB) Technical Specialist III Library Systems and Web Services University of Lethbridge Phone: (403) 329-2756 Office: L1110C Email: [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark H. Wood Sent: Wednesday, May 02, 2007 3:43 PM To: [email protected] Subject: Re: [Dspace-tech] Moving postgres database 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. ------------------------------------------------------------------------- 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
