Re: Migrate postgres to newer hardware - Mailing list pgsql-admin

From Brad Nicholson
Subject Re: Migrate postgres to newer hardware
Date
Msg-id 1269964186.5155.204.camel@bnicholson-desktop
Whole thread Raw
In response to Re: Migrate postgres to newer hardware  (Tino Schwarze <postgresql@tisc.de>)
List pgsql-admin
On Tue, 2010-03-30 at 16:38 +0200, Tino Schwarze wrote:
> Hi Renato,
>
> dump/restore is the way to go. I suppose, you don't want to compile
> Postgres for 32 bit on the new machine which might work and might allow
> you to do the PITR migration.
>
> And "downtime is not an option" is always a sign of insufficient
> planning beforehand.

First, there is a big difference between saying "downtime is not an
option" and "several hours of downtime is not an option".

Lack of planning is launching a system without having the procedures and
tooling in place to cope with the technical issues while functioning
within your contractual constraints.

Many of people have tight contracts about system availability with end
customers, often with financial penalties associated for failure to
comply.  Dump and restore of a large system is something that can take a
very long time, and can't always fit inside those maintenance windows.

> There is no system which doesn't need an upgrade or
> reboot or whatever, so there will be downtime and it needs to be
> considered during system analysis.

Correct.  One of the reasons we (Afilias) wrote Slony was so that we
could quickly move the services from one database to another with a
short application outage.  That gives us the freedom to do many
maintenances without having the application down for extended periods.
PG upgrades fit nicely into this.  The only outage is a brief one to
move master and re-point the target.  You can measure the time in
minutes (or even seconds if your procedures are automated enough).

> In my experience, it is often just a matter of communicating: "Because
> of hardware upgrades, the system XYZ will not be available on ..."

Again, this will depend on business drivers.

> After all the switch won't be without interruption - you need to switch
> to the new server anyway.

There is a very big difference between saying the system will be down
for a short duration during a Slony switchover and the system will be
down for several hours while doing a dump and restore.

--
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.



pgsql-admin by date:

Previous
From: jose javier parra sanchez
Date:
Subject: Re: Migrate postgres to newer hardware
Next
From: Greg Smith
Date:
Subject: Re: [PERFORM] Database size growing over time and leads to performance impact