You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jeremy Hanna (JIRA)" <ji...@apache.org> on 2010/05/07 22:51:47 UTC
[jira] Created: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
DatacenterShardStrategy needs enforceable and keyspace based RF
---------------------------------------------------------------
Key: CASSANDRA-1066
URL: https://issues.apache.org/jira/browse/CASSANDRA-1066
Project: Cassandra
Issue Type: Improvement
Reporter: Jeremy Hanna
Priority: Minor
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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: 1066.txt
> 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-changes-patch.txt, 1066.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: 1066-3.txt
Rebased and modified with updates based on Stu's comments.
> 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
>
>
> 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.
[jira] Commented: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893747#action_12893747 ]
Stu Hood commented on CASSANDRA-1066:
-------------------------------------
+1
Looks good to me, although the committer might want to bump the Thrift/Avro API version numbers... I'm not sure if we've been doing that for every change in trunk.
> 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
>
>
> 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.
[jira] Commented: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865898#action_12865898 ]
Jonathan Ellis commented on CASSANDRA-1066:
-------------------------------------------
CASSANDRA-952 is going to touch this code, btw.
> 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
>
>
> 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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: 1066-external.patch
Updating the patch now with working unit tests. This time, implemented it in a way to keep the strategies' instances separate from the keyspace metadata, as was discussed.
> 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-changes-patch.txt, 1066-external.patch, 1066.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.
[jira] Commented: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894149#action_12894149 ]
Eric Evans commented on CASSANDRA-1066:
---------------------------------------
A few issues, some of which we discussed on IRC, but I'll put them on record here anyway:
* I had mentioned on IRC that I thought "stragegy_options" was too generic, but it occurred to me that it's consistent with strategy_class. I still think it's too generic, but it's probably not worth changing without changing both (and it's probably not worth doing that).
* cassandra-cli will need updating so that it's possible create keyspaces with these options set (I'd just create another ticket and link it to this one).
* As mentioned on IRC, DD.readTablesFromYaml() hard-codes the strategy options to null
* In KSMetaData.deflate(); ks.strategy_options will never get assigned because it will always be null (that expression should test strategyOptions instead).
Also, are the system tests passing for you? I'm getting the following:
{noformat}
======================================================================
ERROR: system.test_thrift_server.TestMutations.test_bad_calls
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/pymodules/python2.6/nose/case.py", line 364, in setUp
try_run(self.inst, ('setup', 'setUp'))
File "/usr/lib/pymodules/python2.6/nose/util.py", line 487, in try_run
return func()
File "/home/eevans/dev/src/git/cassandra/test/system/__init__.py", line 124, in setUp
self.define_schema()
File "/home/eevans/dev/src/git/cassandra/test/system/__init__.py", line 180, in define_schema
self.client.system_add_keyspace(ks)
File "/home/eevans/dev/src/git/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py", line 1288, in system_add_keyspace
self.send_system_add_keyspace(ks_def)
File "/home/eevans/dev/src/git/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py", line 1295, in send_system_add_keyspace
args.write(self._oprot)
File "/home/eevans/dev/src/git/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py", line 5745, in write
oprot.trans.write(fastbinary.encode_binary(self, (self.__class__, self.thrift_spec)))
SystemError: ../Objects/dictobject.c:1562: bad argument to internal function
{noformat}
I'll probably be touch-and-go after today (traveling), but I'll try and check back in on this issue so that you don't have to start over with someone new. For me, it'd be easier if you incorporated the changes mentioned here in separate patch, one that applied on top of this one.
> 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-4.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: (was: tentative-1066-changes.txt)
> 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: 1066-changes-patch.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865337#action_12865337 ]
Jeremy Hanna commented on CASSANDRA-1066:
-----------------------------------------
One solution could be to push the replication factor back to the strategy by a method to get the replication factor there. That way it could be more flexible/customizable.
> DatacenterShardStrategy needs enforceable and keyspace based RF
> ---------------------------------------------------------------
>
> Key: CASSANDRA-1066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1066
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 0.7
> Reporter: Jeremy Hanna
> Priority: Minor
>
> 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.
[jira] Assigned: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna reassigned CASSANDRA-1066:
---------------------------------------
Assignee: Jeremy Hanna
> DatacenterShardStrategy needs enforceable and keyspace based RF
> ---------------------------------------------------------------
>
> Key: CASSANDRA-1066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1066
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 0.7
> Reporter: Jeremy Hanna
> Assignee: Jeremy Hanna
> Priority: Minor
>
> 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.
[jira] Commented: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868694#action_12868694 ]
Jeremy Hanna commented on CASSANDRA-1066:
-----------------------------------------
Because of the work with CASSANDRA-952, the values in datacenters.properties are now keyspace specific. So it solves that part of this issue. It's still a global collection of properties, but now it has to be specified per keyspace.
So now this improvement is about 1) enforcing the RF that is originally set on the keyspace to include what is set in datacenters.properties and 2) making that information dynamic so that it can be updated at run time.
> 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
>
>
> 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.
[jira] Commented: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Gary Dusbabek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881880#action_12881880 ]
Gary Dusbabek commented on CASSANDRA-1066:
------------------------------------------
* CS should use SS.instance.getTokenMetadata() instead of creating a new one.
* the factory calls the old implicit constructor and then init(). Is this an improvement over just adding a map to the constructor args, and then having the constructor (if needed) do the work in init? Having an init() method opens up the API to abuse (when should[n't] I call init, etc.?). I'm in favor of just amending the implicit constructors.
* fix all the todos. :)
> 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: 1066-changes-patch.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Affects Version/s: 0.7
> DatacenterShardStrategy needs enforceable and keyspace based RF
> ---------------------------------------------------------------
>
> Key: CASSANDRA-1066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1066
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 0.7
> Reporter: Jeremy Hanna
> Priority: Minor
>
> 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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Description:
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.
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.
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
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: (was: 1066.txt)
> 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-changes-patch.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: (was: 1066.txt)
> 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-changes-patch.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.
[jira] Commented: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893685#action_12893685 ]
Stu Hood commented on CASSANDRA-1066:
-------------------------------------
* Comment in conf/cassandra.yaml refers to IReplicaPlacementStrategy
* Neither strategy_class nor strategy_class_options should allow nulls in Avro's KsDef: a map should default to empty, and strategy_class should always be set.
* Some commented printlns made it into dht.Range, TMD, CFSTest
* Why override AbstractReplicationStrategy.equals?
* The "datacenters changed, clearing endpoint cache" in DCShardStrategy shouldn't be necessary anymore
* Can you rename the static version of StorageService.getReplicationStrategy to 'create*'? It looks like it is only for use by client code
Otherwise, looks good to me.
> 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-changes-patch.txt, 1066-external.patch, 1066.txt, 1066.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.
[jira] Commented: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869279#action_12869279 ]
Jeremy Hanna commented on CASSANDRA-1066:
-----------------------------------------
Based on conversations in IRC with Gary, Jonathan, and Stu, we'll genericize the arguments to the KSMetaData constructor into a Map so that we can add the configuration options for the DatacenterShardStrategy there.
> 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
>
>
> 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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894378#action_12894378 ]
Hudson commented on CASSANDRA-1066:
-----------------------------------
Integrated in Cassandra #506 (See [http://hudson.zones.apache.org/hudson/job/Cassandra/506/])
update {CHANGES,NEWS}.txt
Patch by eevans for CASSANDRA-1066
datacenter.properties no longer neeeded
Patch by eevans for CASSANDRA-1066
regenerated thrift code
Patch by eevans for CASSANDRA-1066
configurable options for replication strategies
Patch by Jeremy Hanna; review by eevans for CASSANDRA-1066
> 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 beta 1
>
> Attachments: 1066-3.txt, 1066-4.txt, 1066-5.txt, 1066-changes-patch.txt, 1066-external.patch, 1066-update.txt, 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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: 1066.txt
Still having some issues with a couple of unit tests, but posting the current changes.
> 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-changes-patch.txt, 1066.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: 1066-changes-patch.txt
rebased with trunk.
> 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: 1066-changes-patch.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: 1066-4.txt
Rebased with current trunk.
> 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-4.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: 1066.txt
> 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-changes-patch.txt, 1066.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: 1066-update.txt
As 1291 is being reverted, I am posting the changes to trunk previous to 1291, not the entire patch.
> 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-4.txt, 1066-5.txt, 1066-changes-patch.txt, 1066-external.patch, 1066-update.txt, 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.
[jira] Issue Comment Edited: (CASSANDRA-1066)
DatacenterShardStrategy needs enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892392#action_12892392 ]
Jeremy Hanna edited comment on CASSANDRA-1066 at 7/26/10 2:00 PM:
------------------------------------------------------------------
There was some discussion on whether the replication strategy should be part of the keyspace metadata. I'll try to distill my thoughts on why I think it should in here.
Problem:
Currently the DatacenterShardStrategy uses configuration options found in a properties file. Work has been done to reload this automatically. However, what happens when 0.7 adds the ability to create keyspaces dynamically? A client can't just add a keyspace with DSS. They would first have to update their DSS configuration file to include settings for the new keyspace. Then they would refresh that configuration and create their keyspace. That's pretty onerous for a client to have to do.
Also currently, the replication strategies are separate from the keyspace metadata, even though there is a 1:1 relationship between KSM and the replication strategy. That results in various utility methods and special casing in StorageService and DatabaseDescriptor to handle these separate quasi singleton replication strategies. For example, the special cases to init and clean replication strategies when setting and clearing table definitions in DatabaseDescriptor. In the past we've done it this way because it's worked and because there was no configuration for a strategy. Now there is - DSS configuration.
Solution:
I proposed making RS an instance variable of KSM. It would do in a more direct way what we had previously been doing in a round about way - maintaining their 1:1 relationship more cleanly. It's been said that the KSM should only contain only storage data. Currently we already store the replication strategy class. The configuration options are the only thing that would be added in this scenario. When serializing and deserializing, we just store the keyspace name, class name, and configuration options (Map<String,String>). This is immutable data. The TokenMetadata and Snitch are just references to the current TM and Snitch. Every time a KSM is deserialized, it just gets the current TM and Snitch along with the other info to create a new RS instance.
Alternatives?
Are there any alternatives to doing it this way? We could possibly extend what we're doing with the external model for replication strategies so that they would include state. That would make them external to the KSM but be specific for each KSM (removing the quasi-singleton behavior). That would be less of a change, but seems more hackish to me.
I would be welcome to other alternatives. I just think a dynamic/automate-able way to create keyspaces shouldn't need to be handled specially for those using the DSS in 0.7.
was (Author: jeromatron):
There was some discussion on whether the replication strategy should be part of the keyspace metadata. I'll try to distill my thoughts on why I think it should in here.
Problem:
Currently the DatacenterShardStrategy uses configuration options found in a properties file. Work has been done to reload this automatically. However, what happens when 0.7 adds dynamic keyspaces? A client can't just add a keyspace with DSS. They would first have to update their DSS configuration file to include settings for the new keyspace. Then they would refresh that configuration and create their keyspace. That's pretty onerous for a client to have to do.
Also currently, the replication strategies are separate from the keyspace metadata, even though there is a 1:1 relationship between KSM and the replication strategy. That results in various utility methods and special casing in StorageService and DatabaseDescriptor to handle these separate quasi singleton replication strategies. For example, the special cases to init and clean replication strategies when setting and clearing table definitions in DatabaseDescriptor. In the past we've done it this way because it's worked and because there was no state for a strategy. Now there is - DSS configuration.
Solution:
I proposed making RS an instance variable of KSM. It would do in a more direct way what we had previously been doing in a round about way - maintaining their 1:1 relationship more cleanly. It's been said that the KSM should only contain only storage data. Currently we already store the replication strategy class. The configuration options are the only thing that would be added in this scenario. When serializing and deserializing, we just store the keyspace name, class name, and configuration options (Map<String,String>). This is immutable data. The TokenMetadata and Snitch are just references to the current TM and Snitch. Every time a KSM is deserialized, it just gets the current TM and Snitch along with the other info to create a new RS instance.
Alternatives?
Are there any alternatives to doing it this way? We could possibly extend what we're doing with the external model for replication strategies so that they would include state. That would make them external to the KSM but be specific for each KSM (removing the quasi-singleton behavior). That would be less of a change, but seems more hackish to me.
I would be welcome to other alternatives. I just think a dynamic/automate-able way to create keyspaces shouldn't need to be handled specially for those using the DSS in 0.7.
> 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-changes-patch.txt, 1066.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: 1066-5.txt
Had to rebase again because of CASSANDRA-1291 getting committed, but only a couple of minor changes.
Updated __init__.py and test_thrift_server.py to fix the system tests.
Updated KSMetaData.deflate to check null for strategyOptions instead of ks.strategy_options.
Updated DatabaseDescriptor to actually use keyspace.strategy_options in readTablesFromYaml.
Will create a separate ticket for the CLI updates.
> 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-4.txt, 1066-5.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.
[jira] Commented: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892392#action_12892392 ]
Jeremy Hanna commented on CASSANDRA-1066:
-----------------------------------------
There was some discussion on whether the replication strategy should be part of the keyspace metadata. I'll try to distill my thoughts on why I think it should in here.
Problem:
Currently the DatacenterShardStrategy uses configuration options found in a properties file. Work has been done to reload this automatically. However, what happens when 0.7 adds dynamic keyspaces? A client can't just add a keyspace with DSS. They would first have to update their DSS configuration file to include settings for the new keyspace. Then they would refresh that configuration and create their keyspace. That's pretty onerous for a client to have to do.
Also currently, the replication strategies are separate from the keyspace metadata, even though there is a 1:1 relationship between KSM and the replication strategy. That results in various utility methods and special casing in StorageService and DatabaseDescriptor to handle these separate quasi singleton replication strategies. For example, the special cases to init and clean replication strategies when setting and clearing table definitions in DatabaseDescriptor. In the past we've done it this way because it's worked and because there was no state for a strategy. Now there is - DSS configuration.
Solution:
I proposed making RS an instance variable of KSM. It would do in a more direct way what we had previously been doing in a round about way - maintaining their 1:1 relationship more cleanly. It's been said that the KSM should only contain only storage data. Currently we already store the replication strategy class. The configuration options are the only thing that would be added in this scenario. When serializing and deserializing, we just store the keyspace name, class name, and configuration options (Map<String,String>). This is immutable data. The TokenMetadata and Snitch are just references to the current TM and Snitch. Every time a KSM is deserialized, it just gets the current TM and Snitch along with the other info to create a new RS instance.
Alternatives?
Are there any alternatives to doing it this way? We could possibly extend what we're doing with the external model for replication strategies so that they would include state. That would make them external to the KSM but be specific for each KSM (removing the quasi-singleton behavior). That would be less of a change, but seems more hackish to me.
I would be welcome to other alternatives. I just think a dynamic/automate-able way to create keyspaces shouldn't need to be handled specially for those using the DSS in 0.7.
> 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-changes-patch.txt, 1066.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hanna updated CASSANDRA-1066:
------------------------------------
Attachment: 1066.txt
rebasing after CASSANDRA-1237 changes
> 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-changes-patch.txt, 1066-external.patch, 1066.txt, 1066.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.
[jira] Updated: (CASSANDRA-1066) DatacenterShardStrategy needs
enforceable and keyspace based RF
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1066:
--------------------------------------
Fix Version/s: 0.7
Affects Version/s: (was: 0.7)
Component/s: Core
> 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
>
>
> 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.