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

Brandon Williams commented on CASSANDRA-3706:
---------------------------------------------

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

The system keyspace isn't replicated, though, and if we did store them all, IP 
would still be a bad choice.  Since there's really no point in having every 
machine's config stored on every machine, a static key name seems fine.

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

I don't think a config will ever see so much churn this becomes an issue (in 
other words, we don't delete old configs, we just check that a column exists 
for the current digest and move on.)  If somehow it does, this is where a 
static key can be handy, because opening up the cli and deleting 
LocationInfo['CONFIG'] is pretty simple.
                
> 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

        

Reply via email to