cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Overton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4123) vnodes aware Replication Strategy
Date Wed, 27 Jun 2012 14:51:44 GMT

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

Sam Overton commented on CASSANDRA-4123:
----------------------------------------

I should point out that the existing NTS (and also the modified implementation in CASSANDRA-3881)
already prevent replicas from being placed on the same host. The first couple of paragraphs
in the ticket description could probably be removed.

The main issue left in this ticket is this notion of Distribution Factor and replica sets,
to reduce the chance that simultaneous failures share data.


                
> vnodes aware Replication Strategy 
> ----------------------------------
>
>                 Key: CASSANDRA-4123
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4123
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Sam Overton
>            Assignee: Sam Overton
>
> The simplest implementation for this would be if NTS regarded a single host as a distinct
rack. This would prevent replicas being placed on the same host. The rest of the logic for
replica selection would be identical to NTS (but this would be removing a level of topology
hierarchy). This would be achievable just by writing a snitch to place hosts in their own
rack.
> A better solution would be to add an extra level of hierarchy to NTS so that it still
supported DC & rack, and IP would be the new level at the bottom of the hierarchy. The
logic would remain largely the same.
> I would very much like to build in Peter Schuller's notion of Distribution Factor (as
described in http://www.mail-archive.com/dev@cassandra.apache.org/msg03844.html). This requires
a method of defining a "replica set" for each host and then treating it in a similar way to
a DC (ie. RF replicas are chosen from that set, instead of from the whole cluster). 

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

        

Mime
View raw message