launchpad-dev team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...
> I would like to fix the postgresql one too; at the moment the way we
> work with it - due to its design around clustering and schema changes
> - is to change things once a month, which drives latency for feature
> work and performance work - we're *just now* landing a change we could
> have had out there for 3 weeks, if we didn't have a 4 week cycle.
> 
> Postgresql having defects in this area isn't a reason to bring in
> other like defects in new components :)
> 
> -Rob

Absolutely. But my point is that postgres fails on both accounts. If the
master dies you're screwed, but you also can't stop one machine to
upgrade while the other keeps churning.

It sounds like Rabbit suffers from the same problem. Though it also
sounds like a 3s downtime wouldn't be nearly the problem a 5-min
downtime would be. (and much less than a 90min downtime window.)

I didn't know Rabbit particularly well. And I agree you don't want to
add more bad.

However, if you have 2 Rabbits in active-passive. You stop the second
one to upgrade it, then you do a 5s downtime to switch, and upgrade the
first. (The old passive has become the new active). Is the issue that
you have a complete gap? Is it possible to haproxy this (some sort of
proxy that would queue up requests for the 5s necessary to switch over,
without killing them).

Is it that you aren't able to ever create a clean break? (You'll always
have random new requests that you can't shunt over to the new system,
because you can't shut down the old system because it is still serving
the last requests.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3vJTEACgkQJdeBCYSNAANc0gCfYjsavvgt6B3VBtB04mDzYKpj
SpwAoNnkPBlmFM6sKCgdHBlPj4ywjRzg
=GIcw
-----END PGP SIGNATURE-----