launchpad-dev team mailing list archive

[Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx>]

On Fri, Dec 3, 2010 at 12:47 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/02/2010 12:41 PM, Robert Collins wrote:
>> I think thats applying and reverting the recife change.
>
> I'm not sure what you're referring to.  But I don't think those database
> times include the recife revert-- that only landed this morning (i.e.
> post 14:00 UTC).


This is what I'm getting from staging:



Full restore
2010-11-28 07:58:29 INFO    Applying patches to Slony-I environment.
SELECT assert_patch_applied(2208, 28, 0);]
SELECT assert_patch_applied(2208, 28, 1);]    # 2k seconds
SELECT assert_patch_applied(2208, 29, 0);]
SELECT assert_patch_applied(2208, 31, 0);]
Running fti.py Sun Nov 28 09:07:01 UTC 2010       # 4112 seconds

Partial restore
Mon Nov 29 11:03:06 UTC 2010 Applying database updates and permissions to DB
SELECT assert_patch_applied(2208, 27, 0);]    # 25 seconds
SELECT assert_patch_applied(2208, 30, 0);]    # 50 seconds
Mon Nov 29 11:09:58 UTC 2010 DB upgrades applied   # 412 seconds

Partial restore
Wed Dec 1 13:06:47 UTC 2010 Applying database updates and permissions to DB
SELECT assert_patch_applied(2208, 32, 0);]
Wed Dec 1 13:13:58 UTC 2010 DB upgrades applied

The partial on 30th didn't contain any db patches. The partial on Dec
2 failed, but only a CREATE TABLE and a few empty indexes.

So in total, on staging, about 5000 seconds or 1.4 hours.

patch-2208-28-1 is the slow one, but this was designed to be applied
live so I'll do that now. This will reduce things to 3000 seconds.

Previous rule of thumb is to just double this number for the
production rollout time, which is within budget. We should compare the
actual rollout time to see if the newer formulas are correct.


-- 
Stuart Bishop <stuart@xxxxxxxxxxxxxxxx>
http://www.stuartbishop.net/