[
https://issues.apache.org/jira/browse/CASSANDRA-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797388#action_12797388
]
Gary Dusbabek commented on CASSANDRA-620:
-----------------------------------------
I've spent some time looking at this. The biggest obstacle I've seen so far is
that introducing RF per keyspace means that you can no longer deduce a range
from a token (you'll need token + keyspace).
Correct me if I'm wrong, but here is what looks like needs to be changed:
The replicationStrategy and tokenMetadata members in SS will go away. Each
table is going to need its own replication strategy, which implies a
TokenMetadata for each. TokenMetadata has been treated as a singleton up until
now, so I'll need to figure out how to approach that.
Bootstrapping will need to happen per table instead of all tables at once since
the range of each node will vary according to the table replication factor.
After that, I think I'll have smooth sailing. Is there anything obvious and
big I might be missing?
> 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
> Fix For: 0.9
>
>
> (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.
