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
