Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 25 Oct 2012 10:49:23 +0000 (UTC)
From: "Brandon Williams (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <172624619.26937.1351162163857.JavaMail.jiratomcat@arcas>
In-Reply-To: <1591717607.2918.1350679212438.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (CASSANDRA-4839) Online toggle for node
 write-only status
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-4839?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
13484040#comment-13484040 ]=20

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

bq. I think it would be something like wait N seconds on boot to receive hi=
nts, and then wait until any in-progress hint deliveries finished or timed =
out before taking reads. It doesn't have to be perfect, but would significa=
ntly increase the consistency of CL.ONE reads during reboots, which along w=
ith the other tickets that cover faster table loading, would promote more p=
roductive restarts =E2=80=93 think tuning and minor upgrades for both C* an=
d the JVM.

That sounds like a reasonable solution if it's configurable.

bq. Either way, I think that automatically doing that would be great but is=
n't coupled to the original idea. Just getting the ability to do this from =
JMX would be great.

I actually like your first idea better than a JMX method that does spooky t=
hings :)
               =20
> 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 n=
ode, while still allowing write operations to take place. This would be sim=
ilar 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 ha=
ve 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 p=
revent any inconsistency from the scenario above, it seems ridiculous to al=
ways incur the cost to cover the 0.1% case.
> In addition, it would open up the ability for a node to (optionally) auto=
matically "go dark" for reads while it's receiving hints after joining the =
cluster or perhaps during repair. These obviously have their own complicati=
ons and justify separate tickets.

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