Re: Migrate postgres to newer hardware

Поиск
Список
Период
Сортировка
От Brad Nicholson
Тема Re: Migrate postgres to newer hardware
Дата
Msg-id 1269964186.5155.204.camel@bnicholson-desktop
обсуждение исходный текст
Ответ на Re: Migrate postgres to newer hardware  (Tino Schwarze <postgresql@tisc.de>)
Список 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 по дате отправления:

Предыдущее
От: jose javier parra sanchez
Дата:
Сообщение: Re: Migrate postgres to newer hardware
Следующее
От: Greg Smith
Дата:
Сообщение: Re: [PERFORM] Database size growing over time and leads to performance impact