[
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 12/5/18 7:04 PM:
-------------------------------------------------------------------
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};
ALTER KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy'}
{noformat}
||trunk||
|[12aa4543|https://github.com/apache/cassandra/commit/12aa45434a6d5913a2a3db91a26a8d2f7081042a]|
|[!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. I have also added the CHANGES and
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};
ALTER KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy'}
{noformat}
||trunk||
|[6849e7a3|https://github.com/apache/cassandra/commit/6849e7a3394be758e6ed3b47cf60b91fe41ffbd5]|
|[!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.
> Auto-expand replication_factor 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: [email protected]
For additional commands, e-mail: [email protected]
