We get the new AMI release with the new OS updates and we are not allowed to use the old AMI .
On Sat, May 27, 2017 at 7:11 PM Jeff Jirsa <jji...@apache.org> wrote: > > > > > On 2017-05-27 18:04 (-0700), Surbhi Gupta <surbhi.gupt...@gmail.com> > wrote: > > > Thanks a lot for all of your reply. > > > Our requirement is : > > > Our company releases AMI almost every month where they have some or the > > > other security packages. > > > So as per our security team we need to move our cassandra cluster to the > > > new AMI . > > > As this process happens every month, we would like to automate the > process . > > > Few points to consider here: > > > > > > 1. We are using ephemeral drives to store cassandra data > > > 2. We are on dse 4.8.x > > > > > > So currently to do the process, we pinup a new nodes with new DC name and > > > join that DC, alter the keyspace, do rebuild and later alter the > keyspace > > > again to remove the old DC . > > > > > > But all of this process is manually done as of now. > > > > > > So i wanted to understand , on AWS, how do you do above kind of task > > > automatically ? > > > > > > 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). > > > > 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. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: user-h...@cassandra.apache.org > > > >
