cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
Date Fri, 20 Jan 2012 22:00:41 GMT

    [ 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

        

Mime
View raw message