Then I think you're not looking for memcached. Look into some other distributed key-value datastores. There is a lot of really interesting work being done in this area right now.
This might be a good starting point: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/ On Fri, Feb 27, 2009 at 12:08 AM, theRat <[email protected]> wrote: > > I'm still curious about this though. I'm considering an application > that doesn't even USE a database - we'd keep data in it that we > wouldn't WANT to lose - but it wouldn't be a disaster if we did. > Without a database to backup if memcached failed, each memcached node > becomes a single point of failure. I'm looking to see if I can do > something a little more robust... I don't know if this is possible to > do at the config level - or if it is something that different > implementations of the client can handle - or if it has to be done by > my application... > > Your thoughts? > > -john > > On Feb 26, 3:38 pm, Joseph Engo <[email protected]> wrote: >> You wouldn't want this type of setup. Memcached is a simple cache, if >> your request results in a miss you should hit your datastore. Don't >> treat it like a database. Always have a fall back plan for something >> not being present in cache. >> >> Add all the memcached nodes to your connection pool and allow the >> library to distribute your keys. >> >> On Feb 26, 2009, at 3:35 PM, theRat wrote: >> >> >> >> > All, >> >> > sorry for the newbie question - I haven't found my answer anywhere >> > else... >> >> > When I write a value to a particular memcached server node A, can I >> > also have it write to a second (or third) node B - as a backup in case >> > node A goes down? It's unclear to me whether this is possible. If it >> > IS possible, is this set up through a configuration of the server? >> > the client? Is it done "invisibly" or does my application have to >> > write to multiple nodes? >> >> > Many thanks! >> >> > -john > -- awl
