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 по дате отправления: