[
https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Description:
(Updated to reflect the true scope of this improvement along with decisions
about implementation)
Currently, the DatacenterShardStrategy reads in a properties file -
datacenters.properties - to get a per-datacenter replication factor.
This improvement would do away with a separate properties file for configuring
per-datacenter replication in favor of configuring them on a per-keyspace
basis. This would allow clients to create a new keyspace with the
configuration of the DatacenterShardStrategy as part of the keyspace
definition. It would also update the cassandra.yaml configuration parsing to
allow users to configure their DSS from there as well.
The basic structure would not change and the KSMetaData would just contain
additional configuration information - a map of configuration options. That
way, if other ReplicationStrategies in the future would like specific
configuration options, they can use them as well.
Further changes previously mentioned in this ticket involved enforcing the
replication factor. A separate ticket has been created to push the replication
factor down to the replication strategy. That facilitates enforcing the RF at
that level.
was:
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. This part will be addressed in CASSANDRA-1263 as pushing the
replication factor down into the strategy really facilitates this.
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.
> 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.0
>
> Attachments: 1066-3.txt, 1066-changes-patch.txt, 1066-external.patch,
> 1066.txt, 1066.txt
>
>
> (Updated to reflect the true scope of this improvement along with decisions
> about implementation)
> Currently, the DatacenterShardStrategy reads in a properties file -
> datacenters.properties - to get a per-datacenter replication factor.
> This improvement would do away with a separate properties file for
> configuring per-datacenter replication in favor of configuring them on a
> per-keyspace basis. This would allow clients to create a new keyspace with
> the configuration of the DatacenterShardStrategy as part of the keyspace
> definition. It would also update the cassandra.yaml configuration parsing to
> allow users to configure their DSS from there as well.
> The basic structure would not change and the KSMetaData would just contain
> additional configuration information - a map of configuration options. That
> way, if other ReplicationStrategies in the future would like specific
> configuration options, they can use them as well.
> Further changes previously mentioned in this ticket involved enforcing the
> replication factor. A separate ticket has been created to push the
> replication factor down to the replication strategy. That facilitates
> enforcing the RF at that level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
