From: Jerry Sievers <gsievers19@comcast.net>
To: Mark Steben <mark.steben@drivedominion.com>
Cc: Jerry Sievers <gsievers19@comcast.net>,
  pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: will this upgrade strategy work?
References: 
 <CADyzmyyB2HY8Kzjdb0OVQXkmQSxH4Rb+C+13uupM3k5RwdmOOA@mail.gmail.com>
	<87pnxrrbtp.fsf@jsievers.enova.com>
	<CADyzmyyXbyRLDeUHyck+6PK+za7-DbPnOML6GLCHSpc5Py+oaA@mail.gmail.com>
Date: Wed, 05 Sep 2018 16:01:39 -0500
In-Reply-To: 
 <CADyzmyyXbyRLDeUHyck+6PK+za7-DbPnOML6GLCHSpc5Py+oaA@mail.gmail.com>
	(Mark Steben's message of "Wed, 5 Sep 2018 15:28:28 -0400")
Message-ID: <8736un7j64.fsf@jsievers.enova.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Mark Steben <mark.steben@drivedominion.com> writes:

> HI Jerry
>
> Thanks for your response.=C2=A0 Is the copy option of pg_upgrade faster
> than a traditional pg_dump-restore?

It should be unless the system is horribly bloated.  But your proposal
doesn't specify dump/restore anyway.

> Remember we are striving for speed and mimimal downtime.

Then consider doing a logical live replica  using any of slony, skytools
or pglogical from your 9.4 system into 9.6 and then just promote the 9.6
system and run on it.

FYI

>
> On Wed, Sep 5, 2018 at 3:20 PM, Jerry Sievers <gsievers19@comcast.net
>> wrote:
>
>     Mark Steben <mark.steben@drivedominion.com> writes:
>=20=20=20=20
>     > Good afternoon, team.
>     >
>     > We wish to do a postgres upgrade from 9.4 to 9.6.=C2=A0 In order to
>     > minimize downtime we were thinking to do this:
>     > =C2=A0 1. bring postgres down (9.4 is on 'diskset 1')
>     > =C2=A0 2. do a physical copy of the data to 'diskset 2' (same
>     phyxical
>     > server.
>     > =C2=A0 3.=C2=A0 do an inplace pg_upgrade=C2=A0 to 9.6 on 'diskset 2'
>=20=20=20=20
>     Note that the copy (vs link) option of pg_upgrade is
>     non-destructive and
>     probably a simpler version than what you're proposing.
>=20=20=20=20
>     Whatever method you choose, best do a prior test run in a
>     non-prod
>     setting to insure everything is correct.
>=20=20=20=20
>     HTH
>=20=20=20=20
>=20=20=20=20
>     > =C2=A0 4.=C2=A0 Bring postgres up on 9.6 diskset 2
>     > =C2=A0This way we have 9.4 on diskset 1 to fall back on.
>     >
>     > This would work much faster than the traditional dump restore.
>     >
>     > Any comments welcome.=C2=A0 Thanks.
>     >
>     >
>     > --
>     > Mark Steben
>     > =C2=A0Database Administrator
>     > @utoRevenue=C2=A0|=C2=A0Autobase=C2=A0
>     > =C2=A0 CRM division of Dominion Dealer Solutions=C2=A0
>     > 95D Ashley Ave.
>     > West Springfield, MA 01089
>     > t: 413.327-3045
>     > f: 413.383-9567
>     >
>     > www.fb.com/DominionDealerSolutions
>     > www.twitter.com/DominionDealer
>     > =C2=A0www.drivedominion.com
>     >
>     >=C2=A0
>     >
>     >
>     >
>     >
>     >
>     >
>=20=20=20=20
>     --
>     Jerry Sievers
>     Postgres DBA/Development Consulting
>     e: postgres.consulting@comcast.net
>     p: 312.241.7800
>
>
>
>
> --
> Mark Steben
> =C2=A0Database Administrator
> @utoRevenue=C2=A0|=C2=A0Autobase=C2=A0
> =C2=A0 CRM division of Dominion Dealer Solutions=C2=A0
> 95D Ashley Ave.
> West Springfield, MA 01089
> t: 413.327-3045
> f: 413.383-9567
>
> www.fb.com/DominionDealerSolutions
> www.twitter.com/DominionDealer
> =C2=A0www.drivedominion.com
>
>=20=20
>
>
>
>
>
>

--=20
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
p: 312.241.7800