We have several databases over 700Gb. A full dump can take a very long time.

is there any plan in the future to address migration of databases from
a 8.x.y release to a 8.y.x release..

Due to the current nature of migration( full dump and restore)...we
simply cannot migrate without a lot of down time.

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Fri, Oct 23, 2009 at 4:00 PM, Anj Adu <fotographs [at] gmail.com> wrote:
> We have several databases over 700Gb. A full dump can take =A0a very long=
time.
>
> is there any plan in the future to address migration of databases from
> a 8.x.y release to a 8.y.x release..
>
> Due to the current nature of migration( =A0full dump and restore)...we
> simply cannot migrate without a lot of down time.

We migrate with Slony. Works like a charm and our downtime is usually
only a minute or two.

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Fri, Oct 23, 2009 at 4:00 PM, Anj Adu <fotographs [at] gmail.com> wrote:
> We have several databases over 700Gb. A full dump can take =A0a very long=
time.
>
> is there any plan in the future to address migration of databases from
> a 8.x.y release to a 8.y.x release..

Oh and there's a migration application as of 8.4 that might help.
Gotta have the same basic switches, especially int timestamps versus
fp timestamps.

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

All our postgres versions are 8.1.x..... pg_migrator supports only 8.2
and above..


I''ll check out slony..thanks

On Fri, Oct 23, 2009 at 3:06 PM, Scott Marlowe <scott.marlowe [at] gmail.com> wr=
ote:
> On Fri, Oct 23, 2009 at 4:00 PM, Anj Adu <fotographs [at] gmail.com> wrote:
>> We have several databases over 700Gb. A full dump can take =A0a very lon=
g time.
>>
>> is there any plan in the future to address migration of databases from
>> a 8.x.y release to a 8.y.x release..
>
> Oh and there's a migration application as of 8.4 that might help.
> Gotta have the same basic switches, especially int timestamps versus
> fp timestamps.
>

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Fri, Oct 23, 2009 at 4:26 PM, Anj Adu <fotographs [at] gmail.com> wrote:
> All our postgres versions are 8.1.x..... pg_migrator supports only 8.2
> and above..

We used slony to migrate from 8.1 to 8.3 flawlessly. The nice this is
it let us run the 8.3 database as a slave, where we could point x% of
traffic to it to see how it was working, and spot major problems (we
had exactly two bits of code to fix regarding casting dates to text
that needed fixing anyway).

After a week of testing, we could simply throw the switch and go to
8.3 as the main db. Sequence of events were roughly:

shutdown app layer
run slony failover command
edit config to point to the old db as the main db and vice versa
startup app layer
paint system green to prevent rust

That last step is entirely optional.

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin