cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alain RODRIGUEZ <arodr...@gmail.com>
Subject Re: Upgrading to SSD
Date Mon, 25 Apr 2016 09:15:50 GMT
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 - alain@thelastpickle.com
France

The Last Pickle - Apache Cassandra Consulting
http://www.thelastpickle.com

2016-04-23 21:47 GMT+02:00 Jonathan Haddad <jon@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 <
> clintlmartin@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_2003@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>
>>
>>

Mime
View raw message