Hello, Maybe you should call « nodetool drain » just before stoping the node. As it flush the memtables, the commitlog will be empty and so easier to move.
https://docs.datastax.com/en/cassandra/2.0/cassandra/tools/toolsDrain.html -- Jérôme Mainaud jer...@mainaud.com 2016-04-26 8:44 GMT+02:00 Anuj Wadehra <anujw_2...@yahoo.co.in>: > Thanks All !! > > Anuj > -------------------------------------------- > On Mon, 25/4/16, Alain RODRIGUEZ <arodr...@gmail.com> wrote: > > Subject: Re: Upgrading to SSD > To: user@cassandra.apache.org > Date: Monday, 25 April, 2016, 2:45 PM > > Hi > Anuj, You could do the following instead > to minimize server downtime: > 1. rsync while the server is > running2. rsync again > to get any new files3. > shut server down4. > rsync for the 3rd time 5. change directory in yaml and > start back up > +1 > Here > are some more details about that process and a script doing > most of the job: > thelastpickle.com/blog/2016/02/25/removing-a-disk-mapping-from-cassandra.html > Hope it will be useful to > you > C*heers,-----------------------Alain > Rodriguez - alain@thelastpickle.comFrance > The Last Pickle - Apache Cassandra > Consultinghttp://www.thelastpickle.com > 2016-04-23 21:47 GMT+02:00 > Jonathan Haddad <j...@jonhaddad.com>: > You could do the > following instead to minimize server downtime: > 1. rsync while the server is > running2. rsync again to get any new > files3. shut server down4. rsync for > the 3rd time5. change directory in yaml and start > back up > > > On Sat, Apr 23, 2016 at 12:23 PM Clint Martin > <clintlmar...@coolfiretechnologies.com> > wrote: > As long as you shut down the node before you start > copying and moving stuff around it shouldn't matter if > you take backups or snapshots or whatever. > When you add the filesystem for the ssd will > you be removing the existing filesystem? Or will you be able > to keep both filesystems mounted at the same time for the > migration? If you can keep them both at the same time then > an of system backup isn't strictly necessary. Just > change your data dir config in your yaml. Copy the data and > commit from the old dir to the new ssd and restart the node. > > If you can't keep both filesystems mounted > concurrently then a remote system is necessary to copy the > data to. But the steps and procedure are the same. > Running repair before you do the migration > isn't strictly necessary. Not a bad idea if you > don't mind spending the time. Definitely run repair > after you restart the node, especially if you take longer > than the hint interval to perform the work. > As for your filesystems, there is really > nothing special to worry about. Depending on which > filesystem you use there are recommendations for tuning and > configuration that you should probably follow. > (Datastax's recommendations as well as AL tobey's > tuning guide are great resources. > https://tobert.github.io/pages/als-cassandra-21-tuning-guide.html > ) > > > Clint > On Apr 23, 2016 3:05 > PM, "Anuj Wadehra" <anujw_2...@yahoo.co.in> > wrote: > Hi > We have a 3 node cluster of 2.0.14. > We use Read/Write Qorum and RF is 3. We want to move data > and commitlog directory from a SATA HDD to SSD. We have > planned to do a rolling upgrade. > We plan to run repair -pr on all > nodes to sync data upfront and then execute following > steps on each server one by one: > 1. Take backup of data/commitlog > directory to external server.2. Change mount > points so that Cassandra data/commitlog directory now points > to SSD.3. Copy files from external backup to > SSD.4. Start Cassandra.5. Run full > repair on the node before starting step 1 on next > node. > Questions:1. Is copying > commitlog and data directory good enough or we should go for > taking snapshot of each node and restoring data from that > snapshot? > 2. Any > precautions we need to take while moving data to new SSD? > File system format of two disks etc. > 3. Should we drain data before > taking backup? We are also restoring commitlog directory > from backup. > 4. I have > added repair to sync full data upfront and a repair after > restoring data on each node. Sounds safe and > logical? > 5. Any > problems you see with mentioned approach? Any better > approach? > ThanksAnuj > > Sent > from Yahoo Mail on > Android > > >
