Large caches ...

[Jason Coene]

> >MySQL Cluster is a clustered, redundant, entirely in-memory database.
> >You can take down or lose a machine and the cluster stays running with
> >no data loss.  It sounds like MySQL Cluster would suite your needs a
> >lot better than memcached.
> >
> >
> 
> 
> Building an in memory database is not that hard - in fact it is easy. I
> wouldn't call that a real, sophisticated cluster.
> What really makes things complex is keeping "real" databases in sync (=
> things must be on disk PERSISTENTLY).
> 
>     hans

Memcached is a storage engine with no built-in redundancy capabilities -
most regard it as a very fast, yet very brain-dead method of storage.  It's
up to you to populate it, and if you need redundancy, it's up to you to
provide those capabilities in software.

Memcached won't sync data for you - your software has to populate the cache.
Many of us know how difficult this can be, ranging from very easy to
incredibly hair-pullingly complex, depending on the data and how it's used
and updated.  Again, this isn't something memcached can magically do, your
software will need to manage the cache.

A simple method of adding redundancy may be to take the RAID-1 mirror
approach.  Have 2 sets of memcached servers.  On each SET/INCR/DECR/etc
command that will modify data, make it happen at 1 server in each set of
servers.  On each GET, read from one of the two randomly (or sequentially).
Should the read fail, use the other.  Of course, it provides no guaranteed
data integrity, but a creative mind may be come up with something to
mitigate or completely overcome that, depending on your scenario.

If you want to avoid this, a MySQL disk-data solution + MySQL cluster in
memory sounds like a fairly solid and very simple solution.

Good luck,

Jason