Re: Moving a live production database to different server and postgres release

Поиск
Список
Период
Сортировка
От Ulas Albayrak
Тема Re: Moving a live production database to different server and postgres release
Дата
Msg-id AANLkTikC1UJq2oOwddWb-_vcRy-TVLUG7uzvabOGE3id@mail.gmail.com
обсуждение исходный текст
Ответы Re: Re: Moving a live production database to different server and postgres release  (Raymond O'Donnell <rod@iol.ie>)
Re: Re: Moving a live production database to different server and postgres release  ("Greg Sabino Mullane" <greg@turnstep.com>)
Re: Re: Moving a live production database to different server and postgres release  (Scott Marlowe <scott.marlowe@gmail.com>)
Список pgsql-general
The database is < 10GB and currently on a postgres version 8.2.15 on a
BSD system and moving to postgres version 8.4.4 on a windows 2008
server. The adding of data is continuous but in small quantities,
totaling at about 20MB a day.

After your post I had a look at Slony-I, which, according to it web
page, requires postgres 8.3 or later, so I guess that won't work. That
leaves Bucardo: will it work on a Windows system?

/Regards


> > My best idea so far is to do a pg_dump and somehow archive all the DML
> > in the original db from that point in time for later insertion in the
> > new db, but I dont know how that would be done practically. And I
> > dont even know if thats the best way to go, as I said, its only an
> > idea.
>
> What you need is a replication system. Take a look at Slony or Bucardo.
> Basically, you copy over everything except for the data to the new
> database, switch the replication system on, let it catch up, then
> stop apps from hitting the server, wait for the new one to catch up,
> and point your apps to the new one.
>
> Important factors that you left out are exactly how big your database is,
> what version you are on, what version you are moving to, and how busy your
> system is. Also keep in mind that both Bucardo and Slony are trigger based
> on primary keys or unique indexes, so tables without such constraints
> cannot be replicated: you'll need to either add a unique constraint to
> the tables, or copy them separately (e.g. pg_dump -t tablename or
> Bucardo's fullcopy mode).
>
> If you weren't also moving your OS and server, pg_migrator (aka pg_upgrade)
> might work for you as well: it does an inplace, one-time upgrade but only
> supports a limited number of versions at the moment.
>
> - --
> Greg Sabino Mullane greg@turnstep.com
> End Point Corporation http://www.endpoint.com/
> PGP Key: 0x14964AC8 201006110927
> http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8


--
Ulas Albayrak
ulas.albayrak@gmail.com

В списке pgsql-general по дате отправления:

Предыдущее
От: Jeff Amiel
Дата:
Сообщение: Advice on contingency plan for DAS array with separate local WAL drives
Следующее
От: Jeff Amiel
Дата:
Сообщение: Re: Advice on contingency plan for DAS array with separate local WAL drives