You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benjamin Coverston (JIRA)" <ji...@apache.org> on 2011/03/03 00:40:36 UTC
[jira] Created: (CASSANDRA-2264) Restore From Snapshot eg: nodetool
restore [filename] | ([keyspace] [columnfamily])
Restore From Snapshot eg: nodetool restore [filename] | ([keyspace] [columnfamily])
-------------------------------------------------------------------------------------
Key: CASSANDRA-2264
URL: https://issues.apache.org/jira/browse/CASSANDRA-2264
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 0.7.2
Reporter: Benjamin Coverston
Store additional metadata in the SSTable including:
generated_by: (From memtable, compaction, or cleanup)
ancestors: A list of SSTableNames|MD5sum
When executed it will copy the ancestors from the snapshot directory to the data directory.
If given Keyspace and ColumnFamily arguments it will attempt to restore all SSTables in the Keyspace/Columnfamily on that node.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2264) Restore From Snapshot eg:
nodetool restore [filename] | ([keyspace] [columnfamily])
Posted by "David Boxenhorn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001930#comment-13001930 ]
David Boxenhorn commented on CASSANDRA-2264:
--------------------------------------------
I guess the next question is what it should do when a bad SSTable is found. It should log an error and blacklist the SSTable as in https://issues.apache.org/jira/browse/CASSANDRA-2261 .
> Restore From Snapshot eg: nodetool restore [filename] | ([keyspace] [columnfamily])
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-2264
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2264
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7.2
> Reporter: Benjamin Coverston
>
> Store additional metadata in the SSTable including:
> generated_by: (From memtable, compaction, or cleanup)
> ancestors: A list of SSTableNames|MD5sum
> When executed it will copy the ancestors from the snapshot directory to the data directory.
> If given Keyspace and ColumnFamily arguments it will attempt to restore all SSTables in the Keyspace/Columnfamily on that node.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2264) Restore From Snapshot eg:
nodetool restore [filename] | ([keyspace] [columnfamily])
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002030#comment-13002030 ]
Jonathan Ellis commented on CASSANDRA-2264:
-------------------------------------------
Why do we need to store additional metadata? ISTM that "restore from snapshot" should just be "make the snapshotted sstables live."
> Restore From Snapshot eg: nodetool restore [filename] | ([keyspace] [columnfamily])
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-2264
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2264
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7.2
> Reporter: Benjamin Coverston
>
> Store additional metadata in the SSTable including:
> generated_by: (From memtable, compaction, or cleanup)
> ancestors: A list of SSTableNames|MD5sum
> When executed it will copy the ancestors from the snapshot directory to the data directory.
> If given Keyspace and ColumnFamily arguments it will attempt to restore all SSTables in the Keyspace/Columnfamily on that node.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2264) Restore From Snapshot eg:
nodetool restore [filename] | ([keyspace] [columnfamily])
Posted by "David Boxenhorn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002555#comment-13002555 ]
David Boxenhorn commented on CASSANDRA-2264:
--------------------------------------------
"Why do we need to store additional metadata?"
Is this meta-data already available somewhere?
If I have a bad SSTable I want to know how it got bad. (I want to know that real bad.) I want as much information as possible - you never know what piece of information will lead you to the bug. In particular, knowing which process created it could point me in the right direction, even in the case that it's a hardware bug.
May I suggest a human-readable -Stat table (perhaps, name-value pairs) alongside every -Data table, with as much information as possible in it, so that no special tools would be needed for forensics? Among the information in the -Stat table would be the SSTable's ancestors (if any) and which process created it.
I am speaking from the point of view of a somewhat, but not completely, naive user. Solutions have to be available to people like me. I have a machine which used to be a bad node that I swapped out of the cluster. The data is still there. What kinds of tools do I need to enable me to do forensics on that detached node? If not the above, then what? That's what I want.
> Restore From Snapshot eg: nodetool restore [filename] | ([keyspace] [columnfamily])
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-2264
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2264
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7.2
> Reporter: Benjamin Coverston
>
> Store additional metadata in the SSTable including:
> generated_by: (From memtable, compaction, or cleanup)
> ancestors: A list of SSTableNames|MD5sum
> When executed it will copy the ancestors from the snapshot directory to the data directory.
> If given Keyspace and ColumnFamily arguments it will attempt to restore all SSTables in the Keyspace/Columnfamily on that node.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2264) Restore From Snapshot eg:
nodetool restore [filename] | ([keyspace] [columnfamily])
Posted by "David Boxenhorn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001921#comment-13001921 ]
David Boxenhorn commented on CASSANDRA-2264:
--------------------------------------------
It would also be nice if we could flip a switch and check all SSTables right after they are created. This would help us in the case where we are trying to pinpoint where bad SSTables are entering the system. Also, if this check does not catch anything, and bad SSTables are created anyway, we will know that the source of the corruption is exogenous.
I imagine that it would also help in testing prospective Cassandra releases...
> Restore From Snapshot eg: nodetool restore [filename] | ([keyspace] [columnfamily])
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-2264
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2264
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7.2
> Reporter: Benjamin Coverston
>
> Store additional metadata in the SSTable including:
> generated_by: (From memtable, compaction, or cleanup)
> ancestors: A list of SSTableNames|MD5sum
> When executed it will copy the ancestors from the snapshot directory to the data directory.
> If given Keyspace and ColumnFamily arguments it will attempt to restore all SSTables in the Keyspace/Columnfamily on that node.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira