ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
mysqlnd is looking for testers
Georg, Andrey and Ulf have been hard at work designing, implementing and testing a replacement for libmysql only for us PHP users. The idea is that mysqlnd can leverage all the internal PHP infrastructure for communication and memory management. It can also be much more PHP aware, removing old cruft we do not need while adding extra goodies just for us!
Circular master-master replication
One interesting solution to scalability and HA is to implement a circular master-master replication setup directly on the frontend servers. Obviously there is a reasonable limit as to how many servers you can have in such a ring, since the lag with which changes propagate will increase linearly as you add more servers to the ring. However according to an article by Giuseppe a 10 server ring is reasonable. Especially if you make your sessions sticky on a per frontend server basis, you actually have an elegant solution against the old issue of replication lag, where a user does not see changes he has made in subsequent requests, since his changes were written to a remote master server which have not propagated to the slave he is reading in the subsequent request. Latency should also improve as you do not have to open up a remote connection in the user request.
MySQL Query Cache invalidation changes
I just wanted to point everybody at a recent blog post by Konstantin. In the post he discusses a solution for dealing with cache invalidation issues of very large caches under heavy load. He points out that cache invalidation can severely bog down the system. The general solution he proposes is to simply deactivate the query cache entirely during invalidation. I think this is an important caveat to be aware of and actually he is asking for feedback if this "solution" is acceptable. I think its awesome that MySQL engineers are giving us the opportunity to provide feedback on such changes. Maybe there should be a dedicated "pipeline" where such requests could be found?
I got a little something from Apple
.. and it ain't no stinking iPhone! No its a MacBook Pro. Top of the line, well with the slower HD, since the faster one would have delayed delivery by well over a month. Hoping to go SSD sometime next year. I also got myself iWorks 06. Speaking of which, I am impressed how Apple can get away with "screwing" its customers twice. First they delay Leopard (and probably iWorks 07 as well) because of the stinking iPhone. So while people now have to wait longer to get the software promised earlier, they now also get to pay for something they would otherwise get bundled today. Anyways, not really complaining, just impressed that I have turned into a mac droid so easily, since I accepted all this with my purchase.
So whats the deal with gap locking?
So the other day I stumbled over the slides of the InnoDB talk at this years MySQL users conf and I noticed "gap locking" somewhere in the middle. I have never heard of "gap locking" so I was quite intrigued by what that might be. From what I understand its InnoDB's solution to implementing REPEATABLE READ (though until MySQL 5.1 it seems this feature is also enabled for READ COMMITTED). I guess its a fairly unique approach and from my current understanding to be feasible it expects short running transactions, which luckily are quite common in web applications that most of us care about.