1

we want migrate our data from regular drives on production server to new SSD drives. how we can do that without taking down the node no longer than 4 hours(hinted hand-off is 4 hours) our data is in few hundreds of GigaBytes.

what i was thinking is stoping cassandra on one node at a time flushing data to disks and then transfering data from old drives to new drives and de-mounting old disk and bringing back node online. Is this a right approach ?? If so what is my major concern is,the data migration to new disk takes more than 4 hours in the mean while i will lose hints.

Is there any better approach for migration of data to new disks??

user6288321
  • 25
  • 7

2 Answers2

2

While Cassandra is running, rsync from HD to SSD. Make sure you use the -H and --delete flags to address hardlinks and deleted sstables/commitlogs. Don't forget commitlogs if they're on the same device. Once you get to a point where you've transferred the bulk of the data and subsequent rsyncs complete relatively quickly, you can drain & stop that cassandra instance, do a final rsync, and change the data_dir path. This shortens node downtime to minutes, roughly the time it takes for the final rsync, assuming the chassis can fit both the HD and SSD at the same time.

Dave
  • 123
  • 1
  • 1
  • 5
  • you don't need to copy the commitlogs if you're going to drain and stop the node, as that will cause all commitlogs to be written anyway – LHWizard May 27 '16 at 15:13
  • This is the method used when upgrading between the old and new generation of SSD arrays. I would suggest to automate every step to make sure to avoid any human error. – Baptiste Mille-Mathias Aug 07 '16 at 08:02
0

or if your got replication > 1, simulate a dead node and then bootstrap it with new SSD layout and get it rejoining the cluster.

Steffen Winther Sørensen
  • 176
  • 6