You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2012/08/10 15:34:28 UTC

[jira] [Commented] (CASSANDRA-4351) Consider storing more informations on peers in system tables

    [ https://issues.apache.org/jira/browse/CASSANDRA-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13432725#comment-13432725 ] 

Sylvain Lebresne commented on CASSANDRA-4351:
---------------------------------------------

The idea for this ticket is that in an ideal world, I could imagine to have a schema like:
{noformat}
CREATE TABLE System.peers (
    ring_id uuid PRIMARY KEY,
    tokens set<blob>,
    peer inet,
    schema_version uuid,   // so that client can check if the cluster is in agreement
    release_version text,  // quick check to see where we're at of a rolling upgrade
    rpc_address,
    dc text,
    rack text              // a smart client that want to discover node could use that to maintain it's metadata
)
{noformat}

Now the main thing I'm not sure is that currently we have a bunch of cases where we call SystemTable.removeTokens() that I'm not sure how to adapt to such schema. That is, I'm not fully sure I understand why removeTokens is called in some of those cases.

                
> Consider storing more informations on peers in system tables 
> -------------------------------------------------------------
>
>                 Key: CASSANDRA-4351
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4351
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.2
>
>
> Currently, the only thing we keep in system tables about other peers is their token and IP addresses. We should probably also record the new ring_id, but since CASSANDRA-4018 makes system table easily queriable, may it could be worth adding some more information (basically most of what we gossip could be a candidate (schema UUID, status, C* version, ...)) as a simple way to expose the ring state to users (even if it's just a "view" of the ring state from one specific node I believe it's still nice).
> Of course that means storing information that may not be absolutely needed by the server, but I'm not sure there is much harm to that.
> Note that doing this cleanly may require changing the schema of current system tables but as long as we do that in the 1.2 timeframe it's ok (since the concerned system table 'local' and 'peers' are news anyway).

--
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