From: Brad Nicholson <bnichols@ca.afilias.info>
To: Tino Schwarze <postgresql@tisc.de>
Cc: pgsql-admin@postgresql.org
Subject: Re: Migrate postgres to newer hardware
Date: Tue, 30 Mar 2010 11:49:46 -0400
Message-ID: <1269964186.5155.204.camel@bnicholson-desktop> (raw)
In-Reply-To: <20100330143831.GE17567@easy5.in-chemnitz.de>
References: <7965A9DCF12CC14984420BCC37B1608F25AB1AED49@Elzar.grant.co.uk>
<1269959369.15416.5.camel@deimos>
<20100330143831.GE17567@easy5.in-chemnitz.de>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: bnichols@ca.afilias.info, postgresql@tisc.de
Subject: Re: Migrate postgres to newer hardware
In-Reply-To: <1269964186.5155.204.camel@bnicholson-desktop>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox