[
https://issues.apache.org/jira/browse/CASSANDRA-14303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713794#comment-16713794
]
Jeff Jirsa edited comment on CASSANDRA-14303 at 12/8/18 10:36 PM:
------------------------------------------------------------------
I think you may be right. I can't think of a better option. The only real safe
way to do this is far more involved, given our current state. Given rf=3, a
user doesn't have to do rf=3 in each dc, user could do rf=2 in each dc, then
increase slowly interleaving repairs to go from rf=(2,2) to rf=(3,3). That
still violates consistency (until you run the first repair), but not by as
much. No normal user is going to get that nuance, though (I suspect going to
2/2 is going to be safe most of the time with statically assigned tokens that
interleave dcs, but may not be true with vnodes). We really need a migration
step/process that's in the db so we dont have to rely on users knowing how to
do this safely.
was (Author: jjirsa):
I think you may be right. I can't think of a better option. The only real safe
way to do this is far more involved, given our current state. Given rf=3, a
user doesn't have to do rf=3 in each dc, user could do rf=2 in each dc, then
increase slowly interleaving repairs to go from rf=(2,2) to rf=(3,3). No normal
user is going to get that nuance, though (I suspect going to 2/2 is going to be
safe most of the time with statically assigned tokens that interleave dcs, but
may not be true with vnodes). We really need a migration step/process that's in
the db so we dont have to rely on users knowing how to do this safely.
> 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]
