Colin Guthrie wrote: > > Chris Mulligan wrote: >> I agree with Noah. What's the problem this is really solving in the >> real world? Why did you ever need a separate read database? > > Not related to this general principle but i recently had to scale up a > project I was running (totally unrelated to Trac) and if it had been > coded with a separate read database it would have made my life a lot > easier.... Using MySQL slaves for read operations and only hitting the > master for writes would have made scaling up a lot easier. > > So this patch does definitely solve a real life problem with regards to > load. Sure, most trac project wont get that busy (and with trac the > bottleneck is usually at the python end rather than the SQL end), but > the principle is not a bad one.
Yeah, but I think this is a fairly uncommon use case. It only covers the case where a specific trac env is too busy for a single database server to keep up. And even with this patch I'm a bit skeptical that Trac will work very well with the asynchronous type of replication offered by MySQL. So I'm "-1" since it's not work totally breaking all existing code (including most plugins) because of this. / Jonas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
