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

Поиск
Список
Период
Сортировка
От Guy Fraser
Тема Re: need for in-place upgrades (was Re: State of Beta 2)
Дата
Msg-id 3F70B327.2090008@incentre.net
обсуждение исходный текст
Ответ на Re: need for in-place upgrades (was Re: State of Beta 2)  (Andrew Sullivan <andrew@libertyrms.info>)
Список pgsql-general
Under circumstances where I have had critical upgrades I have usualy
used a new machine
to build the new upgrade. This allows me to use revitalized equipment
and a "clean" install
for the upgraded server. If something goes sideways, you just switch
back to the old machine.
This is ususaly the quickest and most reliable method of upgrading a server.

Under a few circumstances I have not had a second machine, so I either
put in a new drive
and installed fresh, mounting the original drive to copy the old data to
the new drive before
any modification. Then if the upgrade goes sideways, just switch drives.
This takes longer to
recover.

When I have upgraded under the most stringent ecomonic restraints, I
have backed up the
original data and configuration files before making any changes. This is
the most error
prone method of upgrading a server, and takes the longest time to recover.

Using mirrored drives and splitting the mirror so that you have two
identical data sets can also
be feasible. I did this once successfuly but it requires having a spare
drive or two to rebuild the
mirror without losing the old data.

Andrew Sullivan wrote:

>On Thu, Sep 18, 2003 at 06:49:56PM -0300, Marc G. Fournier wrote:
>
>
>>Hadn't thought of it that way ... but, what would prompt someone to
>>upgrade, then use something like erserver to roll back?  All I can think
>>of is that the upgrade caused alot of problems with the application
>>itself, but in a case like that, would you have the time to be able to
>>'re-replicate' back to the old version?
>>
>>
>
>The trick is to have your former master set up as slave before you
>turn your application back on.
>
>The lack of a rollback strategy in PostgreSQL upgrades is a major
>barrier for corporate use.  One can only do so much testing, and it's
>always possible you've missed something.  You need to be able to go
>back to some known-working state.
>
>A
>
>
>

--
Guy Fraser
Network Administrator
The Internet Centre
780-450-6787 , 1-888-450-6787

There is a fine line between genius and lunacy, fear not, walk the
line with pride. Not all things will end up as you wanted, but you
will certainly discover things the meek and timid will miss out on.





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

Предыдущее
От: "pw"
Дата:
Сообщение: pg_tables column descriptions
Следующее
От: Jean-Francois.Doyon@CCRS.NRCan.gc.ca
Дата:
Сообщение: Problem with ORDER BY and random() ?