The problem with a replicated cache is figuring out what to do if one fails. Memcached effectively solves this problem by not doing replication. I strongly agree with this approach unless you have a VERY good reason not to, and in that case, memcached is probably not a very good choice.
<br><br>What I recommend is using multiple memcached caches, even if all your cached data can fit in one instance, spread it over several. That way if you need to stop one instance for any reason, you dont lose your whole cache, you only lose part of it, which can be recreated from the database.
<br><br>One of my smaller projects has a finite set of data that is only about 20mb in size, it will change frequently, but not get any larger or smaller. I actually use two memcached instances on different machines (each with 20mb allocated), and the keys are distributed over both (by the client).
<br><br>This has worked quite adequately for me for small and large projects. <br><br>Replication sounds like a simple thing, but in implementing it, there are a LOT of things that become issues.<br><br><div><span class="gmail_quote">
On 10/24/07, <b class="gmail_sendername">Marcus Bointon</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 23 Oct 2007, at 20:17, Brian Beuning wrote:<br><br>> One instance of memcached could handle our tiny 400 MB with no<br>> problem.<br>> It can probably even handle the load of 100 processes hitting it.<br>> But I am
<br>> concerned if memcached went down then we would miss our fixed time<br>> window.<br>><br>> Ideally we would like to have a few memcached instances each with a<br>> full<br>> copy of the 400 MB. The Wiki says memcached does not do replication.
<br><br>Seems like the memcachedb project mentioned on here recently might be<br>a good fit for you. It's essentially a memcache front-end with a bdb<br>back end, so can survive restarts etc, while still serving some scary
<br>performance numbers.<br><br>Marcus<br>--<br>Marcus Bointon<br>Synchromedia Limited: Creators of <a href="http://www.smartmessages.net/">http://www.smartmessages.net/</a><br>UK resellers of info@hand CRM solutions<br><a href="mailto:firstname.lastname@example.org">
email@example.com</a> | <a href="http://www.synchromedia.co.uk/">http://www.synchromedia.co.uk/</a><br><br><br></blockquote></div><br><br clear="all"><br>-- <br>"Be excellent to each other"