[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420738#comment-13420738 ] Jonathan Ellis commented on CASSANDRA-3706: --- I'd just go ahead and build the generic distributed system keyspace in 1123 and we'll rebase this on top. > 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.2 > > Attachments: save_configuration.diff, save_configuration_2.diff, > save_configuration_3.diff, save_configuration_4.diff, > save_configuration_6.diff, save_configuration_7.diff, > save_configuration_8.diff, save_configuration_9.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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420729#comment-13420729 ] David Alves commented on CASSANDRA-3706: How far is this from going in? Any thing I can do to help? CASSANDRA-1123 will also need distributed system tables and I'd like to minimize duplicate code. I can split the patch into generic dist system tables and specific configuration backup + rebase and use the common part in 1123. wdyt? > 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.2 > > Attachments: save_configuration.diff, save_configuration_2.diff, > save_configuration_3.diff, save_configuration_4.diff, > save_configuration_6.diff, save_configuration_7.diff, > save_configuration_8.diff, save_configuration_9.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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273680#comment-13273680 ] Jonathan Ellis commented on CASSANDRA-3706: --- bq. let me see if i can get CASSANDRA-4018 done today... would be nice to build on that I was thinking in terms of using a composite column to keep multiple versions around, but re-thinking that, if people want multiple versions they should be responsible for snapshot + backup themselves. So, never mind. :) > 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, > save_configuration_8.diff, save_configuration_9.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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273362#comment-13273362 ] Jonathan Ellis commented on CASSANDRA-3706: --- let me see if i can get CASSANDRA-4018 done today... would be nice to build on that > 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, > save_configuration_8.diff, save_configuration_9.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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[
https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273355#comment-13273355
]
Brandon Williams commented on CASSANDRA-3706:
-
I'm getting the following exception upon modifying a config and restarting:
{noformat}
INFO 15:26:57,770 Opening
/var/lib/cassandra/data/system_configuration/Configuration/system_configuration-Configuration-ia-1
(23286 bytes)
ERROR 15:26:57,788 Exception encountered during startup
java.lang.AssertionError
at
org.apache.cassandra.db.SystemTable.getCurrentLocalNodeId(SystemTable.java:582)
at
org.apache.cassandra.utils.NodeId$LocalNodeIdHistory.(NodeId.java:194)
at org.apache.cassandra.utils.NodeId$LocalIds.(NodeId.java:42)
at org.apache.cassandra.utils.NodeId.localIds(NodeId.java:49)
at org.apache.cassandra.utils.NodeId.getLocalId(NodeId.java:54)
at
org.apache.cassandra.db.SystemTable.saveConfiguration(SystemTable.java:340)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:184)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:355)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:105)
java.lang.AssertionError
at
org.apache.cassandra.db.SystemTable.getCurrentLocalNodeId(SystemTable.java:582)
at
org.apache.cassandra.utils.NodeId$LocalNodeIdHistory.(NodeId.java:194)
at org.apache.cassandra.utils.NodeId$LocalIds.(NodeId.java:42)
at org.apache.cassandra.utils.NodeId.localIds(NodeId.java:49)
at org.apache.cassandra.utils.NodeId.getLocalId(NodeId.java:54)
at
org.apache.cassandra.db.SystemTable.saveConfiguration(SystemTable.java:340)
at
org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:184)
at
org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:355)
at
org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:105)
Exception encountered during startup: null
{noformat}
Also, it would be nice to log at INFO when a new config is being saved.
> 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,
> save_configuration_8.diff, save_configuration_9.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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272695#comment-13272695 ] Jonathan Ellis commented on CASSANDRA-3706: --- another vote for 1.2 > 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, > save_configuration_8.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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272685#comment-13272685 ] Brandon Williams commented on CASSANDRA-3706: - If we're going to push this to 1.2 (since your patch is against trunk) then using the new node id instead of the broadcast address would be nice, otherwise can you rebase to 1.1? Between the two, I think I'd rather put this in 1.2, since node id seems like the optimal way to do this, as changing all the IPs in a cluster is actually not all that uncommon. > 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, > save_configuration_8.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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271591#comment-13271591 ] Jonathan Ellis commented on CASSANDRA-3706: --- you can compare the raw text just as easily as the digest... it's a bit more cpu, but still negilible, and same amount of code. don't think it's worth the trouble to create an option to disable, if you don't need it just ignore it. > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271587#comment-13271587 ] Brandon Williams commented on CASSANDRA-3706: - bq. i may be biased by the fact that i constant start and stop instances for debugging An option to disable this would be nice, as personally I would never use it. > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271586#comment-13271586 ] Brandon Williams commented on CASSANDRA-3706: - bq. could this use our new-fangled gossip node id instead of the ip? For 1.2, that would be best, but complicates backward-compatibility if we put this in 1.1 > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271583#comment-13271583 ] Dave Brosius commented on CASSANDRA-3706: - currently the rows are keyed by ip address, and have columns YAMLDIGEST, YAMLCONTENTS, LOG4JDIGEST, LOG4JCONTENTS, ENVDIGEST, ENVCONTENTS the digest columns are so you don't constantly write duplicate 'blobs' into the database if nothing has changed. perhaps that's not much of a concern and i may be biased by the fact that i constant start and stop instances for debugging. In any case, i can change it to whatever you like. > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[
https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271567#comment-13271567
]
Jonathan Ellis commented on CASSANDRA-3706:
---
Okay, let me spell it out a bit more:
{code}
last_yaml = None
for yaml in query("select yaml from backups"):
if last_yaml != None and yaml != last_yaml:
raise 'cluster yaml out of sync'
last_yaml = yaml
{code}
... that said, it would make sense to me to to use a data model like this:
{code}
CREATE TABLE config_backups (
peer inetaddress,
backed_up_at datetime,
cassandra_yaml text,
cassandra_env text,
PRIMARY KEY (peer, backed_up_at)
)
{code}
which would allow you to query history for a given node (at the cost of making
my example loop for "compare current versions" more complex, since CQL isn't
powerful enough to say "give me the most recent version for each node" --
although you could do that with Hive).
(could this use our new-fangled gossip node id instead of the ip?)
> 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271555#comment-13271555 ] Brandon Williams commented on CASSANDRA-3706: - Ok, well, the patch as-is has know of finding the last_yaml since columns are keyed by digest. > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271522#comment-13271522 ] Jonathan Ellis commented on CASSANDRA-3706: --- bq. I'm not sure what last_yaml is if we're storing by digest Why would we do that? Just store the file raw. Then you don't need FS access, is my point. bq. also we're backing up 3 different files, not just yaml, but that's not a big deal Yeah, I was kind of hoping the extrapolation would be obvious. :P > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271509#comment-13271509 ] Brandon Williams commented on CASSANDRA-3706: - Maybe I misunderstand what 'in sync' meant, but I'm not sure what last_yaml is if we're storing by digest (or why they'd every be the same, in that case.) (also we're backing up 3 different files, not just yaml, but that's not a big deal) > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271502#comment-13271502 ] Jonathan Ellis commented on CASSANDRA-3706: --- I don't follow, all I need is "for yaml in select yaml from backups: if yaml != last_yaml raise" > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271485#comment-13271485 ] Brandon Williams commented on CASSANDRA-3706: - bq. Vs just doing a seq scan on a normal, non-node-local config CF to grab them all at once. But you still need a mechanism (local file access to each node, etc) to see if they are in sync. > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266931#comment-13266931 ] Jonathan Ellis commented on CASSANDRA-3706: --- bq. If each node only stores its own config and you backup a snapshot of the node, you can restore it The reason I think this probably doesn't belong node-local is, using a standard replicated CF makes it trivial for any normal client to connect to the cluster and say, "show me the config for node X," or, "query all backed-up config files, and make sure they are in sync." The first, single-node query is only a little harder with node-local storage (you need to defeat your client's connection pool, and connect to the right node), but this second is much more difficult: first you need to load a list of cluster members somehow, then connect to each and query in turn. Vs just doing a seq scan on a normal, non-node-local config CF to grab them all at once. > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190758#comment-13190758 ] Jonathan Ellis commented on CASSANDRA-3706: --- bq. Especially if we're using it for "nice to have but not critical" data, I don't see a problem with going with SimpleStrategy/RF=1 and allowing admins to change that if they want. > 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, save_configuration_4.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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190612#comment-13190612 ] Dave Brosius commented on CASSANDRA-3706: - Would it be possible to create dynamic RF values based on live endpoints, that would work sort of similar to how consistency specifications work?, ie RFs ALL -> equal to the number of live endpoints QUORUM -> equal to more than have of the live endpoints, --perhaps other constants-- these constants could be mapped to negative value constants, i suppose, but would be calculated at the time they were needed, and not at startup. > 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, save_configuration_4.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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[
https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190275#comment-13190275
]
Brandon Williams commented on CASSANDRA-3706:
-
bq. We should probably add another ("cluster_system"?) that is reserved for
internal use but is replicated normally.
The wrinkle in this is something we've encountered before... what do we set the
RF to when we don't know how many nodes there will be?
> 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190272#comment-13190272 ] Dave Brosius commented on CASSANDRA-3706: - Ah, the fact that system was local-only had escaped me, this makes your original comments (brandon) make alot more sense. 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 planned to add support for the cassandra-env and log4j files as well, but wanted to get feed back first before proceeding with those as those files are not first class files in cassandra as the yaml file is, and thus marginally more tricky. Glad I did :) Let me know what you want to do, and i'll be glad to go forward, or cancel whatever is appropriate. > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[
https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190158#comment-13190158
]
Jonathan Ellis commented on CASSANDRA-3706:
---
system keyspace is local-only. We should probably add another
("cluster_system"?) that is reserved for internal use but is replicated
normally.
> 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190148#comment-13190148 ] Dave Brosius commented on CASSANDRA-3706: - 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190141#comment-13190141 ] Brandon Williams commented on CASSANDRA-3706: - This looks good, but a couple of things: using the IP address as the row key can make things a bit painful if the machine changes IPs. Is there any reason not to use a hardcoded, predictable key such as "CONFIG" or something similar? In a similar vein, a column for both the digest and the content seems like a bit much, couldn't we store the digest as the column name and the contents at the value? Finally, if we do use a static row key, an entire new CF for this seems like overkill, we could just stuff this into the STATUS_CF. > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190094#comment-13190094 ] Brandon Williams commented on CASSANDRA-3706: - Both git and patch say v2 is corrupt at line 184 and it does not apply. > 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 > > > 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
[jira] [Commented] (CASSANDRA-3706) Back up configuration files on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190064#comment-13190064 ] Brandon Williams commented on CASSANDRA-3706: - Can we do this without org.apache.hadoop.io.IOUtils? > 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 > > > 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
