On 05/27/2017 09:13 PM, Surbhi Gupta wrote: > We get the new AMI release with the new OS updates and we are not > allowed to use the old AMI .
Neither of Jeff's suggestions use the old AMI - that was my suggestion :) > On Sat, May 27, 2017 at 7:11 PM Jeff Jirsa <jji...@apache.org > <mailto:jji...@apache.org>> wrote: > > At a previous employer, they used M4 class instances with data on a > dedicated EBS volumes, so we could swap AMIs / stop / start / adjust > instances without having to deal with this. This worked reasonably > well for their scale (which was petabytes of data). This suggestion seems like a nice way to easily cycle out old AMIs to a new AMI quickly, getting rid of any data migration. A one-time pain to switch to EBS with many benfits, which lends itself to automation well. > Other companies using ephemeral tend to be more willing to just > terminate instances and replace them (-Dcassandra.replace_address). > If you stop cassandra, then boot a replacement with > 'replace_address' set, it'll take over for the stopped instance, > including re-streaming all data (as best it can, subject to > consistency level and repair status). This may be easier for you to > script than switching your fleet to EBS, but it's not without risk. This suggestion for ephemeral data disks also seems like a possibly more manageable way to cycle out old AMIs to a new AMI via individual node replacement. The rest of the cluster needs to be healthy, and it may mean an almost continuous node replacement, depending on node count. This is potentially a lot less overall cluster load, since one replacement node is streaming at a time, instead of all the data streaming to a new replacement DC. Easier to automate than a replacement DC, perhaps, too. -- Kind regards, Michael --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
