[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215774#comment-13215774 ]
Brandon Williams commented on CASSANDRA-3706: --------------------------------------------- bq. As Jonathan points out, it makes no sense to save this information in the system keyspace then, as the point of this storage is for easing disaster recovery, and if the node goes down, the yaml as depicted in the keyspace is no more likely to survive than the yaml file in the conf directory. If this feature is to have value at all, it must be replicated, so a secondary quasi-system keyspace that is replicated would be needed. I'm not convinced this is necessarily true. If each node only stores its own config and you backup a snapshot of the node, you can restore it. If all data is lost and you have nothing to restore from, another node having a copy of the dead node's config is hardly useful; configs only diverge by initial_token in practice, and copying the config files directly from another node and changing the initial_token is more practical than extracting the files from a CF and then copying them (there is no way for the 'restored' node to do this automatically without a config to start with.) > Back up configuration files on startup > -------------------------------------- > > Key: CASSANDRA-3706 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3706 > Project: Cassandra > Issue Type: New Feature > Components: Tools > Reporter: Jonathan Ellis > Assignee: Dave Brosius > Priority: Minor > Labels: lhf > Fix For: 1.1.1 > > Attachments: save_configuration.diff, save_configuration_2.diff, > save_configuration_3.diff, save_configuration_4.diff, > save_configuration_6.diff, save_configuration_7.diff > > > Snapshot can backup user data, but it's also nice to be able to have > known-good configurations saved as well in case of accidental snafus or even > catastrophic loss of a cluster. If we check for changes to cassandra.yaml, > cassandra-env.sh, and maybe log4j-server.properties on startup, we can back > them up to a columnfamily that can then be handled by normal snapshot/backup > procedures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira