[
https://issues.apache.org/jira/browse/CASSANDRA-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-6719:
---------------------------------------
Reviewer: (was: Yuki Morishita)
Status: Patch Available (was: Open)
https://github.com/krummas/cassandra/commits/marcuse/6719
* Deprecate old nodetool refresh
* Add new nodetool import <ks> <cf> -d <directory>
* Add option to keep the sstable level
* Add option to keep repaired-info
* Verify that the sstables to import are not corrupt before importing (with
option to skip)
* Verify that the tokens in the sstable are owned by the current node (with
option to skip)
* Invalidates row cache
* Due to CASSANDRA-6696 we need to figure out which directory is best for the
imported sstable. This is done by iterating over the keys and counting where
most keys should end up (we need to iterate over the keys to invalidate caches
anyway) - also created CASSANDRA-14327 to actually run a compaction of the new
sstables to make sure the tokens end up in the correct directories
> redesign loadnewsstables
> ------------------------
>
> Key: CASSANDRA-6719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6719
> Project: Cassandra
> Issue Type: New Feature
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Marcus Eriksson
> Priority: Minor
> Labels: lhf
> Fix For: 4.x
>
> Attachments: 6719.patch
>
>
> CFSMBean.loadNewSSTables scans data directories for new sstables dropped
> there by an external agent. This is dangerous because of possible filename
> conflicts with existing or newly generated sstables.
> Instead, we should support leaving the new sstables in a separate directory
> (specified by a parameter, or configured as a new location in yaml) and take
> care of renaming as necessary automagically.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
