Replication

[Jeetendra Mirchandani]

Brian,

I have tried out something similar to what you have been thinking -
and it worked just fine!

http://lists.danga.com/pipermail/memcached/2006-October/002856.html

Not everybody will accept this scene where your cache is a little more
than a cache, and you want some reliability out of it, while giving it
more hardware/memory.

Had a few changes in the what were described there, can discuss if you want.

Hope this helps!

Regards,
Jeetu


On 10/24/07, Dustin Sallings <dustin at spy.net> wrote:
>
>
> On Oct 24, 2007, at 9:18 , Brian Beuning wrote:
>
> Memcached as it is today provides a certain good level of reliability
> (with blazing performance).  Some situations are going to require more
> reliability, and one way to get that is replication.  If there is another
> way
> to get more reliability I am very interested in hearing about it.
>
>  From Wikipedia:
>
>  In computer science, a cache is a collection of data duplicating original
> values stored elsewhere or computed earlier, where the original data is
> expensive to fetch (due to longer access time) or to compute, compared to
> the cost of reading the cache.
>
>  It's specifically not *supposed* to be reliable, it's just supposed to be
> faster than using whatever originally held your data.  It's designed to
> throw stuff away when it notices you don't care about it at times.
>
>  It sounds like what you're looking for is a resilient dht.  Maybe chord
> would be more appropriate for your application.
>
>
> MySQL without ACID transactions supports a certain level of reliability.
> Some situations using MySQL need more reliability so MySQL added
> the ACID backend.
>  Databases *are* supposed to be reliable.  MySQL has had and continues to
> have data reliability problems, many by design, throughout its entire
> existence.  Innobase Oy (not MySQL AB) created a backend that allows you to
> have some tables participate in transactions for common (but not all)
> operations.
>
>  Obviously many people feel that MySQL is good enough for their data, but
> your whole concept is backwards here:
>
>  1) You should be able to assume that everything you've committed to your DB
> will reliably come out the same way no matter what.
>  2) You should assume that whatever you put into your cache may never make
> it back out alive and you'll have to reconstruct it from whatever the origin
> is.
>
>
> --
> Dustin Sallings
>
>


-- 
Regards,
Jeetu
http://www.cse.iitb.ac.in/~jeetu
http://apps.facebook.com/myorkut/

"Reality is merely an illusion, albeit a very persistent one."