You can accomplish this by manually tweaking the values in the dynamic snitch mbean so other nodes won’t select it for reads
-- Jeff Jirsa > On Oct 18, 2017, at 3:24 AM, Steinmaurer, Thomas > <thomas.steinmau...@dynatrace.com> wrote: > > Hi Nicolas, > > newly bootstrapping is not really an option, I think. > > I hoped there might be a mode (perhaps there is, but haven’t found it yet) > where a node might not actively participate in read requests but still > writing newly arriving data during a repair or whatever maintenance task one > thinks that some sort of write-only is appropriate. > > Thanks, > Thomas > > From: Nicolas Guyomar [mailto:nicolas.guyo...@gmail.com] > Sent: Mittwoch, 18. Oktober 2017 09:58 > To: user@cassandra.apache.org > Subject: Re: Not serving read requests while running nodetool repair > > Hi Thomas, > > AFAIK temporarily reading at LOCAL_QUORUM/QUORUM until nodetool repair is > finished is the way to go. You can still disable binary/thrift on the node to > "protect" it from acting as a coordinator, and complete its repair quietly, > but I'm not sure that would make such a huge difference in recovery time. > > If you disable gossip the node will be see as down, thus disabling repair if > I'm correct > > If repair is taking too much time, or switching to Read Quorum not feasible > within your application, is it OK for you to shutdown the node, wipe its data > and launch a repair on it at an appropriate time windows ? > > > > On 18 October 2017 at 08:04, Steinmaurer, Thomas > <thomas.steinmau...@dynatrace.com> wrote: > Hello, > > due to performance/latency reasons, we are currently reading and writing time > series data at consistency level ONE/ANY. > > In case of a node being down and recovering after the default hinted handoff > window of 3 hrs, we may potentially read stale data from the recovering node. > Of course, from an operational POV, we will trigger a nodetool repair after > the recovered node has start up, but to my understanding, this still may > cause reading stale data from this particular node until nodetool repair is > finished, which may take several hours. Is this correct? > > Is there a way (e.g. in newer releases 3.0/3.11) to tell a node not being > part of read requests? Something like a counterpart of nodetool drain for > writes? > > Other options: > > - Disabling binary/thrift: Although the node won’t act as > coordinator then for client requests, as it won’t be available from a client > perspective, inter-node, the recovering node is being contacted by other > nodes for serving requests, right? > > - Disabling gossip: Basically the node is marked as DOWN, so treated > like it is not available, thus not an option? > > - Temporarily reading at LOCAL_QUORUM/QUORUM until nodetool repair > is finished? > > > Did I miss something? > > Thanks, > Thomas > > The contents of this e-mail are intended for the named addressee only. It > contains information that may be confidential. Unless you are the named > addressee or an authorized designee, you may not copy or use it, or disclose > it to anyone else. If you received it in error please notify us immediately > and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) > is a company registered in Linz whose registered office is at 4040 Linz, > Austria, Freistädterstraße 313 > > The contents of this e-mail are intended for the named addressee only. It > contains information that may be confidential. Unless you are the named > addressee or an authorized designee, you may not copy or use it, or disclose > it to anyone else. If you received it in error please notify us immediately > and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) > is a company registered in Linz whose registered office is at 4040 Linz, > Austria, Freistädterstraße 313
