Re: need for in-place upgrades (was Re: State of Beta 2)

Поиск
Список
Период
Сортировка
От Ron Johnson
Тема Re: need for in-place upgrades (was Re: State of Beta 2)
Дата
Msg-id 1063468365.11739.44.camel@haggis
обсуждение исходный текст
Ответ на Re: need for in-place upgrades (was Re: State of Beta 2)  ("Marc G. Fournier" <scrappy@postgresql.org>)
Ответы Re: need for in-place upgrades (was Re: State of Beta 2)  ("Marc G. Fournier" <scrappy@postgresql.org>)
Re: need for in-place upgrades (was Re: State of Beta 2)  (Andrew Sullivan <andrew@libertyrms.info>)
Список pgsql-general
On Sat, 2003-09-13 at 10:10, Marc G. Fournier wrote:
> On Fri, 12 Sep 2003, Ron Johnson wrote:
>
> > On Fri, 2003-09-12 at 17:48, Joshua D. Drake wrote:
> > > Hello,
> > >
> > >   The initdb is not always a bad thing. In reality the idea of just
> > > being able to "upgrade" is not a good thing. Just think about the
> > > differences between 7.2.3 and 7.3.x... The most annoying (although
> > > appropriate) one being that integers can no longer be ''.
> >
> > But that's just not going to cut it if PostgreSQL wants to be
> > a serious "player" in the enterprise space, where 24x7 systems
> > are common, and you just don't *get* 12/18/24/whatever hours to
> > dump/restore a 200GB database.
> >
> > For example, there are some rather large companies whose fac-
> > tories are run 24x365 on rather old versions of VAX/VMS and
> > Rdb/VMS, because the DBAs can't even get the 3 hours to do
> > in-place upgrades to Rdb, much less the time the SysAdmin needs
> > to upgrade VAX/VMS to VAX/OpenVMS.
> >
> > In our case, we have systems that have multiple 300+GB databases
> > (working in concert as one big system), and dumping all of them,
> > then restoring (which includes creating indexes on tables with
> > row-counts in the low 9 digits, and one which has gone as high
> > as 2+ billion records) is just totally out of the question.
>
> 'k, but is it out of the question to pick up a duplicate server, and use
> something like eRServer to replicate the databases between the two
> systems, with the new system having the upgraded database version running
> on it, and then cutting over once its all in sync?

So instead of 1TB of 15K fiber channel disks (and the requisite
controllers, shelves, RAID overhead, etc), we'd need *two* TB of
15K fiber channel disks (and the requisite controllers, shelves,
RAID overhead, etc) just for the 1 time per year when we'd upgrade
PostgreSQL?

Not a chance.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson@cox.net
Jefferson, LA USA

Thanks to the good people in Microsoft, a great deal of the data
that flows is dependent on one company. That is not a healthy
ecosystem. The issue is that creativity gets filtered through
the business plan of one company.
Mitchell Baker, "Chief Lizard Wrangler" at Mozilla


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

Предыдущее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: need for in-place upgrades (was Re: State of Beta 2)
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: need for in-place upgrades (was Re: State of Beta 2)