RE: PG9.1 migration to PG9.6, dump/restore issues - Mailing list pgsql-general

From Scot Kreienkamp
Subject RE: PG9.1 migration to PG9.6, dump/restore issues
Date
Msg-id 17082AAFC33A934082836458CB53494374C9A5F0@MONDB03.na.lzb.hq
Whole thread Raw
In response to Re: PG9.1 migration to PG9.6, dump/restore issues  (Ron <ronljohnsonjr@gmail.com>)
List pgsql-general

Thanks Ron, glad to hear it worked and someone was successful at it.  I’m on the right path then.

 

 

Scot Kreienkamp |Senior Systems Engineer | La-Z-Boy Corporate
One La-Z-Boy Drive| Monroe, Michigan 48162 | Office: 734-384-6403 | | Mobile: 7349151444 | Email: Scot.Kreienkamp@la-z-boy.com

From: Ron [mailto:ronljohnsonjr@gmail.com]
Sent: Wednesday, September 12, 2018 10:40 AM
To: pgsql-general@lists.postgresql.org
Subject: Re: PG9.1 migration to PG9.6, dump/restore issues

 

On 09/12/2018 08:55 AM, Scot Kreienkamp wrote:

Hi Everyone,

 

I am working on a migration from PG9.1 to PG9.6.  Hoping some people can chime in on my plans as I am running into some restore issues.

 

We are upgrading to a new version of PG and migrating to new hardware with RHEL 7, so I am planning on doing a dump and restore to get moved to the new server.  My database is about 300 gigs, not huge but big enough that doing a single threaded dump with multi-threaded restore is going to take too much time for the window of opportunity I’ve been given.  I know I can use multi-threaded restore on PG9.6 using the custom or directory formats, but PG9.1 only supports single threaded dump.  To get around this I’m going to disable all database access to the PG9.1 databases, then use the PG9.6 tools to do a multi-threaded dump and then multi-threaded restore. 

 

These are the commands I was using:

pg_dump -vj 4 -F d -h $OLDSERVER  $DATABASE -f $BACKUPPATH/DATABASE --no-synchronized-snapshots

created $DATABASE

pg_restore -evj 4 -d $DATABASE  $BACKUPPATH/$DATABASE   --disable-triggers

 


This is almost exactly what I did when migrating from 8.4 to 9.6.  As Adrian Klaver mentioned, you need to dump the globals and then run that script on the new database.

No need to disable triggers, since it's "relevant only when performing a data-only restore", and you aren't doing a data-only restore.  Besides, pg_restore adds all that metadata -- including PKs, FKs, indexes, etc. to the db *after* the data is loaded.

--
Angular momentum makes the world go 'round.

 

This message is intended only for the individual or entity to which it is addressed.  It may contain privileged, confidential information which is exempt from disclosure under applicable laws.  If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information.  If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.

pgsql-general by date:

Previous
From: Scot Kreienkamp
Date:
Subject: RE: PG9.1 migration to PG9.6, dump/restore issues
Next
From: Tom Lane
Date:
Subject: Re: Code of Conduct plan