[jira] Commented: (CASSANDRA-620) Add per-keyspace replication factor (possibly even replication strategy)

["Jaakko Laine (JIRA)" <ji...@apache.org>]

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

Jaakko Laine commented on CASSANDRA-620:
----------------------------------------

Yes, pending ranges is range->list<InetAddress> mapping. Replication strategy dictates *what* nodes there are in the list and in which order, whereas replication factor dictates the *length* of the list. If we have two tables with same replication factor, it would be sufficient to calculate pending ranges once for maximum replication factor for that table, since pending ranges for smaller factor will be a subset of the other. An example to illustrate this:

Suppose we have TableA and TableB using same strategy, with replication factors 2 and 3 respectively. Suppose there are nodes NodeA, NodeB and NodeC in the cluster and NodeD boots "behind" NodeC. In this situation pending ranges for NodeD would be:

TableA: B-C, C-D
TableB: A-B, B-C, C-D

Notice that pending ranges for TableA is a subset of pending ranges for TableB. Instead of having pending ranges per table, it would be enough to have them per replication strategy in use. We could then just pick replication factor number of nodes from the beginning of the list.

Anyway, as said before, this is an optimization which can be done later if needed.

The patchset loogs OK to me.


> Add per-keyspace replication factor (possibly even replication strategy)
> ------------------------------------------------------------------------
>
>                 Key: CASSANDRA-620
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-620
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Jonathan Ellis
>            Assignee: Gary Dusbabek
>             Fix For: 0.6
>
>         Attachments: 0001-push-replication-factor-and-strategy-into-table-exce.patch, 0002-cleaned-up-as-much-as-possible-before-dealing-with-r.patch, 0003-push-table-names-into-streaming-expose-TMD-in-ARS.patch, 0004-fix-non-compiling-tests.-necessary-changes-in-test-c.patch, 0005-introduce-table-into-pending-ranges-code.patch, 0006-added-additional-testing-keyspace.patch, 0007-modify-TestRingCache-to-make-it-easier-to-test-speci.patch, 0008-push-endpoint-snitch-into-keyspace-configuration.patch, 0009-make-TMD-private-in-ARS.patch, 0010-fix-problems-with-bootstrapping.patch, 0011-remove-replicas-from-ARS.patch, 0012-ensure-that-unbootstrap-calls-onFinish-after-tables-.patch, 0013-adjustments-for-new-clusterprobe-tool.patch, v1-patches.tgz, v2-patches.tgz
>
>
> (but partitioner may only be cluster-wide, still)
> not 100% sure this makes sense but it would allow maintaining system metadata in a replicated-across-entire-cluster keyspace (without ugly special casing), as well as making Cassandra more flexible as a shared resource for multiple apps

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.