[
https://issues.apache.org/jira/browse/CASSANDRA-11337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191599#comment-15191599
]
Paulo Motta commented on CASSANDRA-11337:
-----------------------------------------
tested locally and worked as expected:
{noformat}
nodetool getsstables --hex-format keyspace1 standard1 3330394c344e35313730
~/.ccm/test/node1/data0/keyspace1/standard1-49f7b910e7d511e5ba4be7733a17ee6e/ma-1-big-Data.db
{noformat}
> Add --hex-format option to nodetool getsstables
> -----------------------------------------------
>
> Key: CASSANDRA-11337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11337
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Paulo Motta
> Assignee: Paulo Motta
> Priority: Minor
> Labels: lhf
>
> Sometimes it's useful to retrieve an sstable from the hex string
> representation of its key, for instance, when you get an exception like this
> and you want to find out which sstable owns the faulty key:
> {noformat}
> java.lang.AssertionError: row DecoratedKey(2769066505137675224,
> 00040000002e00000800000153441a3ef000) received out of order wrt
> DecoratedKey(2774747040849866654, 00040000019b0000080000015348847eb200)
> {noformat}
> In this case, {noformat}nodetool getsstables ks cf
> 00040000002e00000800000153441a3ef000{noformat} will only work if {{ks.cf}}
> has a blob primary key.
> It's straightforward to retrieve a {{DecoratedKey}} from the hexstr
> representation of the key, so we should add a {{--hex-key}} option to allow
> for that.
> {noformat}nodetool getsstables ks cf --hex-key
> 00040000002e00000800000153441a3ef000{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
