RE: PG9.1 migration to PG9.6, dump/restore issues

From: Scot Kreienkamp <Scot(dot)Kreienkamp(at)la-z-boy(dot)com>
To: Ron <ronljohnsonjr(at)gmail(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: RE: PG9.1 migration to PG9.6, dump/restore issues
Date: 2018-09-12 18:31:55
Message-ID: 17082AAFC33A934082836458CB53494374C9A5F0@MONDB03.na.lzb.hq
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)Kreienkamp(at)la-z-boy(dot)com
From: Ron [mailto:ronljohnsonjr(at)gmail(dot)com]
Sent: Wednesday, September 12, 2018 10:40 AM
To: pgsql-general(at)lists(dot)postgresql(dot)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.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2018-09-12 20:53:46 Re: Code of Conduct plan
Previous Message Scot Kreienkamp 2018-09-12 18:30:25 RE: PG9.1 migration to PG9.6, dump/restore issues