You'd be surprised how many places uses this as an actual solution. All arguments aside about what level of the architecture should be doing what, it simply works well. Moreover, it works today as opposed to waiting until the end of time for the database developers to add features like that (which mysql cluster is already a distributed database, and the devs have said they're not interested in trying to turn the regular mysql into a distributed product, instead they want to focus on what it does best)
I would love to see a drop-in solution that requires no application changes, and doesn't introduce any additional complications such as adding excessive overhead, or have yet another single point of failure, but none (or at least no good ones) exist. This is because optimization is a very specific process. Applications like PHPBB, Drupal and WordPress should have their database access encapsulated well enough that making the changes to split reads and writes is trivial. If not, then it's bad design on their part. Scalability is very much a part of application design as well, and just because lots of people use those apps, doesn't mean they were designed to scale well. Regards, Gavin Towey -----Original Message----- From: Tim Gustafson [mailto:t...@soe.ucsc.edu] Sent: Friday, September 25, 2009 2:44 PM To: mysql@lists.mysql.com Subject: Re: Master/Slave Replication Question > Another thought would be at the application layer, sending > all the updates (insert,delete, update, etc) to server A, > and the selects to the local slave servers. This has been suggested before, and I'm totally against it. Applications like PHPBB, Drupal, WordPress, etc can't be easily configured to do this, and I'd really like to use those applications in a more robust and redundant environment. Pushing the work of this sort of master/slave relationship to the application level means that most applications will not support it. Replication is a database server problem, not an application problem. Tim Gustafson Baskin School of Engineering UC Santa Cruz t...@soe.ucsc.edu 831-459-5354 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=gto...@ffn.com The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
