cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13812) Missing system keyspace tables are not created
Date Tue, 29 Aug 2017 10:46:03 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145097#comment-16145097
] 

Aleksey Yeschenko commented on CASSANDRA-13812:
-----------------------------------------------

[~slebresne] The purpose of hardcoding a minimal timestamp value there is to avoid mismatches
from automated creation, but still allow custom updates (to keyspace RF for example). When
we do update them in Core, we'd bump the timestamp too so that the new default would override
the old default, but still not affect the overrides by the user - if any. FWIW we've been
doing it like this since forever, not just CASSANDRA-13441, just not consistently everywhere.
If I recall correctly, so does DSE. Now, this may or may not work as intended, but that was
the intention.

As for dropping those tables - no, it should absolutely not be allowed.

bq. But as said above, even outside that particular case, CASSANDRA-13441 means (unless I'm
missing something) that we cannot ever do any update to a system_distributed table (we can
add stuffs, but we can't update) and that doesn't feel ideal to me.

It's already been the case for tables themselves before 13441, I think. Just not for KS metadata.
So far we've been lucky to not require any incompatible changes.

Overall, I think we should not allow user modifications to our distributed system tables (auth,
tracing, system_distributed). So long as that is true, we can hardcode a timestamp as a generation,
and bump it every time we make a change. But we should allow altering the keyspace itself
by the user - at the very least to allow changing RF. I think it's still fine to hard code
a timestamp there - user's changes will always win, and for keyspaces this is what we want
- given that the only two params we have on keyspaces are RF and durable_writes.

> Missing system keyspace tables are not created
> ----------------------------------------------
>
>                 Key: CASSANDRA-13812
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13812
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Distributed Metadata
>            Reporter: ZhaoYang
>
> Auth/Trace/Distributed Keyspaces or Tables dropped are not created on startup although
a log message {{MigrationManager.java:220 - Create new table: TableMetadata...}} appears.
> Steps to reproduce:
> # Start node
> # {{DROP TABLE system_distributed.view_build_status;}}
> # {{DROP TABLE system_distributed.repair_history;}}
> # Stop node
> # Start node
> # Tables are *not* created, but log messages appear
> Cause:
> System's keyspaces or tables are created with timestamp 0 in CASSANDRA-13441



--
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