Take Mozilla, for example. More than 50% of the time, my queries time out because the site is so popular, even though Mozilla has the shadow database feature enabled. My suggestion is that Bugzilla allows the administrator to specify how many shadow databases to specify, and would then query the least-busy database. I bet that Mozilla would rather use more hard drive space but make the database available to people 100% of the time. Please consider this -- it will make the Bugzilla solution much more reliable and scalable.
Urk. The correct solution here is to use MySQL (or other DB) replication, rather than attempt to reimplement it ourselves. Gerv
How would this speed anything up? I can only imagine it slowing things down. I don't see how there could be contention for the shadow database, the point is you can have any number of readers at once. I suppose if they were on different hard drives it could possibly be better, but even that's dubious.
gerv: You've misunderstood this rfe. This isn't a request to create such dbs. Its a request to, given a list of n databases which magically somehow exist, rotate between them. This would require my replication patch which, among other things, connects to another database for the shadow db, instead of just using USE statements.
It's true that I don't know the true reason for Bugzilla's slowness on Mozilla project... is it because the database is busy responding to other requests and I am enqueued for a long time? Or is it because the machine cannot handle it, hardware-wise? If it's because the database is busy, I thought it'd be logical to duplicate the data among multiple databases and as Bradley said, rotate between them to alleviate load. Maybe even (and this is not easy, of course, but would be excellent for some projects) allow the administrator to specify the IP/port of several databases, so that those databases could be on different physical machines. Of course, this may be useless if the bottleneck lies in the hardware or network connection instead of the database.
We already duplicate the data because of lock contention, duplicating it again wouldn't make sense to reduce lock contention because there isn't any contention in the shadow database. This would only provide benefit for when you can place them across extra disk drives.
Resolving to INVALID now that shadow databases are depreciated and support for them is slated to be removed in the next versions.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
There will still be a shadow database feature, its just that it will use a better implementation.
You need to log in before you can comment on or make changes to this bug.