Merge lp:~stub/launchpad/pending-db-changes into lp:launchpad/db-devel
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Stuart Bishop on 2010-11-24 | ||||
| Approved revision: | no longer in the source branch. | ||||
| Merged at revision: | 9997 | ||||
| Proposed branch: | lp:~stub/launchpad/pending-db-changes | ||||
| Merge into: | lp:launchpad/db-devel | ||||
| Diff against target: |
84 lines (+56/-0) 2 files modified
database/schema/patch-2208-01-1.sql (+10/-0) database/schema/upgrade.py (+46/-0) |
||||
| To merge this branch: | bzr merge lp:~stub/launchpad/pending-db-changes | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Jelmer Vernooij (community) | 2010-11-24 | Approve on 2010-11-24 | |
|
Review via email:
|
|||
Commit Message
[r=jelmer]
Description of the Change
Store and report database patch application times.
The reported times are the time spent running the actual SQL. There are also overheads involved, but this should be constant. Given a total of these times for a rollout, the actual time will be "num_nodes * db_time + x * num_patches + y", where x and y are as yet unknown constants representing overhead per patch and extra overhead (trusted.sql, comments.sql, merging new table replication set into main replication set etc.)
| Robert Collins (lifeless) wrote : | # |
| Stuart Bishop (stub) wrote : | # |
On Thu, Nov 25, 2010 at 2:26 AM, Robert Collins
<email address hidden> wrote:
> When we have 2 slaves, do they apply patches in parallel with each
> other, or serially?
Hmm... yeah. That formula is bogus. I think this is what happens: we
apply all the patches in a transaction on the master, so if it fails
on the master things roll back. Then slony sends off DDL as events
which propagate to the slaves and they run the DDL. Because our slaves
all connect directly to the master at the moment, they end up running
the DDL in parallel. So time would be 2 * db_time + x * num_slaves *
num_patches + y. In reality, we can get away with 2 * db_time + 5
minutes.
--
Stuart Bishop <email address hidden>
http://
| Robert Collins (lifeless) wrote : | # |
On Thu, Nov 25, 2010 at 3:17 PM, Stuart Bishop
<email address hidden> wrote:
> the DDL in parallel. So time would be 2 * db_time + x * num_slaves *
> num_patches + y. In reality, we can get away with 2 * db_time + 5
> minutes.
Excellent - thanks. Could you perhaps put that in the release manager
notes on the wiki? We need to write up how to get these things and
have a place to record the total time for devs doing qa on db-devel
too, but thats a slightly separate problem :)
-Rob

When we have 2 slaves, do they apply patches in parallel with each
other, or serially?