Description:
If I remember correctly LDAP will automatically forward a query which causes a change to the directory from a slave to it's master. This seems to me like a good way to achieve transparent scaling-out for web applications that aren't coded for separate read / write servers.
This could be especially helpful for lazy programmers, like myself, that would rather not modify an application, where even possible, to allow for separate read / write servers.
This could also be a good alternative to scaling-up, which can be very costly after a point. Instead replication slaves are put in place to act as passive servers, and pass any writing request on up to the master server.
How to repeat:
Just a feature request
Suggested fix:
This could be implemented either at the client library and/or replication server level.
At the client level, the replication slave would return a reference to it's master when it received a query that would change or lock some part of the database. The client would then have to follow that reference, possible several references in a replication chain or circle, to find a master to take the writing query. If I remember right this is the way LDAP implements it.
On the other hand this could be implemented just at the replicate server level. When a replication slave got such a request it would itself forward that request to it's master.
Either way there would have to be a method to watch for the query being forwarded to a master that has already seen it. This could be a problem anytime there is something like a master - master cluster. Possibly include the replication id of each server that has seen the request as part of the packet. Then if a server got the packet and saw it's id in the chain, it would assume it safe to go ahead and run the query itself.
