[
https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: tentative-1066-changes.txt
Attaching a tentative way to handle this. Most of the files modified are just
renaming variables, but a few of them have more substantial changes.
Essentially, since there is a 1:1 relationship between replication strategies
and keyspaces, it seems natural to add the replication strategy to the keyspace
data structure. That way the independent map of quasi-singletons of
replication strategies can be removed and everything is handled by the keyspace
metadata object. That cleans up some other instances when things like removing
keyspaces happens. It also makes it nice when new keyspaces are created
because it's all handled in one place - the system add keyspace call.
Otherwise, we would run into the condition that the configuration for DSS would
have to be done before the keyspace is created in order for it to have a
working strategy. Additionally, whenever we handle the alter keyspace
functionality, it's nice to have that together.
Another approach would have been to handle initialization within the keyspace
metadata class itself, but Gary seemed opposed to doing that in there. That
does mean that since the keyspace metadata object has the full strategy object,
it will need to handle serialization/deserialization for it, but that would
need to happen in any case where we tie the two together (strategy and KSM).
Gary - btw is there any reason why we're writing our own serialization code for
the KSM object rather than just relying on Java's serialization?
I've commented out some things and haven't done the avro binding fully just
because this is a rough patch to get feedback about the approach.
> DatacenterShardStrategy needs enforceable and keyspace based RF
> ---------------------------------------------------------------
>
> Key: CASSANDRA-1066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1066
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jeremy Hanna
> Priority: Minor
> Fix For: 0.7
>
> Attachments: tentative-1066-changes.txt
>
>
> Currently, the DatacenterShardStrategy reads in a properties file -
> datacenters.properties - to get a per-datacenter replication factor. So any
> keyspace that is using the DSS in the cluster is using that same properties
> file to configure its replication factor. The implementation doesn't take
> into account the per-keyspace replication factor, but it is assumed that the
> sum of all the datacenter RF values equals the per-keyspace replication value
> that is part of the keyspace metadata.
> It seems that an improvement could be two-fold:
> 1. Enforce the replication factor for the keyspace as always equal the sum of
> all the datacenter RF values. Otherwise, if they aren't equal, bad things
> (tm) can happen.
> 2. Make the datacenter RF values part of the keyspace metadata rather than a
> global value. Again, currently if any keyspace in the cluster is configured
> to use DSS, it will be using the global DC RF values found in the properties
> file. An improvement could be to instead of having the properties file,
> configure that on a per keyspace basis. That would make the cluster more
> multi-tenant friendly so it could be flexible with multiple keyspaces.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
