Thread: Upgrading from 9.1 to 9.2 in place, same machine

On Wed, Jul 10, 2013 at 1:53 PM, Wells Oliver <wellsoliver@gmail.com> wrote:
> I have 9.1 running on 5432, and 9.2 running on 5433. The 9.1 database size
> is 153g. 9.1 is actively used by systems, 9.2 is just sitting there empty.
>
> I'd like to move the 9.1 database to 9.2 without any down time, and ensuring
> that no data is lost.
>
> My original idea was to make 9.2 a slave of 9.1, then switch it over.
>
> Is there a better idea? Thanks for any tips.

have you looked at simply using pg_upgrade ?

http://www.postgresql.org/docs/9.2/static/pgupgrade.html


>
> --
> Wells Oliver
> wellsoliver@gmail.com

On 07/10/2013 11:53 AM, Wells Oliver wrote:
> I'd like to move the 9.1 database to 9.2 without any down time, and
> ensuring that no data is lost.
>
> My original idea was to make 9.2 a slave of 9.1, then switch it over.

You can't do this with streaming replication.  But you can with slony.
Just replicate from 9.1 as master to 9.2 as a slave.  Once they are
fully in sync, promote 9.2 to master.

Note that you will have to restart postgres at least once to move the
9.2 port to the same as the 9.1 port when you switch.  SO it won't be
zero down time, but pretty darn close.

    - Chris

On Wed, Jul 10, 2013 at 02:08:04PM -0400, Jonathan Nalley wrote:
> On Wed, Jul 10, 2013 at 1:53 PM, Wells Oliver <wellsoliver@gmail.com> wrote:
> > I have 9.1 running on 5432, and 9.2 running on 5433. The 9.1 database size
> > is 153g. 9.1 is actively used by systems, 9.2 is just sitting there empty.
> >
> > I'd like to move the 9.1 database to 9.2 without any down time, and ensuring
> > that no data is lost.
> >
> > My original idea was to make 9.2 a slave of 9.1, then switch it over.
> >
> > Is there a better idea? Thanks for any tips.
>
> have you looked at simply using pg_upgrade ?
>
> http://www.postgresql.org/docs/9.2/static/pgupgrade.html
>

Hi Wells,

I would definitely consider pgupgrade. You could test it first to get
some timings. I would make a 9.1 slave on the same box and run pg_upgrade
against it. Then if you have a problem you can restart using the original.
You can also use something like slony or bucardo to replicate from 9.1 to
9.2 and then failover to it that way.

Regards,
Ken

On Wed, Jul 10, 2013 at 11:52:54AM -0700, Wells Oliver wrote:
> Can anyone speak to the speed of pg_upgrade? Our database is 153GB. From
> 9.1 to 9.2, I'm nervous it might take hours. If it were less than hour,
> downtime would be more acceptable.
>

You can use the --link option and then you make hard links instead of
requiring a copy of the data files. It should be pretty fast. Without
--link a copy of 153GB could take a while. :)

http://www.postgresql.org/docs/9.2/interactive/pgupgrade.html

Ken

On Wed, Jul 10, 2013 at 12:02:06PM -0700, Wells Oliver wrote:
> Hard linking means that you must maintain 8.2's data directory though, even
> after upgrade, correct? Since it's a link and not a copied file.
>
I think it only hard links the files to the new 9.2 data directory so you
can delete the old data directory and the files will still be in the new
directory since the link count will be > 0.

Ken

On Wed, 10 Jul 2013, Vincent Lau wrote:

> On Wed, Jul 10, 2013 at 12:19 PM, Wells Oliver <wellsoliver@gmail.com>wrote:
>
>> OK, cool. I did not want to be in a position where I stop the servers,
>> pg_upgrade --link 9.1 to 9.2, then (eventually) pg_dropcluster of 9.1 and,
>> woops, I killed all of my data files.
>>
>>
> And if you have enough storage, you can always stage a testing environment
> and test this out. It'd tell you how long the whole upgrade would take too.
> :)
>
>
>
>>
>> On Wed, Jul 10, 2013 at 12:13 PM, ktm@rice.edu <ktm@rice.edu> wrote:
>>
>>> On Wed, Jul 10, 2013 at 12:02:06PM -0700, Wells Oliver wrote:
>>>> Hard linking means that you must maintain 8.2's data directory though,
>>> even
>>>> after upgrade, correct? Since it's a link and not a copied file.
>>>>
>>> I think it only hard links the files to the new 9.2 data directory so you
>>> can delete the old data directory and the files will still be in the new
>>> directory since the link count will be > 0.
>>>
>>> Ken
>>>
>>
>>
>>
>> --
>> Wells Oliver
>> wellsoliver@gmail.com
>>
>
>
>
> --
> Vincent Lau | Database Administrator
> 503.284.7581 x394 | vincent.lau@rentrak.com <vincent.lau@rentrakmail.com>
> RENTRAK | www.rentrak.com | NASDAQ: RENT
>
> Notice: This message is confidential and is intended only for the
> recipient(s) named above. If you have received this message in error,
> or are not the named recipient(s), please immediately notify the
> sender and delete this message.
>


how would pg_upgrade be used to upgrade to a new machine
use nfs?
would i run pg_upgrade on the new server?

On Wed, Jul 10, 2013 at 03:46:28PM -0500, lxnf98mm@gmail.com wrote:
> On Wed, 10 Jul 2013, Vincent Lau wrote:
>
> how would pg_upgrade be used to upgrade to a new machine
> use nfs?
> would i run pg_upgrade on the new server?
>
>

I would replicate to the new server from the old using WAL to get
an up to date copy of the DB. Shutdown the new copy and run pg_upgrade.
Then you can fallback to the old system if there is a problem.

Regards,
Ken