You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Brandon Williams (Created) (JIRA)" <ji...@apache.org> on 2012/03/14 00:18:40 UTC
[jira] [Created] (CASSANDRA-4047) Bulk hinting
Bulk hinting
------------
Key: CASSANDRA-4047
URL: https://issues.apache.org/jira/browse/CASSANDRA-4047
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Brandon Williams
Fix For: 1.2
With the introduction of the BulkOutputFormat, there may be cases where someone would like to tolerate node failures and have the job complete, but afterwards since we streamed they have to repair or rely on read repair. We don't currently have any way of hinting streams, but a node could take a snapshot before acknowledging the stream session, then remember to send the files in the snapshot to the unavailable nodes when they come back up. This isn't quite ideal since of course the node may have compacted these files, however it's much simpler than any sort of key tracking at this scale.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4047) Bulk hinting
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13397956#comment-13397956 ]
Brandon Williams commented on CASSANDRA-4047:
---------------------------------------------
The tricky part is, who stores the hint? Since it's a non-member doing the streaming... I guess it could just choose some other target at random, but by the time it does that the sstable might already be compacted away.
> Bulk hinting
> ------------
>
> Key: CASSANDRA-4047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4047
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Brandon Williams
> Assignee: Brandon Williams
> Fix For: 1.2
>
>
> With the introduction of the BulkOutputFormat, there may be cases where someone would like to tolerate node failures and have the job complete, but afterwards since we streamed they have to repair or rely on read repair. We don't currently have any way of hinting streams, but a node could take a snapshot before acknowledging the stream session, then remember to send the files in the snapshot to the unavailable nodes when they come back up. This isn't quite ideal since of course the node may have compacted these files, however it's much simpler than any sort of key tracking at this scale.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4047) Bulk hinting
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398493#comment-13398493 ]
Brandon Williams commented on CASSANDRA-4047:
---------------------------------------------
bq. Alternatively... we can do repairs of specific ranges now. What if we stored as our "hint" the range we streamed, and the node that went down, and then the live node will run a partial repair with that replica when it comes back up?
This sounds like a good way to do it. One wrinkle though is communication, now that bulk loading doesn't have a MS to speak with, it only has streaming or thrift available, and shunting this into either seems awkward.
> Bulk hinting
> ------------
>
> Key: CASSANDRA-4047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4047
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Brandon Williams
> Assignee: Brandon Williams
> Fix For: 1.2
>
>
> With the introduction of the BulkOutputFormat, there may be cases where someone would like to tolerate node failures and have the job complete, but afterwards since we streamed they have to repair or rely on read repair. We don't currently have any way of hinting streams, but a node could take a snapshot before acknowledging the stream session, then remember to send the files in the snapshot to the unavailable nodes when they come back up. This isn't quite ideal since of course the node may have compacted these files, however it's much simpler than any sort of key tracking at this scale.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4047) Bulk hinting
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398214#comment-13398214 ]
Jonathan Ellis commented on CASSANDRA-4047:
-------------------------------------------
Ugh, that is pretty messy.
One complication is that the outputformat node can't assume that it will know ahead of time which replicas it will need to generate hints for (since nodes can go down after it's started streaming everywhere).
I think that means we'd need to stream a *second* copy (since the first may have been compacted already) to one of the nodes, after we learn that hints are needed.
Alternatively... we can do repairs of specific ranges now. What if we stored as our "hint" the range we streamed, and the node that went down, and then the live node will run a partial repair with that replica when it comes back up?
> Bulk hinting
> ------------
>
> Key: CASSANDRA-4047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4047
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Brandon Williams
> Assignee: Brandon Williams
> Fix For: 1.2
>
>
> With the introduction of the BulkOutputFormat, there may be cases where someone would like to tolerate node failures and have the job complete, but afterwards since we streamed they have to repair or rely on read repair. We don't currently have any way of hinting streams, but a node could take a snapshot before acknowledging the stream session, then remember to send the files in the snapshot to the unavailable nodes when they come back up. This isn't quite ideal since of course the node may have compacted these files, however it's much simpler than any sort of key tracking at this scale.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-4047) Bulk hinting
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis reassigned CASSANDRA-4047:
-----------------------------------------
Assignee: Brandon Williams
I guess we could add a hint type field to the hints table (easier post-CASSANDRA-4018) to say whether the hint is a "classic" mutation hint, or a snapshotted sstable.
> Bulk hinting
> ------------
>
> Key: CASSANDRA-4047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4047
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Brandon Williams
> Assignee: Brandon Williams
> Fix For: 1.2
>
>
> With the introduction of the BulkOutputFormat, there may be cases where someone would like to tolerate node failures and have the job complete, but afterwards since we streamed they have to repair or rely on read repair. We don't currently have any way of hinting streams, but a node could take a snapshot before acknowledging the stream session, then remember to send the files in the snapshot to the unavailable nodes when they come back up. This isn't quite ideal since of course the node may have compacted these files, however it's much simpler than any sort of key tracking at this scale.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4047) Bulk hinting
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398586#comment-13398586 ]
Jonathan Ellis commented on CASSANDRA-4047:
-------------------------------------------
Is this where we throw up our hands and finally add multi-port ability for MessagingService?
> Bulk hinting
> ------------
>
> Key: CASSANDRA-4047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4047
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Brandon Williams
> Assignee: Brandon Williams
> Fix For: 1.2
>
>
> With the introduction of the BulkOutputFormat, there may be cases where someone would like to tolerate node failures and have the job complete, but afterwards since we streamed they have to repair or rely on read repair. We don't currently have any way of hinting streams, but a node could take a snapshot before acknowledging the stream session, then remember to send the files in the snapshot to the unavailable nodes when they come back up. This isn't quite ideal since of course the node may have compacted these files, however it's much simpler than any sort of key tracking at this scale.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira