Hi Anuj,
> You could do the following instead to minimize server downtime: > > 1. rsync while the server is running > 2. rsync again to get any new files > 3. shut server down > 4. 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 - al...@thelastpickle.com France The Last Pickle - Apache Cassandra Consulting http://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 running > 2. rsync again to get any new files > 3. shut server down > 4. rsync for the 3rd time > 5. 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? >> >> Thanks >> Anuj >> >> >> Sent from Yahoo Mail on Android >> <https://overview.mail.yahoo.com/mobile/?.src=Android> >> >>
