[jira] [Issue Comment Edited] (CASSANDRA-3706) Back up configuration files on startup

["Dave Brosius (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

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

Dave Brosius edited comment on CASSANDRA-3706 at 1/20/12 9:52 PM:
------------------------------------------------------------------

I was assuming that there would be n rows in this CF, one per cluster member, each with it's own yaml. This calls for a non hard coded key, unless you want to make n columns representing each machine.

As for the digest as the column name, when the yaml changes and you want to update the contents in the row, you would want to remove the old column, but you don't really know what the old column name is now. Perhaps you could just delete columns that you don't know what they are but that seems a little iffy to me.


                
      was (Author: dbrosius@apache.org):
    I was assuming that there would n rows in this CF, one per cluster member, each with it's own yaml. This calls for a non hard coded key, unless you want to make n columns for each machine.

As for the digest as the column name, when the yaml changes and you want to update the contents in the row, you would want to remove the old column, but you don't really know what the old column name is now. Perhaps you could just delete columns that you don't know what they are but that seems a little iffy to me.


                  
> 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
>
>         Attachments: save_configuration.diff, save_configuration_2.diff, save_configuration_3.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