Обсуждение: upgrading postgres version
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.
On Fri, Oct 23, 2009 at 4:00 PM, Anj Adu <fotographs@gmail.com> wrote: > 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. We migrate with Slony. Works like a charm and our downtime is usually only a minute or two.
On Fri, Oct 23, 2009 at 4:00 PM, Anj Adu <fotographs@gmail.com> wrote: > 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.. 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.
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@gmail.com> wrote: > On Fri, Oct 23, 2009 at 4:00 PM, Anj Adu <fotographs@gmail.com> wrote: >> 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.. > > 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. >
On Fri, Oct 23, 2009 at 4:26 PM, Anj Adu <fotographs@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.