cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Greaves (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
Date Tue, 10 Oct 2017 01:24:00 GMT

    [ 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message