cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4351) Consider storing more informations on peers in system tables
Date Fri, 05 Oct 2012 16:50:02 GMT

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

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

Oh I see. Was mislead by the fact that cqlsh don't print blob in hex currently. But if we
fix that then yes, that'd be the same, at least for Murmur3Partitioner.

Though I do note that Murmur3Partitioner is only an option for brand new clusters (i.e. almost
no-one will have Murmur3Partitioner at first). But again, I don't care too much. I suppose
that in the long run, with vnodes, the pretty printing of tokens won't be very useful anymore.
                
> 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.0 beta 2
>
>         Attachments: 0001-4351.txt, 0002-Save-tokens-as-strings.txt
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message