[jira] [Commented] (CASSANDRA-4839) Online toggle for node write-only status

["Brandon Williams (JIRA)" <ji...@apache.org>]

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

Brandon Williams commented on CASSANDRA-4839:
---------------------------------------------

It's not a total solution, but one way we can optimize this is to set the SEVERITY gossip state (in 1.2) very high at startup or when receiving hints and then lower it later so that the dynamic snitch won't ever prefer the node.
                
> Online toggle for node write-only status
> ----------------------------------------
>
>                 Key: CASSANDRA-4839
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4839
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Rick Branson
>            Priority: Minor
>
> It would be really great if users could disable/enable reads on a given node, while still allowing write operations to take place. This would be similar to how we enable/disable thrift and gossip using JMX.
> The scenario for using this is that often a node needs to be brought down for maintenance for a few minutes, and while the node is catching up from hints, which can take 10-30 minutes depending on write load, it will serve stale data. Do the math for a rolling restart of a large cluster and you have potential windows of hours or days where a large amount of inconsistency is surfacing.
> Avoiding this large time gap of inconsistency during regular maintenance alleviates concerns about inconsistent data surfaced to users during normal, planned activities. While a read consistency >ONE can indeed be used to prevent any inconsistency from the scenario above, it seems ridiculous to always incur the cost to cover the 0.1% case.
> In addition, it would open up the ability for a node to (optionally) automatically "go dark" for reads while it's receiving hints after joining the cluster or perhaps during repair. These obviously have their own complications and justify separate tickets.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira