launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #07651
Re: Please read: new DB schema patch rules
-
To:
Robert Collins <robertc@xxxxxxxxxxxxxxxxx>
-
From:
Jeroen Vermeulen <jtv@xxxxxxxxxxxxx>
-
Date:
Fri, 15 Jul 2011 15:14:29 +0200
-
Cc:
Launchpad Community Development Team <launchpad-dev@xxxxxxxxxxxxxxxxxxx>
-
In-reply-to:
<CAJ3HoZ2cp9RuHY9==NT_Yh_RdVF7a4Jrcn+9JahEBco4r8fxmA@mail.gmail.com>
-
User-agent:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
On 2011-07-15 00:27, Robert Collins wrote:
As prep for https://dev.launchpad.net/LEP/FastDowntime the db schema
I appreciate that between now and the deployment side of this going
live we're going to be doing a little more work around each schema
patch with no immediate payoff - but it means we'll be able to go
straight into the fastdowntime process once its ready.
Thank you so much for pushing this through!
There _is_ an immediate payoff: your db patch gets deployed much faster.
We've been aching for this kind of flexibility.
I ran some numbers a few years back when I proposed weekly rollouts of
devel plus "live" DB patches. For a medium-sized change, live patches
took more work but the worst-case time to useful deployment was about
the same as the best-case time for our current scheme. Typical cases
were massively better. And that was with a limitation of one phase per
week; we're getting something much faster.
We'll learn how to write incremental patches. Meeting the 15s goal on a
cold database will be hard though, since we can't easily reproduce
results or try out tweaks. It might help if we could break a slave out
of replication to time a DB patch against a realistic cache.
Jeroen
Follow ups
References