MySQL Camp: Using Memcached as a Configuration Database

I was talking to Dathan today at MySQL camp and he pointed out that one could use memcached as a cheap configuration database. Instead of just using it as a cache you would over-allocate the amount of memory needed so that entries would never be garbage collected.

For example, if you have 10M of configuration data just allocate 64M and this should give you plenty of head room.

Then you could have your clients poll at regular intervals and since memcached is fast you can have it push out changes at a fairly steady rate.

Of course you’d have to use multiple memcached servers each with a full snapshot of the configuration data. This way if one server crashes you don’t lose any data.

You could even have a reference install automatically update settings via crontab so that editing the files on one image will be pushed out to the entire cluster automatically.

  1. You don’t need to over-allocate if you start memcached with -M:

    -M return error on memory exhausted (rather than removing items)

    Though, wouldn’t DNS be better for this? It is fast, reliable, well-understood, ubiquitous, caching, replicated, etc. You can have many client processes on the same machine polling frequently yet the machine’s local cache (e.g. nscd) only makes a single request when the TTL expires. With djbdns, for example, replication of the database file is accomplished trivially with rsync.

%d bloggers like this: