[
https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205377#comment-16205377
]
Kurt Greaves commented on CASSANDRA-13813:
------------------------------------------
bq. I'm not sure what you are trying to mean by that.
Not sure how to make this clearer. If we can't provide a one-size-fits-all
solution for our system distributed tables, which we can't, we should allow for
them to be modified by operators. In CASSANDRA-12701 we can't set a TTL because
we can't pick a TTL that's appropriate for all use cases (or compaction
strategy for that matter). Users have to pick their own, thus we should allow
them to change these properties. So far it only may be that TTL is the one that
users need to change, but I'm sure there are potentially others, and I'm sure
there will be more in the future.
bq. First, it would be nice if you could be a bit more concrete on those time
where it was "necessary"
Sure, I've had to change TTL as per CASSANDRA-12701 multiple times. I've never
bothered changing compaction strategy but obviously that would be beneficial.
I've also had to set up jobs to routinely truncate system_traces. This may
sound absurd, but in environments where you don't necessarily have control over
clients, it is applicable. Being able to TTL on this keyspace would improve
things here.
I've also had to drop tables in system_distributed on occasion when for some
reason or another they got corrupt/different ID's across the cluster. This has
also occured for system_traces, but obviously had to delete manually from
system_schema.
Obviously also the usual system_auth changes, however so far that only relates
to modifying RF, but I'll note that we do require dropping tables in that
keyspace for conversion to role based access.
bq. this ticket is not about discussing whether we should allow ALTER on
system tables in general.
Yep, I was never talking about system tables in general, just the distributed
ones. I thought this would be obvious considering that's what the ticket was
about.
I think it's worth pointing out the following as well, because it's been raised
that having alterable system_distributed tables is a major defect.
This issue (and related ones) were raised by developers as "major" issues.
There appears to be no evidence so far that this issue has actually affected
users.
We're rushing to fix it because for some reason, all of a sudden, we've
determined that users breaking their own cluster by doing funny things is a
huge problem. This is odd to me, considering users routinely break their
clusters by running repairs, but I've never heard of anyone breaking their
cluster because they altered a system "distributed" keyspace.
There appears to be no evidence that you can really do catastrophic damage by
altering these tables. If we fixed the fact that they don't get recreated
automatically anymore I'm pretty sure any issues created by doing odd changes
on the tables (which is very unlikely) would easily be resolved by dropping the
tables and restarting a node. On that note, not sure if repair actually will
break if the history tables are broken, but as far as MV are concerned, they
keep working even if you truncate/drop the tables.
The suggested fix still leaves a workaround to make the changes we'd be
blocking here, and this is on purpose. This kind of implies that we're
perfectly OK with users making these changes. I mean, if this is an actual
issue surely we should also create a ticket "Don't let user insert garbage into
system_schema".
I'm really not convinced that this is such a major high priority issue that we
can't just put it off until 4 and fix it with something more reasonable like
the capability limitation framework, while maintaining the current behaviour.
> Don't let user drop (or generally break) tables in system_distributed
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-13813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13813
> Project: Cassandra
> Issue Type: Bug
> Components: Distributed Metadata
> Reporter: Sylvain Lebresne
> Assignee: Aleksey Yeschenko
> Fix For: 3.0.x, 3.11.x
>
>
> There is not currently no particular restrictions on schema modifications to
> tables of the {{system_distributed}} keyspace. This does mean you can drop
> those tables, or even alter them in wrong ways like dropping or renaming
> columns. All of which is guaranteed to break stuffs (that is, repair if you
> mess up with on of it's table, or MVs if you mess up with
> {{view_build_status}}).
> I'm pretty sure this was never intended and is an oversight of the condition
> on {{ALTERABLE_SYSTEM_KEYSPACES}} in
> [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397].
> That condition is such that any keyspace not listed in
> {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for
> {{system_distributed}}) has no specific restrictions whatsoever, while given
> the naming it's fair to assume the intention that exactly the opposite.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
