You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Joseph Lynch (JIRA)" <ji...@apache.org> on 2018/11/27 00:07:00 UTC

[jira] [Comment Edited] (CASSANDRA-14303) Default datacenter replication for NetworkTopologyStrategy

    [ https://issues.apache.org/jira/browse/CASSANDRA-14303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699443#comment-16699443 ] 

Joseph Lynch edited comment on CASSANDRA-14303 at 11/27/18 12:06 AM:
---------------------------------------------------------------------

Ok I rebased and merged in your offline suggestion to re-use {{replication_factor}} as well as updating it to (I believe) support transient replication. I've made sure to update the documentation as well indicating the change in behavior.

An interesting side effect of re-using {{replication_factor}} is now we can do cool things like altering a {{SimpleStrategy}} directly to a {{NetworkTopologyStrategy}} while using the old RF, e.g. this now does the right thing:
{noformat}
CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3};
 CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy'}
{noformat}
||trunk||
|[96c8d6df|https://github.com/apache/cassandra/commit/96c8d6df9082ac47b6aca655425a8522ae9459ff]|
|[!https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14303.png?circle-token= 1102a59698d04899ec971dd36e925928f7b521f5!|https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14303]|

Dtests are running in the linked circleci. When you're happy please let me know and I will add the CHANGES/NEWS entries.


was (Author: jolynch):
Ok I rebased and merged in your offline suggestion to re-use {{replication_factor}} as well as updating it to (I believe) support transient replication. I've made sure to update the documentation as well indicating the change in behavior.

An interesting side effect of re-using {{replication_factor}} is now we can do cool things like altering a {{SimpleStrategy}} directly to a {{NetworkTopologyStrategy}} while using the old RF, e.g. this now does the right thing:
{noformat}
CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3};
 CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 'replication_factor': 3};
{noformat}
||trunk||
|[96c8d6df|https://github.com/apache/cassandra/commit/96c8d6df9082ac47b6aca655425a8522ae9459ff]|
|[!https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14303.png?circle-token= 1102a59698d04899ec971dd36e925928f7b521f5!|https://circleci.com/gh/jolynch/cassandra/tree/CASSANDRA-14303]|

Dtests are running in the linked circleci. When you're happy please let me know and I will add the CHANGES/NEWS entries.

> Default datacenter replication for NetworkTopologyStrategy
> ----------------------------------------------------------
>
>                 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
>              Labels: 4.0-feature-freeze-review-requested
>             Fix For: 4.x
>
>
> 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