[
https://issues.apache.org/jira/browse/CASSANDRA-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087881#comment-13087881
]
Peter Schuller commented on CASSANDRA-2568:
-------------------------------------------
As was just discussed on cassandra-user, another useful application of this
would be to allow easier "re-creation" of an existing node without
re-bootstrapping with a different IP address, by starting a node without data
and having it enter the cluster in write-only mode, followed by initiating a
repair. Turn read/write when repairs complete.
After a disk/raid failure, it should make the operative burden significantly
less. For some changing IP:s willy nilly may be simple, but for many it is
likely a significant concern.
> Write only mode
> ---------------
>
> Key: CASSANDRA-2568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2568
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Chris Burroughs
> Priority: Minor
>
> Allow a node to receive writes (which are relatively cheap) but not reads
> (random io). The purpose is to allow a major compaction or repair to be run
> on a node that is under too much load for this be safely done "live".
> Marking a node as down by disabling gossip is good enough in some cases(for
> major compaction). But for repairs is insufficient, since hints will build
> back up once I repeat the process on the next node.
> This is presumably a rather complicated change in to gossip to accommodate
> the new state. I am also concerned of the effects of having different
> numbers of nodes available for write and read quorums.
> See also: http://www.mail-archive.com/[email protected]/msg02240.html
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
