cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Brosius (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CASSANDRA-3706) Back up configuration files on startup
Date Sat, 21 Jan 2012 02:24:39 GMT

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

Dave Brosius edited comment on CASSANDRA-3706 at 1/21/12 2:24 AM:
------------------------------------------------------------------

Ah, the fact that system was local-only had escaped me, this makes your original comments
(brandon) make alot more sense to me.

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 :)

As for an IP being a poor choice for key, I agree it's sub-optimal, however it was used to
ensure uniqueness, and have some tie back to the original machine (albeit not absolute). The
only other choice I could think of is an added field in the yaml file such as cluster-node-id
that had to be set by the administrator, but then we need to rely on the administrator to
choose a unique one which is far less likely. To enforce this uniqueness that id would need
to be added to the gossip protocol, and nodes need to be rejected with conflicting unique
ids. All of that seems like overkill. While IPs seem problematic, I don't know how problematic
they really are in practice. While these cluster nodes use gossip for communication, I still
would wonder whether the standard deployment would use dhcp for these machines, as they still
would need to be administered remotely. Thus for static ips, the changing ip problem wouldn't
be one. But perhaps i'm talking out my ear.

Let me know what you want to do, and i'll be glad to go forward, or cancel whatever is appropriate.

                
      was (Author: dbrosius@apache.org):
    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

        

Mime
View raw message