Issue #7584 has been updated by Daniel Pittman.
Garrett Honeycutt wrote: > I didn't specifically for Dashboard, but this is a general approach to > scaling SQL. We really should measure before we cut, here: if our problem is write load, rather than read load, this will not resolve the problem, but only make it worse. It isn't clear to me that any of the performance issues we are seeing have to do with read load, and while I would *love* to see those numbers, without them I am pretty reluctant to make this in any way a priority. (For the audience reading later, the reason that it only helps when reads are a bottleneck is that your read-only replica database servers still need to make one write for every write made on the master: if they didn't, they would not be a replica, just a partial copy, and the problem there is likely obvious. ;) ---------------------------------------- Feature #7584: ability to designate different read and write hosts for mysql in the Dashboard https://projects.puppetlabs.com/issues/7584 Author: Garrett Honeycutt Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: mysql scalability Branch: Dashboard's mysql configs let you specify a host, but they do not break it up into a write host and a read host. For further scalability it would be beneficial to have different read and write handlers for the SQL connections. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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/puppet-bugs?hl=en.
