Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 29 Aug 2017 10:46:03 +0000 (UTC)
From: "Aleksey Yeschenko (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13097875.1503897904000.145172.1504003563246@Atlassian.JIRA>
In-Reply-To: <JIRA.13097875.1503897904000@Atlassian.JIRA>
References: <JIRA.13097875.1503897904000@Atlassian.JIRA> <JIRA.13097875.1503897904156@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-13812) Missing system keyspace tables
 are not created
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 29 Aug 2017 10:46:12 -0000


    [ 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