On Wed, Oct 28, 2015 at 2:20 PM, Vasileios Vlachos <
vasileiosvlac...@gmail.com> wrote:
> Thanks for clarifying this Rob.
>
> -However no step other than 2) provides a *guarantee* of consistency. And
> it only provides that guarantee for data that exists when the repair starts.
>
> I read the
Rob,
Would you mind to elaborate further on this? I am a little concerned that
my understanding (nodetool repair is *not* the only way one can achieve
consistency) is not correct. I understand that if people use CL < QUORUM,
nodetool repair is the only way to go, but I just cannot see how can
On Sat, Oct 24, 2015 at 2:02 PM, Vasileios Vlachos <
vasileiosvlac...@gmail.com> wrote:
>
>> All other means of repair are optimizations which require a certain
>> amount of luck to happen to result in consistency.
>>
>
> Is that true regardless of the CL one uses? So, for example if writing
>
I am not sure I fully understand the question, because nodetool repair is
one of the three ways for Cassandra to ensure consistency. If by "affect"
you mean "make your data consistent and ensure all replicas are
up-to-date", then yes, that's what I think it does.
And yes, I would expect nodetool
Max hint window is only part of the equation. If it is down longer than
Max hint window, a repair will still fix up the node for you.
The max time a node can be down before it must be re built is determined by
the lowest gc grace setting on your various tables. By default gc grace is
10 days,
Never mind Vasileios, you have been a great help !!
Thanks a ton again !!!
Thanks and Regards,
Ajay
On Sat, Oct 24, 2015 at 10:17 PM, Vasileios Vlachos <
vasileiosvlac...@gmail.com> wrote:
> I am not sure I fully understand the question, because nodetool repair is
> one of the three ways for
Thanks a ton Vasileios !!
Just one last question ::
Does running "nodetool repair" affect the functionality of cluster for
current-live data?
It's ok if the insertions/deletions of current-live data become a little
slow during the process, but data-consistency must be maintained. If that
is the
On Sat, Oct 24, 2015 at 9:47 AM, Vasileios Vlachos <
vasileiosvlac...@gmail.com> wrote:
> I am not sure I fully understand the question, because nodetool repair is
> one of the three ways for Cassandra to ensure consistency. If by "affect"
> you mean "make your data consistent and ensure all
>
>
> All other means of repair are optimizations which require a certain amount
> of luck to happen to result in consistency.
>
Is that true regardless of the CL one uses? So, for example if writing
QUORUM and reading QUORUM, wouldn't an increased read_repair_chance
probability be sufficient? If
Hello Ajay,
Here is a good link:
http://docs.datastax.com/en/cassandra/2.1/cassandra/operations/opsRepairNodesManualRepair.html
Generally, I find the DataStax docs to be OK. You could consult them for
all usual operations etc. Ofc there are occasions where a given concept is
not as clear, but
If a node in the cluster goes down and comes up, the data gets synced up on
this downed node.
Is there a limit on the interval for which the node can remain down? Or the
data will be synced up even if the node remains down for weeks/months/years?
--
Regards,
Ajay
Thanks Vasileios for the reply !!!
That makes sense !!!
I will be grateful if you could point me to the node-repair command for
Cassandra-2.1.10.
I don't want to get stuck in a wrong-versioned documentation (already
bitten once hard when setting up replication).
Thanks again...
Thanks and
Hello Ajay,
Have a look in the *max_hint_window_in_ms* :
http://docs.datastax.com/en/cassandra/2.0/cassandra/configuration/configCassandra_yaml_r.html
My understanding is that if a node remains down for more than
*max_hint_window_in_ms*, then you will need to repair that node.
Thanks,
Vasilis
13 matches
Mail list logo
