You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Paulo Motta <pa...@gmail.com> on 2017/06/22 20:30:54 UTC
Re: Repairing question
> This attribute seems to be only modified when executing "nodetool repair [keyspace] [table....]", but not when executing with other options like --in-local-dc or --pr.
This is correct behavior because this metric actually represent the
percentage of SSTables incrementally repaired - and marked as repaired
- which doesn't happen when you execute a non-incremental repair
(--full, --in-local-dc, --pr). When you perform a non-incremental
repair data is repaired but not marked as repaired since this require
anti-compaction to be run.
Actually this "percent repaired" display name is a bit misleading,
since it sounds like data needs to be repaired while you could be
running non-incremental repairs and still have data 100% repaired, so
we should probably open a ticket to rename that to "Percent
incrementally repaired" or similar.
2017-06-22 14:38 GMT-05:00 Javier Canillas <ja...@gmail.com>:
> Hi,
>
> I have been thinking about scheduling a daily routine to force repairs on a
> cluster to maintain its health.
>
> I saw that by running a nodetool tablestats [keyspace] there is an attribute
> called "Percent repaired" that show the percentage of data repaired on the
> each table.
>
> This attribute seems to be only modified when executing "nodetool repair
> [keyspace] [table....]", but not when executing with other options like
> --in-local-dc or --pr.
>
> My main concern is about building the whole MERKLE tree for a big table. I
> have also check to repair by token ranges, but this also seems not to modify
> this attribute of the table.
>
> Is this an expected behavior? Or there is something missing on the code that
> needs to be fixed?
>
> My "maintenance" script would be calling nodetool tablestats per each
> keyspace that has replication_factor > 0 to check for the value of the
> "Percent repaired" of each table and, in case it is below some threshold, I
> would execute a repair on it.
>
> Any ideas?
>
> Thanks in advance.
>
> Javier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Repairing question
Posted by Javier Canillas <ja...@gmail.com>.
Paulo,
Thanks for your explanation.
2017-06-22 17:30 GMT-03:00 Paulo Motta <pa...@gmail.com>:
> > This attribute seems to be only modified when executing "nodetool repair
> [keyspace] [table....]", but not when executing with other options like
> --in-local-dc or --pr.
>
> This is correct behavior because this metric actually represent the
> percentage of SSTables incrementally repaired - and marked as repaired
> - which doesn't happen when you execute a non-incremental repair
> (--full, --in-local-dc, --pr). When you perform a non-incremental
> repair data is repaired but not marked as repaired since this require
> anti-compaction to be run.
>
> Actually this "percent repaired" display name is a bit misleading,
> since it sounds like data needs to be repaired while you could be
> running non-incremental repairs and still have data 100% repaired, so
> we should probably open a ticket to rename that to "Percent
> incrementally repaired" or similar.
>
>
> 2017-06-22 14:38 GMT-05:00 Javier Canillas <ja...@gmail.com>:
> > Hi,
> >
> > I have been thinking about scheduling a daily routine to force repairs
> on a
> > cluster to maintain its health.
> >
> > I saw that by running a nodetool tablestats [keyspace] there is an
> attribute
> > called "Percent repaired" that show the percentage of data repaired on
> the
> > each table.
> >
> > This attribute seems to be only modified when executing "nodetool repair
> > [keyspace] [table....]", but not when executing with other options like
> > --in-local-dc or --pr.
> >
> > My main concern is about building the whole MERKLE tree for a big table.
> I
> > have also check to repair by token ranges, but this also seems not to
> modify
> > this attribute of the table.
> >
> > Is this an expected behavior? Or there is something missing on the code
> that
> > needs to be fixed?
> >
> > My "maintenance" script would be calling nodetool tablestats per each
> > keyspace that has replication_factor > 0 to check for the value of the
> > "Percent repaired" of each table and, in case it is below some
> threshold, I
> > would execute a repair on it.
> >
> > Any ideas?
> >
> > Thanks in advance.
> >
> > Javier.
>
Re: Repairing question
Posted by Javier Canillas <ja...@gmail.com>.
Thanks for all the responses. It's much clearer now.
2017-06-26 0:59 GMT-03:00 Paulo Motta <pa...@gmail.com>:
> > Not sure since what version, but in 3.10 at least (I think its since 3.x
> started) full repair does do anti-compactions and marks sstables as
> repaired.
>
> Thanks for the correction, anti-compaction after full repairs was
> added on 2.2 CASSANDRA-7586 but removed on 4.0 by CASSANDRA-9143. Just
> for completeness, anti-compaction is not run when the following
> options are specified:
> -st/-et
> --local or --dc
> --full on 4.0+
>
> 2017-06-25 16:35 GMT-05:00 Cameron Zemek <ca...@instaclustr.com>:
> >> When you perform a non-incremental repair data is repaired but not
> marked
> >> as repaired since this require anti-compaction to be run.
> >
> > Not sure since what version, but in 3.10 at least (I think its since 3.x
> > started) full repair does do anti-compactions and marks sstables as
> > repaired.
> >
> > On 23 June 2017 at 06:30, Paulo Motta <pa...@gmail.com> wrote:
> >>
> >> > This attribute seems to be only modified when executing "nodetool
> repair
> >> > [keyspace] [table....]", but not when executing with other options
> like
> >> > --in-local-dc or --pr.
> >>
> >> This is correct behavior because this metric actually represent the
> >> percentage of SSTables incrementally repaired - and marked as repaired
> >> - which doesn't happen when you execute a non-incremental repair
> >> (--full, --in-local-dc, --pr). When you perform a non-incremental
> >> repair data is repaired but not marked as repaired since this require
> >> anti-compaction to be run.
> >>
> >> Actually this "percent repaired" display name is a bit misleading,
> >> since it sounds like data needs to be repaired while you could be
> >> running non-incremental repairs and still have data 100% repaired, so
> >> we should probably open a ticket to rename that to "Percent
> >> incrementally repaired" or similar.
> >>
> >>
> >> 2017-06-22 14:38 GMT-05:00 Javier Canillas <ja...@gmail.com>:
> >> > Hi,
> >> >
> >> > I have been thinking about scheduling a daily routine to force repairs
> >> > on a
> >> > cluster to maintain its health.
> >> >
> >> > I saw that by running a nodetool tablestats [keyspace] there is an
> >> > attribute
> >> > called "Percent repaired" that show the percentage of data repaired on
> >> > the
> >> > each table.
> >> >
> >> > This attribute seems to be only modified when executing "nodetool
> repair
> >> > [keyspace] [table....]", but not when executing with other options
> like
> >> > --in-local-dc or --pr.
> >> >
> >> > My main concern is about building the whole MERKLE tree for a big
> table.
> >> > I
> >> > have also check to repair by token ranges, but this also seems not to
> >> > modify
> >> > this attribute of the table.
> >> >
> >> > Is this an expected behavior? Or there is something missing on the
> code
> >> > that
> >> > needs to be fixed?
> >> >
> >> > My "maintenance" script would be calling nodetool tablestats per each
> >> > keyspace that has replication_factor > 0 to check for the value of the
> >> > "Percent repaired" of each table and, in case it is below some
> >> > threshold, I
> >> > would execute a repair on it.
> >> >
> >> > Any ideas?
> >> >
> >> > Thanks in advance.
> >> >
> >> > Javier.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >
>
Re: Repairing question
Posted by Paulo Motta <pa...@gmail.com>.
> Not sure since what version, but in 3.10 at least (I think its since 3.x started) full repair does do anti-compactions and marks sstables as repaired.
Thanks for the correction, anti-compaction after full repairs was
added on 2.2 CASSANDRA-7586 but removed on 4.0 by CASSANDRA-9143. Just
for completeness, anti-compaction is not run when the following
options are specified:
-st/-et
--local or --dc
--full on 4.0+
2017-06-25 16:35 GMT-05:00 Cameron Zemek <ca...@instaclustr.com>:
>> When you perform a non-incremental repair data is repaired but not marked
>> as repaired since this require anti-compaction to be run.
>
> Not sure since what version, but in 3.10 at least (I think its since 3.x
> started) full repair does do anti-compactions and marks sstables as
> repaired.
>
> On 23 June 2017 at 06:30, Paulo Motta <pa...@gmail.com> wrote:
>>
>> > This attribute seems to be only modified when executing "nodetool repair
>> > [keyspace] [table....]", but not when executing with other options like
>> > --in-local-dc or --pr.
>>
>> This is correct behavior because this metric actually represent the
>> percentage of SSTables incrementally repaired - and marked as repaired
>> - which doesn't happen when you execute a non-incremental repair
>> (--full, --in-local-dc, --pr). When you perform a non-incremental
>> repair data is repaired but not marked as repaired since this require
>> anti-compaction to be run.
>>
>> Actually this "percent repaired" display name is a bit misleading,
>> since it sounds like data needs to be repaired while you could be
>> running non-incremental repairs and still have data 100% repaired, so
>> we should probably open a ticket to rename that to "Percent
>> incrementally repaired" or similar.
>>
>>
>> 2017-06-22 14:38 GMT-05:00 Javier Canillas <ja...@gmail.com>:
>> > Hi,
>> >
>> > I have been thinking about scheduling a daily routine to force repairs
>> > on a
>> > cluster to maintain its health.
>> >
>> > I saw that by running a nodetool tablestats [keyspace] there is an
>> > attribute
>> > called "Percent repaired" that show the percentage of data repaired on
>> > the
>> > each table.
>> >
>> > This attribute seems to be only modified when executing "nodetool repair
>> > [keyspace] [table....]", but not when executing with other options like
>> > --in-local-dc or --pr.
>> >
>> > My main concern is about building the whole MERKLE tree for a big table.
>> > I
>> > have also check to repair by token ranges, but this also seems not to
>> > modify
>> > this attribute of the table.
>> >
>> > Is this an expected behavior? Or there is something missing on the code
>> > that
>> > needs to be fixed?
>> >
>> > My "maintenance" script would be calling nodetool tablestats per each
>> > keyspace that has replication_factor > 0 to check for the value of the
>> > "Percent repaired" of each table and, in case it is below some
>> > threshold, I
>> > would execute a repair on it.
>> >
>> > Any ideas?
>> >
>> > Thanks in advance.
>> >
>> > Javier.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Repairing question
Posted by Paulo Motta <pa...@gmail.com>.
> Not sure since what version, but in 3.10 at least (I think its since 3.x started) full repair does do anti-compactions and marks sstables as repaired.
Thanks for the correction, anti-compaction after full repairs was
added on 2.2 CASSANDRA-7586 but removed on 4.0 by CASSANDRA-9143. Just
for completeness, anti-compaction is not run when the following
options are specified:
-st/-et
--local or --dc
--full on 4.0+
2017-06-25 16:35 GMT-05:00 Cameron Zemek <ca...@instaclustr.com>:
>> When you perform a non-incremental repair data is repaired but not marked
>> as repaired since this require anti-compaction to be run.
>
> Not sure since what version, but in 3.10 at least (I think its since 3.x
> started) full repair does do anti-compactions and marks sstables as
> repaired.
>
> On 23 June 2017 at 06:30, Paulo Motta <pa...@gmail.com> wrote:
>>
>> > This attribute seems to be only modified when executing "nodetool repair
>> > [keyspace] [table....]", but not when executing with other options like
>> > --in-local-dc or --pr.
>>
>> This is correct behavior because this metric actually represent the
>> percentage of SSTables incrementally repaired - and marked as repaired
>> - which doesn't happen when you execute a non-incremental repair
>> (--full, --in-local-dc, --pr). When you perform a non-incremental
>> repair data is repaired but not marked as repaired since this require
>> anti-compaction to be run.
>>
>> Actually this "percent repaired" display name is a bit misleading,
>> since it sounds like data needs to be repaired while you could be
>> running non-incremental repairs and still have data 100% repaired, so
>> we should probably open a ticket to rename that to "Percent
>> incrementally repaired" or similar.
>>
>>
>> 2017-06-22 14:38 GMT-05:00 Javier Canillas <ja...@gmail.com>:
>> > Hi,
>> >
>> > I have been thinking about scheduling a daily routine to force repairs
>> > on a
>> > cluster to maintain its health.
>> >
>> > I saw that by running a nodetool tablestats [keyspace] there is an
>> > attribute
>> > called "Percent repaired" that show the percentage of data repaired on
>> > the
>> > each table.
>> >
>> > This attribute seems to be only modified when executing "nodetool repair
>> > [keyspace] [table....]", but not when executing with other options like
>> > --in-local-dc or --pr.
>> >
>> > My main concern is about building the whole MERKLE tree for a big table.
>> > I
>> > have also check to repair by token ranges, but this also seems not to
>> > modify
>> > this attribute of the table.
>> >
>> > Is this an expected behavior? Or there is something missing on the code
>> > that
>> > needs to be fixed?
>> >
>> > My "maintenance" script would be calling nodetool tablestats per each
>> > keyspace that has replication_factor > 0 to check for the value of the
>> > "Percent repaired" of each table and, in case it is below some
>> > threshold, I
>> > would execute a repair on it.
>> >
>> > Any ideas?
>> >
>> > Thanks in advance.
>> >
>> > Javier.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
For additional commands, e-mail: user-help@cassandra.apache.org
Re: Repairing question
Posted by Cameron Zemek <ca...@instaclustr.com>.
> When you perform a non-incremental repair data is repaired but not marked
as repaired since this require anti-compaction to be run.
Not sure since what version, but in 3.10 at least (I think its since 3.x
started) full repair does do anti-compactions and marks sstables as
repaired.
On 23 June 2017 at 06:30, Paulo Motta <pa...@gmail.com> wrote:
> > This attribute seems to be only modified when executing "nodetool repair
> [keyspace] [table....]", but not when executing with other options like
> --in-local-dc or --pr.
>
> This is correct behavior because this metric actually represent the
> percentage of SSTables incrementally repaired - and marked as repaired
> - which doesn't happen when you execute a non-incremental repair
> (--full, --in-local-dc, --pr). When you perform a non-incremental
> repair data is repaired but not marked as repaired since this require
> anti-compaction to be run.
>
> Actually this "percent repaired" display name is a bit misleading,
> since it sounds like data needs to be repaired while you could be
> running non-incremental repairs and still have data 100% repaired, so
> we should probably open a ticket to rename that to "Percent
> incrementally repaired" or similar.
>
>
> 2017-06-22 14:38 GMT-05:00 Javier Canillas <ja...@gmail.com>:
> > Hi,
> >
> > I have been thinking about scheduling a daily routine to force repairs
> on a
> > cluster to maintain its health.
> >
> > I saw that by running a nodetool tablestats [keyspace] there is an
> attribute
> > called "Percent repaired" that show the percentage of data repaired on
> the
> > each table.
> >
> > This attribute seems to be only modified when executing "nodetool repair
> > [keyspace] [table....]", but not when executing with other options like
> > --in-local-dc or --pr.
> >
> > My main concern is about building the whole MERKLE tree for a big table.
> I
> > have also check to repair by token ranges, but this also seems not to
> modify
> > this attribute of the table.
> >
> > Is this an expected behavior? Or there is something missing on the code
> that
> > needs to be fixed?
> >
> > My "maintenance" script would be calling nodetool tablestats per each
> > keyspace that has replication_factor > 0 to check for the value of the
> > "Percent repaired" of each table and, in case it is below some
> threshold, I
> > would execute a repair on it.
> >
> > Any ideas?
> >
> > Thanks in advance.
> >
> > Javier.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Repairing question
Posted by Javier Canillas <ja...@gmail.com>.
Paulo,
Thanks for your explanation.
2017-06-22 17:30 GMT-03:00 Paulo Motta <pa...@gmail.com>:
> > This attribute seems to be only modified when executing "nodetool repair
> [keyspace] [table....]", but not when executing with other options like
> --in-local-dc or --pr.
>
> This is correct behavior because this metric actually represent the
> percentage of SSTables incrementally repaired - and marked as repaired
> - which doesn't happen when you execute a non-incremental repair
> (--full, --in-local-dc, --pr). When you perform a non-incremental
> repair data is repaired but not marked as repaired since this require
> anti-compaction to be run.
>
> Actually this "percent repaired" display name is a bit misleading,
> since it sounds like data needs to be repaired while you could be
> running non-incremental repairs and still have data 100% repaired, so
> we should probably open a ticket to rename that to "Percent
> incrementally repaired" or similar.
>
>
> 2017-06-22 14:38 GMT-05:00 Javier Canillas <ja...@gmail.com>:
> > Hi,
> >
> > I have been thinking about scheduling a daily routine to force repairs
> on a
> > cluster to maintain its health.
> >
> > I saw that by running a nodetool tablestats [keyspace] there is an
> attribute
> > called "Percent repaired" that show the percentage of data repaired on
> the
> > each table.
> >
> > This attribute seems to be only modified when executing "nodetool repair
> > [keyspace] [table....]", but not when executing with other options like
> > --in-local-dc or --pr.
> >
> > My main concern is about building the whole MERKLE tree for a big table.
> I
> > have also check to repair by token ranges, but this also seems not to
> modify
> > this attribute of the table.
> >
> > Is this an expected behavior? Or there is something missing on the code
> that
> > needs to be fixed?
> >
> > My "maintenance" script would be calling nodetool tablestats per each
> > keyspace that has replication_factor > 0 to check for the value of the
> > "Percent repaired" of each table and, in case it is below some
> threshold, I
> > would execute a repair on it.
> >
> > Any ideas?
> >
> > Thanks in advance.
> >
> > Javier.
>