On Mon, 27 Jun 2016, Geoff Galitz wrote: > Hi... > We're working on a project to migrate from one set of memcache servers to > newer largers ones which are behind a mcrouter. > > One option on the table is to take the current memcache_servers array in our > perl app and replace a single instance with the larger new memcache > server/cluster. Once the new > larger server(s) is warmed up we'd start popping servers off the end of the > array to shrink it. Would this a problem? My concern is that the index > would become invalid and > we'd invalidate the entire memcache pool. > > As an example: > > Starting config: > memcache_servers => ['memcache01', 'memcache02', 'memcache03', 'memcache04'] > > Next: > memcache_servers => ['new-memcache01','memcache02', 'memcache03', > 'memcache04'] > > Next: > memcache_servers => ['new-memcache01','memcache02', 'memcache03'] > > and so on. > > Any thoughts?
If you're using consistent hashing, the churn will be relative to the percentage of change, instead of invaliding everything. The other way folks tend to do this (and I don't know if mcrouter has this feature) is to overlay two clusters. IE: You have your new-memcache array, and then the original array as separate client instances. First fetch against new-memcache, if miss fetch from old memcache. When writing new entries, write to the new one (and optionally update or delete against the old one). You end up with a big initial "hit" with a roundtrip, but much less impactful than going to your backing store. but that's complicated. if you can take a temporary 30% hit each time you rotate in a new server you should stick with that. Run it during offpeak or something. -- --- 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
