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.
