if you want shared keys, use a shared server... one memcache for app1, one memcache for app2, and one memcache for shared cache
if you want replication (aka cluster) you should use a replicated memcache fork (repcache for example or many many others) 2012/10/9 Les Mikesell <[email protected]> > On Tue, Oct 9, 2012 at 8:59 AM, Kiran Kumar <[email protected]> wrote: > > Thanks , let me explain my architecture more clearly > > > > you misunderstand how memcached works. It doesn't front-end the > > database servers like you think it does. It works like this: > > > > Memcache1 Memcache2 > > \ / > > \ / > > \ / > > \ / > > \ / > > \ / > > MySQL Master > > MySQL Slave > > > > There is NO replication between Memcache1 and Memcache2 because they > > do not cache the same data. Memcache1 caches 50% of the data and > > Memcache2 caches the other 50% of the data. There is no data overlap > > so no synchronization is necessary. > > > > If either memcached server fails, the application requesting the data > > should "fall through" and hit the database server(s) directly. > > > > Do you understand now? > > That description is correct, but it doesn't explain why your 2 > applications wouldn't work the way you want in this configuration or > why you would want separate independent servers for each application. > Being able to distribute the cache over multiple servers is the main > reason people would use memcache. > > -- > Les Mikesell > [email protected] > -- Roberto Spadim Spadim Technology / SPAEmpresarial
