slave database should never be used when lag is too great
Bug #307407 reported by
Stuart Bishop
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Stuart Bishop |
Bug Description
When replication lag gets large, people start noticing the oddities, such as the branchscanner appearing to be taking forever or the bug they just reported using the email interface not existing in the web UI.
Launchpad can already detect how lagged the slave database is. If the lag is > X seconds, then the slave database should never be used even for Anonymous connections or connections that have not made changes recently.
This should also automatically lessen the load on the slave, freeing up resources so replication catches up sooner.
Related branches
lp:~stub/launchpad/replication
Merged
into
lp:launchpad
- Abel Deuring (community): Approve (code)
- Aaron Bentley (community): Approve
-
Diff: 196 lines (+106/-19)7 files modifieddaemons/cache-database-replication-lag.py (+53/-0)
database/replication/helpers.py (+1/-0)
database/schema/comments.sql (+4/-0)
database/schema/patch-2207-28-1.sql (+9/-0)
database/schema/security.cfg (+6/-0)
database/schema/trusted.sql (+22/-0)
lib/canonical/launchpad/webapp/dbpolicy.py (+11/-19)
Changed in launchpad-foundations: | |
assignee: | nobody → stub |
importance: | Undecided → High |
status: | New → Triaged |
Changed in launchpad-foundations: | |
milestone: | none → 2.2.1 |
Changed in launchpad-foundations: | |
status: | Triaged → Fix Released |
To post a comment you must log in.
Can we fix this before the release?