Re: Cassandra Repair question

Yes - agree with Sergio. For the majority of use cases, the best practice for repair is to use Cassandra Reaper. > On Oct 19, 2019, at 12:06 am, Sergio wrote: > > Use Cassandra reaper > > On Fri, Oct 18, 2019, 10:12 PM Krish Donald > wrote: > Thanks Manish, > >

Re: Cassandra Repair question

Use Cassandra reaper On Fri, Oct 18, 2019, 10:12 PM Krish Donald wrote: > Thanks Manish, > > What is the best and fastest way to repair a table using nodetool repair ? > We are using 256 vnodes . > > > On Fri, Oct 18, 2019 at 10:05 PM manish khandelwal < > manishkhandelwa...@gmail.com> wrote: >

Re: Cassandra Repair question

Thanks Manish, What is the best and fastest way to repair a table using nodetool repair ? We are using 256 vnodes . On Fri, Oct 18, 2019 at 10:05 PM manish khandelwal < manishkhandelwa...@gmail.com> wrote: > No it will only cover primary ranges of nodes on single rac. Repair with > -pr option i

Re: Cassandra Repair question

No it will only cover primary ranges of nodes on single rac. Repair with -pr option is to be run on all nodes in a rolling manner. Regards Manish On 19 Oct 2019 10:03, "Krish Donald" wrote: > Hi Cassandra experts, > > > We are on Cassandra 3.11.1. > > We have to run repairs for a big cluster. >

Cassandra Repair question

Hi Cassandra experts, We are on Cassandra 3.11.1. We have to run repairs for a big cluster. We have 2 DCs. 3 RACs in each DC. Replication factor is 3 for each datacenter . So if I run repair on all nodes of a single RAC with "pr" option then ideally it will cover all the ranges. Please cor

Re: table repair question

I'm doing it on a daily basis. If the repaired percentage drops from 80%, then I do a repair over that keyspace-table. Seems working fine for the last months without problems and avoids huge merkle tree building. No data loss so far. I'm running 3.11.0 btw. 2017-10-04 17:44 GMT-03:00 Blake Eggles

Re: table repair question

Incremental repairs should also update the percentage, although I'd recommend not using incremental repair before 4.0. Just want to point out that running repairs based on repaired % isn't necessarily a bad thing, but it should be a secondary consideration. The important thing is to repair data

Re: table repair question

That percentage will only be updated if you do a full repair. If you do repairs on local dc or with -pr, that percentage will not be updated. I scripted a regular repair on each node based on if this percentage is below some threshold. It has been running fine since several months ago. 2017-10-04

Re: table repair question

Not really no. There's a repaired % in nodetool tablestats if you're using incremental repair (and you probably shouldn't be before 4.0 comes out), but I wouldn't make any decisions based off it's value. On October 4, 2017 at 8:05:44 AM, ZAIDI, ASAD A (az1...@att.com) wrote: Hello folk,   I’

table repair question

Hello folk, I'm wondering if there is way to find out list of table(s) which need repair OR if there Is way to find out what %age of data would need to be repaired on a table? Is such information available from Cassandra db engine through some other means? TIA~ Asad

Re: repair question (-dc option)

: "Gopal, Dhruva" Cc: "user@cassandra.apache.org" Subject: Re: repair question (-dc option) If there was no node down during that period, and you are using LOCAL_QUORUM read/write, then yes above command works. On Thu, May 11, 2017 at 11:59 AM, Gopal, Dhruva mailto:dhr

Re: repair question (-dc option)

If there was no node down during that period, and you are using LOCAL_QUORUM read/write, then yes above command works. On Thu, May 11, 2017 at 11:59 AM, Gopal, Dhruva wrote: > Hi – > > I have a question on running a repair after bringing up a node that was > down (brought down gracefully) for

repair question (-dc option)

Hi – I have a question on running a repair after bringing up a node that was down (brought down gracefully) for a few days within a data center. Can we just run nodetool repair –dc on a single node (within that DC – specifically the downed node, after it is brought online) and have that entir

Re: Nodetool repair question

No - repair does not change token ownership. The up/down state of a node is not related to token ownership. On Tue, May 10, 2016 at 3:26 PM, Anubhav Kale wrote: > Hello, > > > > Suppose I have 3 nodes, and stop Cassandra on one of them. Then I run a > repair. Will repair move the token ranges fr

Nodetool repair question

Hello, Suppose I have 3 nodes, and stop Cassandra on one of them. Then I run a repair. Will repair move the token ranges from down node to other node ? In other words in any situation, does repair operation ever change token ownership ? Thanks !

Re: Cassandra nodetool repair question

But node might be streaming data as well, in that case only option is to restart node that started streaming operation Sent from my iPhone On Aug 8, 2013, at 5:56 PM, Andrey Ilinykh wrote: > nodetool repair just triggers repair procedure. You can kill nodetool after > start, it doesn't change

Re: Cassandra nodetool repair question

nodetool repair just triggers repair procedure. You can kill nodetool after start, it doesn't change anything. To stop repair you have to use nodetool stop VALIDATION|COMPACTION Thank you, Andrey On Thu, Aug 8, 2013 at 1:00 PM, Andy Losey wrote: > Afternoon, > > We are noticing nodetool

Cassandra nodetool repair question

Afternoon, We are noticing nodetool repair processes are not completing after a weeks worth of time, and have resulted in some Cassandra nodes having more than one process running do to cron scheduled. We are also chasing some performance degradation after upgrading all nodes to version 1.2.8

Re: Re: Repair question - why is so much data transferred?

I have been thinking about the problem of repair for a while. if we do not consider the need for partition-tolerance, then the eventual consistency approach is probably the ultimate reason for needing repairs: compared to Zookeeper/Spinnaker (recent VLDB paper)/Chubby/HBase, those systems only nee

Re: Re: Repair question - why is so much data transferred?

On Thu, Jul 21, 2011 at 10:43 AM, wrote: > from ticket 2818: > "One (reasonably simple) proposition to fix this would be to have repair > schedule validation compactions across nodes one by one (i.e, one CF/range > at a time), waiting for all nodes to return their tree before submitting the > nex

Re: Re: Repair question - why is so much data transferred?

from ticket 2818: "One (reasonably simple) proposition to fix this would be to have repair schedule validation compactions across nodes one by one (ie, one CF/range at a time), waiting for all nodes to return their tree before submitting the next request. Then on each node, we should make su

Re: Repair question - why is so much data transferred?

On Thu, Jul 21, 2011 at 9:14 AM, Jonathan Colby wrote: > I regularly run repair on my cassandra cluster.   However, I often seen that > during the repair operation very large amounts of data are transferred to > other nodes. https://issues.apache.org/jira/browse/CASSANDRA-2280 https://issues.ap

Repair question - why is so much data transferred?

I regularly run repair on my cassandra cluster. However, I often seen that during the repair operation very large amounts of data are transferred to other nodes. My questions is, if only some data is out of sync, why are entire Data files being transferred? /var/lib/cassandra/data/DFS/ma

Re: nodetool repair question

I know it doesn't. But is this a valid enhancement request? On Tue, Jul 5, 2011 at 1:32 PM, Edward Capriolo wrote: > > > On Tue, Jul 5, 2011 at 1:27 PM, Raj N wrote: > >> Hi experts, >> Are there any benchmarks that quantify how long nodetool repair >> takes? Something which says on this ki

Re: nodetool repair question

On Tue, Jul 5, 2011 at 1:27 PM, Raj N wrote: > Hi experts, > Are there any benchmarks that quantify how long nodetool repair takes? > Something which says on this kind of hardware, with this much of data, > nodetool repair takes this long. The other question that I have is since > Cassandra

nodetool repair question

Hi experts, Are there any benchmarks that quantify how long nodetool repair takes? Something which says on this kind of hardware, with this much of data, nodetool repair takes this long. The other question that I have is since Cassandra recommends running nodetool repair within GCGracePeriodSe

Re: repair question

Ok - obviously these haven't been my brightest days. The stream request sent to the neighbors doesn't contain the CF for which the ranges have been determined to mismatch. So every diff in every CF will result in getting that range from every CF of the neighbor. That explains everything. So I

Re: repair question

> Hmmm, I'm starting to like this idea more and more the more I think of it ;) Filed: https://issues.apache.org/jira/browse/CASSANDRA-2699 -- / Peter Schuller

Re: repair question

> And the more spread out the out of sync is, the worse it will be. Though in > general we can expect that to not be too spread out. For the same reason than > why caches work. (Speaking generally now, not addressing the OP's issue) I'm not sure I buy that. Unless your data is such that hotness i

Re: repair question

Ok thanks for your help Sylvain - much appreciated In short: I believe that most of this is me not looking clearly yesterday. There are only one / two points that i don't get. Maybe you could help me out there. First the ~500MB thing is BS. The closer neighbors recieved around 80G and the oth

Re: repair question

On Tue, May 24, 2011 at 9:41 AM, Sylvain Lebresne wrote: > On Tue, May 24, 2011 at 12:40 AM, Daniel Doubleday > wrote: > > We are performing the repair on one node only. Other nodes receive > reasonable amounts of data (~500MB). It's only the repairing node itself > which 'explodes'. > > That, f

Re: repair question

On Tue, May 24, 2011 at 12:40 AM, Daniel Doubleday wrote: > We are performing the repair on one node only. Other nodes receive reasonable > amounts of data (~500MB).  It's only the repairing node itself which > 'explodes'. That, for instance, is a bit weird. That the node on which the repair is

Re: repair question

On Mon, May 23, 2011 at 9:21 PM, Peter Schuller wrote: >> I'm a bit lost: I tried a repair yesterday with only one CF and that didn't >> really work the way I expected but I thought that would be a bug which only >> affects that special case. >> >> So I tried again for all CFs. >> >> I started w

Re: repair question

We are performing the repair on one node only. Other nodes receive reasonable amounts of data (~500MB). It's only the repairing node itself which 'explodes'. I must admit that I'm a noob when it comes to aes/repair. Its just strange that a cluster that is up and running with no probs is doing

Re: repair question

> I'm a bit lost: I tried a repair yesterday with only one CF and that didn't > really work the way I expected but I thought that would be a bug which only > affects that special case. > > So I tried again for all CFs. > > I started with a nicely compacted machine with around 320GB of load. Total

Re: repair question

Thanks Sylvain well no I don't really understand it at all. We have all Wide rows / small val to single larger column in one row. The problem hits every CF. RF = 3 Read / Write with Quorum. The CF that is killing me right now is one col thats never updated (its WORM - updates are reinserts u

Re: repair question

On Mon, May 23, 2011 at 7:17 PM, Daniel Doubleday wrote: > Hi all > > I'm a bit lost: I tried a repair yesterday with only one CF and that didn't > really work the way I expected but I thought that would be a bug which only > affects that special case. > > So I tried again for all CFs. > > I sta

repair question

Hi all I'm a bit lost: I tried a repair yesterday with only one CF and that didn't really work the way I expected but I thought that would be a bug which only affects that special case. So I tried again for all CFs. I started with a nicely compacted machine with around 320GB of load. Total dis