Re: need for in-place upgrades

scrappy(at)postgresql(dot)org ("Marc G. Fournier") writes:
> On Thu, 18 Sep 2003, Andrew Sullivan wrote:
>
>> On Sat, Sep 13, 2003 at 10:27:59PM -0300, Marc G. Fournier wrote:
>> >
>> > I thought we were talking about upgrades here?
>>
>> You do upgrades without being able to roll back?
>
> 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?

Suppose we have two dbs:

db_a - Old version
db_b - New version

Start by replicating db_a to db_b.

The approach would presumably be that at the time of the upgrade, you
shut off the applications hitting db_a (injecting changes into the
source), and let the final set of changes flow thru to db_b.

That brings db_a and db_b to having the same set of data.

Then reverse the flow, so that db_b becomes master, flowing changes to
db_a. Restart the applications, configuring them to hit db_b.

db_a should then be just a little bit behind db_b, and be a "recovery
plan" in case the new version played out badly.

That's surely not what you'd _expect_; the point of the exercise was
for the upgrade to be an improvement. But if something Truly Evil
happened, you might have to. And when people are talking about "risk
management," and ask what you do if Evil Occurs, this is the way the
answer works.

It ought to be pretty cheap, performance-wise, to do things this way,
certainly not _more_ expensive than the replication was to keep db_b
up to date.
--
(reverse (concatenate 'string "gro.mca" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/oses.html
Rules of the Evil Overlord #149. "Ropes supporting various fixtures
will not be tied next to open windows or staircases, and chandeliers
will be hung way at the top of the ceiling."
<http://www.eviloverlord.com/>