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
