The Future of Performance: Scaling

[Colin Ogilvie]

Frédéric Buclin wrote:
> IMO, that's because query.cgi uses the master DB to populate the 
> search form, and buglist.cgi prepares everything using the master DB, 
> and only shifts to the shadow DB at the very end when it's time to run 
> the huge query. I think both should shift to the shadow DB, the only 
> exceptions being when they write to the DB (when updating the default 
> query or deleting/updating a saved search).
>
> I also suspect more and more third-party tools call config.cgi to know 
> the config of Bugzilla, but this script uses the master DB too, 
> despite it's pure read-only. So we could shift to the shadow DB 
> without problem.
>
> describecomponents.cgi and describekeywords.cgi are also good 
> candidates to use the shadow DB. It doesn't matter if the number of 
> bugs reported by keyword is off by a few minutes, really.
>
> Maybe more controversial is show_activity.cgi, which *could* 
> eventually use the shadow DB too. Note that BugMail.pm doesn't call 
> show_activity.cgi to generate bugmail, so this wouldn't break anything.
>
> Other scripts look fine to me. I will file a bug to do these suggested 
> shifts so that we have a more centralized way to track what should be 
> changed or not.

With more and more stuff shifting to the Shadow DB, is replication lag 
going to prove an issue? Are people going to get annoyed if there is 
some replication lag and what they are looking for isn't found?

Is it worth possibly optionally adding a replication lag check in to the 
bit that switches us to the Shadow DB if the user has the right privs 
(which I can't remember off hand) to do a 'SHOW SLAVE STATUS'? (Yeah, I 
know this may be mysql specific, but it's the only DB I actually know :) )

Colin