sorry for my poor expression, i may not describe my thought in english. just after the client restart, the data stored in memcached is outdate, and other client my access these outdate data. is there any way to drop the client data after the connection to memcaced server is stoped.( the client connect to server via tcp connection)
在 2014年9月3日星期三UTC+8下午3时40分02秒，Dormando写道： > > Why would another client get the wrong data if the original data was > successfully uploaded? > > I don't understand the use case, and it's not possible either way. > > On Wed, 3 Sep 2014, Xingui Shi wrote: > > > what i meant is the data is successfully uploaded, but the client > restart for some reason. the data stored in memcache server need to be > flushed. > > or other client my get the wrong data. > > > > 在 2014年9月3日星期三UTC+8下午3时04分59秒，Dormando写道： > > If a client is uploading something and it does not complete the > upload, > > the data will be dropped. > > > > Otherwise, no. > > > > On Wed, 3 Sep 2014, Xingui Shi wrote: > > > > > Hi, Is there any way to drop data add by a client when the > client aborted or exit normally? > > > > > > thanks. > > > > > > 在 2014年8月12日星期二UTC+8上午10时25分43秒，Dormando写道： > > > > > > > Hello there, > > > > There he has a method to be able to remove items from > the cache using a regular expression on the key. For example we want to > > remove > > > all the key as "my_key_ *?" > > > > We try to parse all the slabs with the command "stats > cachedump" but our slabs contain several pages and it is impossible to > > recover > > > all the elements! > > > > Thank you. > > > > > > > > > > Hi, > > > > > > The common way to do this, instantly, and atomically > across your entire > > > memcached cluster is via namespacing: > > > > http://code.google.com/p/memcached/wiki/NewProgrammingTricks#Namespacing > > > > > > You take a tradeoff: before I look up my key, I fetch a > side key which > > > contains the current prefix. Then I add that prefix to my > normal key and > > > do the lookup. When you want to invalidate all keys with > the same prefix, > > > you incr or otherwise update the prefix. The old keys will > fall out of the > > > LRU and your clients will no longer access them. > > > > > > This is *much* more efficient than any wrangling around > with scanning and > > > parsing keys. That only gets worse as you get a larger > cluster, while > > > namespacing stays at a consistent speed. > > > > > > Does this match what you're looking for, or did you have > some specific > > > requirements? If so, please give more detail for your > problem. > > > > > > -- > > > > > > --- > > > You received this message because you are subscribed to the > Google Groups "memcached" group. > > > To unsubscribe from this group and stop receiving emails from > it, send an email to [email protected]. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups "memcached" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
