You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2009/10/09 00:44:31 UTC
[jira] Created: (CASSANDRA-483) more fun with autobootstrap
more fun with autobootstrap
---------------------------
Key: CASSANDRA-483
URL: https://issues.apache.org/jira/browse/CASSANDRA-483
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Fix For: 0.5
now that autobootstrap (CASSANDRA-438) is in, we have a couple other things worth fixing
- a utility to mark a node "bootstrapped" so that people upgrading from 0.4 won't have nodes that shouldn't bootstrap, try to do so
- extra smartness for starting a new cluster -- what we want is to have the seed "bootstrap" each other node in turn, but i don't think it handles multiple nodes in overlapping ranges simultaneously right now. (and we don't need it to -- we only need to tell nodes 3, 4, etc. to wait until node 2 is done.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-483:
-------------------------------------
Attachment: 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-483.
--------------------------------------
Resolution: Fixed
committed, with suggested change to TODO
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-rename-away-underscores.txt, 0003-fix-the-bootstrap-interaction-with-gossip-there-were.txt, 0004-rename-getRangeMap-getRangeAddresses-add-inverse-g.txt, 0005-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-483:
-------------------------------------
Attachment: (was: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt)
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-483:
-------------------------------------
Attachment: (was: 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt)
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-483:
-------------------------------------
Attachment: (was: 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt)
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-483:
-------------------------------------
Description:
existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
(this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
was:
now that autobootstrap (CASSANDRA-438) is in, we have a couple other things worth fixing
- a utility to mark a node "bootstrapped" so that people upgrading from 0.4 won't have nodes that shouldn't bootstrap, try to do so
- extra smartness for starting a new cluster -- what we want is to have the seed "bootstrap" each other node in turn, but i don't think it handles multiple nodes in overlapping ranges simultaneously right now. (and we don't need it to -- we only need to tell nodes 3, 4, etc. to wait until node 2 is done.)
Summary: clean up bootstrap code, 2 (was: more fun with autobootstrap)
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-483:
-------------------------------------
Attachment: 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-483:
-------------------------------------
Attachment: (was: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt)
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-483:
-------------------------------------
Attachment: 0005-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
0004-rename-getRangeMap-getRangeAddresses-add-inverse-g.txt
0003-fix-the-bootstrap-interaction-with-gossip-there-were.txt
0002-rename-away-underscores.txt
0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-rename-away-underscores.txt, 0003-fix-the-bootstrap-interaction-with-gossip-there-were.txt, 0004-rename-getRangeMap-getRangeAddresses-add-inverse-g.txt, 0005-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Chris Goffinet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770371#action_12770371 ]
Chris Goffinet commented on CASSANDRA-483:
------------------------------------------
+1. Looks good. Though please fix //TODO ditto ;-) Be more descriptive.
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-rename-away-underscores.txt, 0003-fix-the-bootstrap-interaction-with-gossip-there-were.txt, 0004-rename-getRangeMap-getRangeAddresses-add-inverse-g.txt, 0005-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770203#action_12770203 ]
Jonathan Ellis commented on CASSANDRA-483:
------------------------------------------
also fixes the bootstrap interaction with gossip; there were two main problems:
1) token and bootstrap state are not guaranteed to be gossiped together; since we only updated TMD.bootstrapNodes on an update of the token, this means we could actually miss the bootstrap notice
2) deletions of state are not actually supported by Gossiper; there is no concept of that at the protocol level. so if we delete state locally it will never get gossiped. Instead, we have a MODE that is either MOVING or NORMAL, corresponding to bootstrap & normal operation. (Sandeep had it working like this in his initial bootstrap patches and I led him astray, sorry. :)
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-483:
-------------------------------------
Attachment: 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-483:
-------------------------------------
Attachment: (was: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt)
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-483) clean up bootstrap
code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770203#action_12770203 ]
Jonathan Ellis edited comment on CASSANDRA-483 at 10/27/09 3:06 AM:
--------------------------------------------------------------------
05
refactor bootstrap to only concern itself with bootstrapping the local node, which greatly simplifies things
04
rename getRangeMap -> getRangeAddresses; add inverse getAddressRanges
03
fix the bootstrap interaction with gossip; there were two main problems:
1) token and bootstrap state are not guaranteed to be gossiped together; since we only updated
TMD.bootstrapNodes on an update of the token, this means we could actually miss the bootstrap notice
2) deletions of state are not actually supported by Gossiper; there is no concept of that at the protocol
level. so if we delete state locally it will never get gossiped. Instead, we have a MODE that is either
MOVING or NORMAL, corresponding to bootstrap & normal operation.
02
rename away underscores
01
r/m single-use executor in favor of a Thread
was (Author: jbellis):
also fixes the bootstrap interaction with gossip; there were two main problems:
1) token and bootstrap state are not guaranteed to be gossiped together; since we only updated TMD.bootstrapNodes on an update of the token, this means we could actually miss the bootstrap notice
2) deletions of state are not actually supported by Gossiper; there is no concept of that at the protocol level. so if we delete state locally it will never get gossiped. Instead, we have a MODE that is either MOVING or NORMAL, corresponding to bootstrap & normal operation. (Sandeep had it working like this in his initial bootstrap patches and I led him astray, sorry. :)
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-rename-away-underscores.txt, 0003-fix-the-bootstrap-interaction-with-gossip-there-were.txt, 0004-rename-getRangeMap-getRangeAddresses-add-inverse-g.txt, 0005-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770913#action_12770913 ]
Hudson commented on CASSANDRA-483:
----------------------------------
Integrated in Cassandra #241 (See [http://hudson.zones.apache.org/hudson/job/Cassandra/241/])
refactor bootstrap to only concern itself with bootstrapping the local node, which greatly simplifies things
patch by jbellis; reviewed by goffinet for
rename getRangeMap -> getRangeAddresses; add inverse getAddressRanges
patch by jbellis; reviewed by goffinet for
fix the bootstrap interaction with gossip; there were two main problems:
1) token and bootstrap state are not guaranteed to be gossiped together; since we only updated TMD.bootstrapNodes on an update of the token, this means we could actually miss the bootstrap notice
2) deletions of state are not actually supported by Gossiper; there is no concept of that at the protocol level. so if we delete state locally it will never get gossiped. Instead, we have a MODE that is either MOVING or NORMAL, corresponding to bootstrap & normal operation.
patch by jbellis; reviewed by goffinet for
rename away underscores
patch by jbellis; reviewed by goffinet for
r/m single-use executor in favor of a Thread
patch by jbellis; reviewed by goffinet for
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-rename-away-underscores.txt, 0003-fix-the-bootstrap-interaction-with-gossip-there-were.txt, 0004-rename-getRangeMap-getRangeAddresses-add-inverse-g.txt, 0005-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-483) clean up bootstrap code, 2
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-483:
-------------------------------------
Attachment: (was: 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt)
> clean up bootstrap code, 2
> --------------------------
>
> Key: CASSANDRA-483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments: 0001-CASSANDRA-483-r-m-single-use-executor-in-favor-of-a-Th.txt, 0002-refactor-bootstrap-to-only-concern-itself-with-bootstr.txt
>
>
> existing bootstrap code overengineers things a bit by allowing multiple nodes to bootstrap into the same span of the ring simultaneously. but, this doesn't handle the case where one of them doesn't complete the bootstrap. one possible response would be to transfer that node's span to one of the other new nodes, but then you're no longer evenly dividing the ring. starting over with recomputed tokens for the remaining nodes is significantly complicated.
> in short I think the right solution is to handle each node independently. if only one node bootstraps into a ring segment at a time, nothing changes. but if another node bootstraps in before the first finishes, we just say "okay" and send them each the data they would get _if it were the only node bootstrapping_. So if one fails, we don't have to do any extra work. If all succeed, the penalty is we transferred too much to some nodes but that will be taken care of by the existing cleanup compaction code.
> (this does mean that we can't automatically pick tokens while a bootstrap is in progress, though, or it will pick the same one for both, which is undesireable. but saying "if you want to bootstrap multiple nodes into the same ring span at once, you have to manually specify the tokens" seems reasonable to me. (especially since that was already the case under the old system, if you didn't want just random tokens.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.