cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Lynch (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-14303) NetworkTopologyStrategy could have a "default replication" option
Date Sat, 07 Apr 2018 01:25:00 GMT

    [ 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message