[
https://issues.apache.org/jira/browse/CASSANDRA-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039277#comment-14039277
]
Robert Stupp commented on CASSANDRA-7370:
-----------------------------------------
OK - the table should reflect configuration changes if for example someone
changes the compaction throughput. From a quick view I see that
{{DatabaseDescriptor}} performs updates in {{Config}} - is
{{DatabaseDescriptor}} the only "immediate source" where Config is modified or
would it be better to search for all accessors of the fields in Config?
If the stuff intended by this issue should be complete, it would make sense to
also add the fields of {{DatabaseDescriptor}} (or put them into a separate
table).
But I do not know if the {{system}} keyspace is a good place for these "view
config" tables due to its 'LocalStratecy'. If an admin wants to view the
configuration, he issues the query against 'any' node and does not want to
explicitly connect to that node. So maybe 'system_traces' if not even a
completely new KS should be used. But this has no direct influence to the
implementation.
Using persistent tables has the benefit that anyone can track configuration
changes of any node - whereas JMX only shows the current status of a particular
node.
Such a KS could also be used to log really important status changes like "node
bootstrapped", "node startup", "node shutdown".
It should however not be a storage for metrics or log data in general (high
write rates).
But in any way it must be clear, that such tables are "read only" - not
something that "magically" changes system config via DML. This should be, if
requested and required, done by "special CQL statements". I'll open a separate
ticket not to lose the idea of "nodetool set config foo=bar" or "ALTER SYSTEM
SET CONFIG foo=bar".
> Create a new system table "node_config" to load cassandra.yaml config data.
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-7370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7370
> Project: Cassandra
> Issue Type: Wish
> Components: Config
> Reporter: Hayato Shimizu
> Priority: Minor
> Labels: ponies
>
> Currently the node configuration information specified in cassandra.yaml can
> only be viewed via JMX or by looking at the file on individual machines.
> As an administrator, it would be extremely useful to be able to execute
> queries like the following example;
> select concurrent_reads from system.node_config;
> which will list all the concurrent_reads value from all of the nodes in a
> cluster.
> This will require a new table in the system keyspace and the data to be
> loaded (if required) during the bootstrap, and updated when MBeans attribute
> value updates are performed. The data from other nodes in the cluster is also
> required in the table.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
