[
https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16197996#comment-16197996
]
Kurt Greaves commented on CASSANDRA-13813:
------------------------------------------
I think if we can't provide a data model for our tables that works for all
scenarios then we need to allow operators to make changes. I've had quite a few
occasions where modifying "system" tables was necessary, and I'm sure more
tables will be introduced that don't work in all scenarios in the future.
While there is the workaround of just inserting into the system_schema tables
that is fraught with peril, and far more likely for them to do something that
breaks things. I can't see someone saying "woops I accidentally DROPped/ALTERed
a random column in system_distributed.view_build_status", but I can definitely
see someone trying to insert into system_schema.tables and making mistakes. As
soon as we make them replicated we hand over some responsibility to the
operator to manage them (not that the non-replicated keyspaces have a history
of being perfect though), and I'd expect to be able to change table properties
that potentially affect the cluster.
Cassandra already requires you to know what your doing as an operator, this
really doesn't increase that expectation. There are a million other bad choices
you could make when managing a cluster that would be far more catastrophic (and
far more likely). I would like to move away from that, but a lot of that sort
of thing requires major changes to fix. As in this case it seems we'll need the
capability limitation framework or other major changes to make a reasonable
compromise.
> 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: [email protected]
For additional commands, e-mail: [email protected]
