cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-620) Add per-keyspace replication factor (possibly even replication strategy)
Date Wed, 06 Jan 2010 23:40:54 GMT


Jonathan Ellis commented on CASSANDRA-620:

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

We still want one token per node, which means singleton TokenMetadata should still be fine.
 The pendingranges business will probably need to grow a Table parameter, but the core is
mapping Token to IP which won't need to change.  (All the higher-level stuff is in ARS already.)

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

Right.  That is, we still want it "at once" in the sense that the node doesn't join the ring
until it's ready to serve reads for all its ranges, but the range determination will be per-table.

> Add per-keyspace replication factor (possibly even replication strategy)
> ------------------------------------------------------------------------
>                 Key: CASSANDRA-620
>                 URL:
>             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.

View raw message