Peter, I want to join everyone else thanking you for helping out so much
with this thread, and especially for pointing out the problems with the DS
docs on this topic. We have some corrections posted today, and will keep
looking to improve the information.
On Thu, Mar 31, 2011 at 3:11 PM, Peter S
> Thanks a lot for elaborating on repairs. Still, it's a bit fuzzy to me why
> it is so important to run a repair before the GCGraceSeconds kicks in. Does
> this mean a delete does not get "replicated" ? In other words when I delete
> something on a node, doesn't cassandra set tombstones
Peter -
Thanks a lot for elaborating on repairs.Still, it's a bit fuzzy to me why
it is so important to run a repair before the GCGraceSeconds kicks in. Does
this mean a delete does not get "replicated" ? In other words when I delete
something on a node, doesn't cassandra set tombstones
If I am not wrong node repair need to be run on all the nodes in staggerred
manner. It is required to take care of tombstones. Please correct me team if
I am wrong :)
See Distributed Deletes:
http://wiki.apache.org/cassandra/Operations
--
View this message in context:
http://cassandra-user-in
> silly question, would every cassandra installation need to have manual
> repairs done on it?
>
> It would seem cassandra's "read repair" and regular compaction would take
> care of keeping the data clean.
>
> Am I missing something?
See my previous posts in this thread for the distinct reasons
silly question, would every cassandra installation need to have manual repairs
done on it?
It would seem cassandra's "read repair" and regular compaction would take care
of keeping the data clean.
Am I missing something?
On Mar 30, 2011, at 7:46 PM, Peter Schuller wrote:
>> I just wanted t
> I just wanted to chime in here and say some people NEVER run repair.
Just so long as the OP is understanding that this implies taking an
explicit decision to accept the "misbehavior" you will see as a
result. I.e., the reason people survive not doing repairs in some
cases is, as in your case, th
> I concur. JIRA time?
https://issues.apache.org/jira/browse/CASSANDRA-2405
--
/ Peter Schuller
On Wed, Mar 30, 2011 at 12:54 PM, Peter Schuller
wrote:
>> Note this script doesn't work if your repair takes hours, and in the
>> middle of the repair cassandra was restarted, nodetool will exit and the
>> flagfile will be updated. Another case, if repair hangs, and day later
>> cassandra is re
> Note this script doesn't work if your repair takes hours, and in the
> middle of the repair cassandra was restarted, nodetool will exit and the
> flagfile will be updated. Another case, if repair hangs, and day later
> cassandra is restarted.
This is why "set -e" is at the to and commented as
On 03/29/2011 01:18 PM, Peter Schuller wrote:
> (What *would* be useful perhaps is to be able to ask a node for the
> time of its most recently started repair, to facilitate easier
> comparison with GCGraceSeconds for monitoring purposes.)
I concur. JIRA time?
(Perhaps keeping track of the same
On 03/30/11 00:31, Peter Schuller wrote:
>
> set -e # important
> touch /path/to/flagfile.tmp
> nodetool -h localhost repair
> mv /path/to/flagfile.tmp /path/to/flagfile
>
Note this script doesn't work if your repair takes hours, and in the
middle of the repair cassandra was restarted, node
> I think what I feel is that there is a need to know if repair is required
> flag in order for team to manage the cluster.
And again, repair is always required essentially. You should *always*
run it within the necessary period as determined by GCGraceSeconds.
> Atleast at minimum, Is there a fl
I think what I feel is that there is a need to know if repair is required
flag in order for team to manage the cluster.
Atleast at minimum, Is there a flag somewhere that tells if repair was run
within GCGracePeriod?
--
View this message in context:
http://cassandra-user-incubator-apache-org.306
> So from what I am understanding is that there is no need to monitor this and
> no need to remember running repair? If that's the case then manual repair
> wouldn't be needed ever, correct?
No. See my next-to-last e-mail where I go through two reasons to run
nodetool repair, of which (a) is absol
So from what I am understanding is that there is no need to monitor this and
no need to remember running repair? If that's the case then manual repair
wouldn't be needed ever, correct?
But if Manual repair is needed then shouldn't there be ability to monitor?
Having dealt with production problems
> Looks like you didn't get to see my updated post :) This is the scenario I
> was referring to:
I don't see what's different. If you write a QUORUM and read at
QUORUM, your read is guaranteed to see a previous write, period. If
that cannot be satisfied, the read will fail due to not being able to
Looks like you didn't get to see my updated post :) This is the scenario I
was referring to:
Say Node A, B, C. Now A is inconsistent and needs repair. Now after a day
Node B goes down and comes up. Now both nodes are inconsistent. Even with
Quorum this will fail read and write by returning inconsi
First some specifics:
> I think my problem is that I don't want to remember to run read repair. I
You are not expected to remember to do so manually. Typically periodic
repairs would be automated in some fashion, such as by having a cron
job on each node that starts the repair. Typically some kin
I think my problem is that I don't want to remember to run read repair. I
want to know from cassandra that I "need" to run repair "now". This seems
like a important functionality that need to be there. I don't really want to
find out hard way that I forgot to run "repair" :)
Say Node A, B, C. Now
> Thanks! I was keeping the discussion simple. But you make my case stronger
> that we need such monitoring since it looks like it should always be run but
> we want to run it as soon as it is required.
The way to deal with individual requests timing out or transient
flapping, is to use a consiste
Thanks! I was keeping the discussion simple. But you make my case stronger
that we need such monitoring since it looks like it should always be run but
we want to run it as soon as it is required.
--
View this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Ho
> Yes but that doesn't really provide the monitoring that will really be
> helpful. If I don't realize it until 2 days then we potentially could be
> returning inconsistent results or not have data sync for 2 days until repair
> is run. It will be best to be able to monitor these things so that it
Yes but that doesn't really provide the monitoring that will really be
helpful. If I don't realize it until 2 days then we potentially could be
returning inconsistent results or not have data sync for 2 days until repair
is run. It will be best to be able to monitor these things so that it can be
r
> Is there a way to monitor and tell if one of the node require repair? For eg:
> Node was down and came back up but in the meantime HH were dropped. Now
> unless we are really careful in all the scenarios we wouldn't have any
> problems :) but in general when things are going awry you might forget
25 matches
Mail list logo
