Re: [EXTERNAL] Re: Nodetool refresh v/s sstableloader
Thank you, everyone, for responding. Rajath Subramanyam On Thu, Aug 30, 2018 at 8:38 AM Carl Mueller wrote: > - Range aware compaction strategy that subdivides data by the token range > could help for this: you only bakcup data for the primary node and not the > replica data > - yes, if you want to use nodetool refresh as some sort of recovery > solution, MAKE SURE YOU STORE THE TOKEN LIST with the > sstables/snapshots/backups for the nodes. > > On Wed, Aug 29, 2018 at 8:57 AM Durity, Sean R < > sean_r_dur...@homedepot.com> wrote: > >> Sstableloader, though, could require a lot more disk space – until >> compaction can reduce. For example, if your RF=3, you will essentially be >> loading 3 copies of the data. Then it will get replicated 3 more times as >> it is being loaded. Thus, you could need up to 9x disk space. >> >> >> >> >> >> Sean Durity >> >> *From:* kurt greaves >> *Sent:* Wednesday, August 29, 2018 7:26 AM >> *To:* User >> *Subject:* [EXTERNAL] Re: Nodetool refresh v/s sstableloader >> >> >> >> Removing dev... >> >> Nodetool refresh only picks up new SSTables that have been placed in the >> tables directory. It doesn't account for actual ownership of the data like >> SSTableloader does. Refresh will only work properly if the SSTables you are >> copying in are completely covered by that nodes tokens. It doesn't work if >> there's a change in topology, replication and token ownership will have to >> be more or less the same. >> >> >> >> SSTableloader will break up the SSTables and send the relevant bits to >> whichever node needs it, so no need for you to worry about tokens and >> copying data to the right places, it will do that for you. >> >> >> >> On 28 August 2018 at 11:27, Rajath Subramanyam >> wrote: >> >> Hi Cassandra users, Cassandra dev, >> >> >> >> When recovering using SSTables from a snapshot, I want to know what are >> the key differences between using: >> >> 1. Nodetool refresh and, >> >> 2. SSTableloader >> >> >> >> Does nodetool refresh have restrictions that need to be met? >> Does nodetool refresh work even if there is a change in the topology >> between the source cluster and the destination cluster? Does it work if the >> token ranges don't match between the source cluster and the destination >> cluster? Does it work when an old SSTable in the snapshot has a dropped >> column that is not part of the current schema? >> >> >> >> I appreciate any help in advance. >> >> >> >> Thanks, >> >> Rajath >> >> >> >> Rajath Subramanyam >> >> >> >> >> >> -- >> >> The information in this Internet Email is confidential and may be legally >> privileged. It is intended solely for the addressee. Access to this Email >> by anyone else is unauthorized. If you are not the intended recipient, any >> disclosure, copying, distribution or any action taken or omitted to be >> taken in reliance on it, is prohibited and may be unlawful. When addressed >> to our clients any opinions or advice contained in this Email are subject >> to the terms and conditions expressed in any applicable governing The Home >> Depot terms of business or client engagement letter. The Home Depot >> disclaims all responsibility and liability for the accuracy and content of >> this attachment and for any damages or losses arising from any >> inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other >> items of a destructive nature, which may be contained in this attachment >> and shall not be liable for direct, indirect, consequential or special >> damages in connection with this e-mail message or its attachment. >> >
Re: [EXTERNAL] Re: Nodetool refresh v/s sstableloader
- Range aware compaction strategy that subdivides data by the token range could help for this: you only bakcup data for the primary node and not the replica data - yes, if you want to use nodetool refresh as some sort of recovery solution, MAKE SURE YOU STORE THE TOKEN LIST with the sstables/snapshots/backups for the nodes. On Wed, Aug 29, 2018 at 8:57 AM Durity, Sean R wrote: > Sstableloader, though, could require a lot more disk space – until > compaction can reduce. For example, if your RF=3, you will essentially be > loading 3 copies of the data. Then it will get replicated 3 more times as > it is being loaded. Thus, you could need up to 9x disk space. > > > > > > Sean Durity > > *From:* kurt greaves > *Sent:* Wednesday, August 29, 2018 7:26 AM > *To:* User > *Subject:* [EXTERNAL] Re: Nodetool refresh v/s sstableloader > > > > Removing dev... > > Nodetool refresh only picks up new SSTables that have been placed in the > tables directory. It doesn't account for actual ownership of the data like > SSTableloader does. Refresh will only work properly if the SSTables you are > copying in are completely covered by that nodes tokens. It doesn't work if > there's a change in topology, replication and token ownership will have to > be more or less the same. > > > > SSTableloader will break up the SSTables and send the relevant bits to > whichever node needs it, so no need for you to worry about tokens and > copying data to the right places, it will do that for you. > > > > On 28 August 2018 at 11:27, Rajath Subramanyam wrote: > > Hi Cassandra users, Cassandra dev, > > > > When recovering using SSTables from a snapshot, I want to know what are > the key differences between using: > > 1. Nodetool refresh and, > > 2. SSTableloader > > > > Does nodetool refresh have restrictions that need to be met? > Does nodetool refresh work even if there is a change in the topology > between the source cluster and the destination cluster? Does it work if the > token ranges don't match between the source cluster and the destination > cluster? Does it work when an old SSTable in the snapshot has a dropped > column that is not part of the current schema? > > > > I appreciate any help in advance. > > > > Thanks, > > Rajath > > > > Rajath Subramanyam > > > > > > -- > > The information in this Internet Email is confidential and may be legally > privileged. It is intended solely for the addressee. Access to this Email > by anyone else is unauthorized. If you are not the intended recipient, any > disclosure, copying, distribution or any action taken or omitted to be > taken in reliance on it, is prohibited and may be unlawful. When addressed > to our clients any opinions or advice contained in this Email are subject > to the terms and conditions expressed in any applicable governing The Home > Depot terms of business or client engagement letter. The Home Depot > disclaims all responsibility and liability for the accuracy and content of > this attachment and for any damages or losses arising from any > inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other > items of a destructive nature, which may be contained in this attachment > and shall not be liable for direct, indirect, consequential or special > damages in connection with this e-mail message or its attachment. >
RE: [EXTERNAL] Re: Nodetool refresh v/s sstableloader
Sstableloader, though, could require a lot more disk space – until compaction can reduce. For example, if your RF=3, you will essentially be loading 3 copies of the data. Then it will get replicated 3 more times as it is being loaded. Thus, you could need up to 9x disk space. Sean Durity From: kurt greaves Sent: Wednesday, August 29, 2018 7:26 AM To: User Subject: [EXTERNAL] Re: Nodetool refresh v/s sstableloader Removing dev... Nodetool refresh only picks up new SSTables that have been placed in the tables directory. It doesn't account for actual ownership of the data like SSTableloader does. Refresh will only work properly if the SSTables you are copying in are completely covered by that nodes tokens. It doesn't work if there's a change in topology, replication and token ownership will have to be more or less the same. SSTableloader will break up the SSTables and send the relevant bits to whichever node needs it, so no need for you to worry about tokens and copying data to the right places, it will do that for you. On 28 August 2018 at 11:27, Rajath Subramanyam mailto:rajat...@gmail.com>> wrote: Hi Cassandra users, Cassandra dev, When recovering using SSTables from a snapshot, I want to know what are the key differences between using: 1. Nodetool refresh and, 2. SSTableloader Does nodetool refresh have restrictions that need to be met? Does nodetool refresh work even if there is a change in the topology between the source cluster and the destination cluster? Does it work if the token ranges don't match between the source cluster and the destination cluster? Does it work when an old SSTable in the snapshot has a dropped column that is not part of the current schema? I appreciate any help in advance. Thanks, Rajath Rajath Subramanyam The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
Re: Nodetool refresh v/s sstableloader
Removing dev... Nodetool refresh only picks up new SSTables that have been placed in the tables directory. It doesn't account for actual ownership of the data like SSTableloader does. Refresh will only work properly if the SSTables you are copying in are completely covered by that nodes tokens. It doesn't work if there's a change in topology, replication and token ownership will have to be more or less the same. SSTableloader will break up the SSTables and send the relevant bits to whichever node needs it, so no need for you to worry about tokens and copying data to the right places, it will do that for you. On 28 August 2018 at 11:27, Rajath Subramanyam wrote: > Hi Cassandra users, Cassandra dev, > > When recovering using SSTables from a snapshot, I want to know what are > the key differences between using: > 1. Nodetool refresh and, > 2. SSTableloader > > Does nodetool refresh have restrictions that need to be met? > Does nodetool refresh work even if there is a change in the topology > between the source cluster and the destination cluster? Does it work if the > token ranges don't match between the source cluster and the destination > cluster? Does it work when an old SSTable in the snapshot has a dropped > column that is not part of the current schema? > > I appreciate any help in advance. > > Thanks, > Rajath > > Rajath Subramanyam > >
Nodetool refresh v/s sstableloader
Hi Cassandra users, Cassandra dev, When recovering using SSTables from a snapshot, I want to know what are the key differences between using: 1. Nodetool refresh and, 2. SSTableloader Does nodetool refresh have restrictions that need to be met? Does nodetool refresh work even if there is a change in the topology between the source cluster and the destination cluster? Does it work if the token ranges don't match between the source cluster and the destination cluster? Does it work when an old SSTable in the snapshot has a dropped column that is not part of the current schema? I appreciate any help in advance. Thanks, Rajath Rajath Subramanyam
