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> > >
