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/09/10 16:40:57 UTC
[jira] Created: (CASSANDRA-437) record token/endpoint (ip) pairs in
system table
record token/endpoint (ip) pairs in system table
------------------------------------------------
Key: CASSANDRA-437
URL: https://issues.apache.org/jira/browse/CASSANDRA-437
Project: Cassandra
Issue Type: Improvement
Reporter: Jonathan Ellis
Fix For: 0.5
Each node records its own token after generating one or reading it from the config file. For more redundancy we should record others' tokens too.
This should not be regarded as canonical information -- do not use it to take shortcuts instead of using gossip. It is only to provide redundancy in case of failure.
For instance, if your cluster loses power and when it comes back up, the disk w/ token information on one of your machines is dead, this will let you get that token information easily from another node instead of having to guess by scanning sstables. This is not a theoretical scenario; something of this nature did happen to FB.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-437) record token/endpoint (ip) pairs
in system table
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759512#action_12759512 ]
Hudson commented on CASSANDRA-437:
----------------------------------
Integrated in Cassandra #208 (See [http://hudson.zones.apache.org/hudson/job/Cassandra/208/])
record gossipped enpoint/token pairs as we see them. also clean up SystemTable code to avoid unnecessary CF fetches. patch by Gary Dusbabek and jbellis for
> record token/endpoint (ip) pairs in system table
> ------------------------------------------------
>
> Key: CASSANDRA-437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-437
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Gary Dusbabek
> Fix For: 0.5
>
> Attachments: cassandra-437.diff
>
>
> Each node records its own token after generating one or reading it from the config file. For more redundancy we should record others' tokens too.
> This should not be regarded as canonical information -- do not use it to take shortcuts instead of using gossip. It is only to provide redundancy in case of failure.
> For instance, if your cluster loses power and when it comes back up, the disk w/ token information on one of your machines is dead, this will let you get that token information easily from another node instead of having to guess by scanning sstables. This is not a theoretical scenario; something of this nature did happen to FB.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-437) record token/endpoint (ip) pairs
in system table
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757814#action_12757814 ]
Jonathan Ellis commented on CASSANDRA-437:
------------------------------------------
My comments from IRC:
what i was thinking is when a node joins the ring then you just store ip -> token. so the place to look is storageservice.onchange.
no need to expose in nodeprobe; in the system table the data is available by thrift if necessary.
> record token/endpoint (ip) pairs in system table
> ------------------------------------------------
>
> Key: CASSANDRA-437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-437
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Sammy Yu
> Fix For: 0.5
>
>
> Each node records its own token after generating one or reading it from the config file. For more redundancy we should record others' tokens too.
> This should not be regarded as canonical information -- do not use it to take shortcuts instead of using gossip. It is only to provide redundancy in case of failure.
> For instance, if your cluster loses power and when it comes back up, the disk w/ token information on one of your machines is dead, this will let you get that token information easily from another node instead of having to guess by scanning sstables. This is not a theoretical scenario; something of this nature did happen to FB.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-437) record token/endpoint (ip) pairs
in system table
Posted by "Chris Goffinet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757807#action_12757807 ]
Chris Goffinet commented on CASSANDRA-437:
------------------------------------------
Sammy has there been any work on this?
> record token/endpoint (ip) pairs in system table
> ------------------------------------------------
>
> Key: CASSANDRA-437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-437
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Sammy Yu
> Fix For: 0.5
>
>
> Each node records its own token after generating one or reading it from the config file. For more redundancy we should record others' tokens too.
> This should not be regarded as canonical information -- do not use it to take shortcuts instead of using gossip. It is only to provide redundancy in case of failure.
> For instance, if your cluster loses power and when it comes back up, the disk w/ token information on one of your machines is dead, this will let you get that token information easily from another node instead of having to guess by scanning sstables. This is not a theoretical scenario; something of this nature did happen to FB.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-437) record token/endpoint (ip) pairs in
system table
Posted by "Gary Dusbabek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Dusbabek updated CASSANDRA-437:
------------------------------------
Attachment: cassandra-437.diff
Patch generated from trunk.
> record token/endpoint (ip) pairs in system table
> ------------------------------------------------
>
> Key: CASSANDRA-437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-437
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Sammy Yu
> Fix For: 0.5
>
> Attachments: cassandra-437.diff
>
>
> Each node records its own token after generating one or reading it from the config file. For more redundancy we should record others' tokens too.
> This should not be regarded as canonical information -- do not use it to take shortcuts instead of using gossip. It is only to provide redundancy in case of failure.
> For instance, if your cluster loses power and when it comes back up, the disk w/ token information on one of your machines is dead, this will let you get that token information easily from another node instead of having to guess by scanning sstables. This is not a theoretical scenario; something of this nature did happen to FB.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-437) record token/endpoint (ip) pairs
in system table
Posted by "Sammy Yu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sammy Yu reassigned CASSANDRA-437:
----------------------------------
Assignee: Sammy Yu
> record token/endpoint (ip) pairs in system table
> ------------------------------------------------
>
> Key: CASSANDRA-437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-437
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Sammy Yu
> Fix For: 0.5
>
>
> Each node records its own token after generating one or reading it from the config file. For more redundancy we should record others' tokens too.
> This should not be regarded as canonical information -- do not use it to take shortcuts instead of using gossip. It is only to provide redundancy in case of failure.
> For instance, if your cluster loses power and when it comes back up, the disk w/ token information on one of your machines is dead, this will let you get that token information easily from another node instead of having to guess by scanning sstables. This is not a theoretical scenario; something of this nature did happen to FB.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-437) record token/endpoint (ip) pairs in
system table
Posted by "Gary Dusbabek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Dusbabek updated CASSANDRA-437:
------------------------------------
Comment: was deleted
(was: Patched from trunk 817267.)
> record token/endpoint (ip) pairs in system table
> ------------------------------------------------
>
> Key: CASSANDRA-437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-437
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Sammy Yu
> Fix For: 0.5
>
> Attachments: cassandra-437.diff
>
>
> Each node records its own token after generating one or reading it from the config file. For more redundancy we should record others' tokens too.
> This should not be regarded as canonical information -- do not use it to take shortcuts instead of using gossip. It is only to provide redundancy in case of failure.
> For instance, if your cluster loses power and when it comes back up, the disk w/ token information on one of your machines is dead, this will let you get that token information easily from another node instead of having to guess by scanning sstables. This is not a theoretical scenario; something of this nature did happen to FB.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.