[
https://issues.apache.org/jira/browse/CASSANDRA-14303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16429187#comment-16429187
]
Joseph Lynch edited comment on CASSANDRA-14303 at 4/7/18 1:24 AM:
------------------------------------------------------------------
||trunk||
|[patch|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-14303#diff-25adf5676f157a803428726a4e55a8e8]|
|[docs|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-14303#diff-911d9ab4d38f8f4be9752d968d414a26]|
|[unit
tests|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-14303#diff-874be227a5ab21298d6a11c7d1f6ce2eR240]
[!https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14303.png?circle-token=
1102a59698d04899ec971dd36e925928f7b521f5!|https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14303]|
I ended up putting the expansion in {{ReplicationParams}} because after that
the params appear entirely immutable to the strategies themselves. I think this
is cleaner than having the map be mutable and allowing the replication
strategies to manipulate the replication options, but I might be able to
refactor it so that ARS can call like a static method or something on the
passed class?
Currently the parameter is called {{default_datacenter_replication}} instead of
re-using {{replication_factor}} because of where I ended up putting the
auto-expansion to get around the immutability, but that might not be the best.
was (Author: jolynch):
||trunk||
|[patch|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-14303#diff-25adf5676f157a803428726a4e55a8e8]|
|[docs|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-14303#diff-911d9ab4d38f8f4be9752d968d414a26]|
|[unit
tests|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-14303#diff-874be227a5ab21298d6a11c7d1f6ce2eR240]
[!https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14303.png?circle-token=
1102a59698d04899ec971dd36e925928f7b521f5!|https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14303]|
I ended up putting the expansion in {{ReplicationParams}} because after that
the params appear entirely immutable to the strategies themselves. I think this
is cleaner than having the map be mutable and allowing the replication
strategies to manipulate the replication options, but I might be able to
refactor it so that ARS can call like a static method or something on the
passed class?
> NetworkTopologyStrategy could have a "default replication" option
> -----------------------------------------------------------------
>
> Key: CASSANDRA-14303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14303
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
> Reporter: Joseph Lynch
> Assignee: Joseph Lynch
> Priority: Minor
> Fix For: 4.0
>
>
> Right now when creating a keyspace with {{NetworkTopologyStrategy}} the user
> has to manually specify the datacenters they want their data replicated to
> with parameters, e.g.:
> {noformat}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': 3, 'dc2': 3}{noformat}
> This is a poor user interface because it requires the creator of the keyspace
> (typically a developer) to know the layout of the Cassandra cluster (which
> may or may not be controlled by them). Also, at least in my experience, folks
> typo the datacenters _all_ the time. To work around this I see a number of
> users creating automation around this where the automation describes the
> Cassandra cluster and automatically expands out to all the dcs that Cassandra
> knows about. Why can't Cassandra just do this for us, re-using the previously
> forbidden {{replication_factor}} option (for backwards compatibility):
> {noformat}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'replication_factor': 3}{noformat}
> This would automatically replicate this Keyspace to all datacenters that are
> present in the cluster. If you need to _override_ the default you could
> supply a datacenter name, e.g.:
> {noformat}
> > CREATE KEYSPACE test WITH replication = {'class':
> > 'NetworkTopologyStrategy', 'replication_factor': 3, 'dc1': 2}
> > DESCRIBE KEYSPACE test
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': '2', 'dc2': 3} AND durable_writes = true;
> {noformat}
> On the implementation side I think this may be reasonably straightforward to
> do an auto-expansion at the time of keyspace creation (or alter), where the
> above would automatically expand to list out the datacenters. We could allow
> this to be recomputed whenever an AlterKeyspaceStatement runs so that to add
> datacenters you would just run:
> {noformat}
> ALTER KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'replication_factor': 3}{noformat}
> and this would check that if the dc's in the current schema are different you
> add in the new ones (_for safety reasons we'd never remove non explicitly
> supplied zero dcs when auto-generating dcs_). Removing a datacenter becomes
> an alter that includes an override for the dc you want to remove (or of
> course you can always not use the auto-expansion and just use the old way):
> {noformat}
> // Tell it explicitly not to replicate to dc2
> > ALTER KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> > 'replication_factor': 3, 'dc2': 0}
> > DESCRIBE KEYSPACE test
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': '3'} AND durable_writes = true;{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
