MySQL Proxy: replicating into memcache
May 18th, 2008
If you use replication with MySQL and memcache at the same time you have the problem to make sure that the memcached and the slave are in sync. If you announce the memcached to mark a entry as dirty and let it update the value from the slave BEFORE it is updated, you fetch a old value.
The easiest way to ensure that memcache is always notified after the slave is updated, you can use ... well ... replication. MySQL 5.1 brings Row Based Replication that makes this kind of applications a lot easier.
I'm not there to present you a Proof of Concept, I'm only close enough to explain the idea:
- Slave fetches records from Master
- Slave applies the records
- Slave exposes its changes as replication stream to the MySQL Proxy
- MySQL Proxy decodes the RBR records, extracts the Primary Key and updates the content in the memcache server
The MySQL Proxy acts as replication client in this case and exposes the records into LUA land to handle it.
Most of the work will be in decoding the replication stream as the RBR puts some work on the reading side to keep track of the changes.
I'll tell you again when I get there.
3 Responses to “MySQL Proxy: replicating into memcache”
Sorry, comments are closed for this article.
May 19th, 2008 at 12:00 AM Or, add a trigger to the table on the slave. Make the trigger call the memcached UDFs.
May 24th, 2008 at 08:42 AM Baron, you're wrong. Read Jan's post again.
May 24th, 2008 at 03:44 PM Does this mean you are working on the library to decode the RBR events? I have been asking various people for this, and now I get to ask you. When will it be ready? We have changed MySQL 5.1 to optionally maintain a log table on the server that has 1 entry per modified row. The entry is a SQL statement -- update, insert or delete, is easy to parse, and can be used to maintain alternate data stores such as memcached.