re working for most most
>> operations.
>>
>> Network looks good. Any other ideas?
>>
>>
>> Regards,
>> Nitan
>> Cell: 510 449 9629
>>
>>> On May 28, 2019, at 11:21 AM, Alain RODRIGUEZ wrote:
>>>
>>> Hello Nita
> Nodetool status shows all nodes up and read writes are working for most
> most operations.
>
> Network looks good. Any other ideas?
>
>
> Regards,
>
> Nitan
>
> Cell: 510 449 9629
>
> On May 28, 2019, at 11:21 AM, Alain RODRIGUEZ wrote:
>
> Hell
most
operations.
Network looks good. Any other ideas?
Regards,
Nitan
Cell: 510 449 9629
> On May 28, 2019, at 11:21 AM, Alain RODRIGUEZ wrote:
>
> Hello Nitan,
>
>> 1. Can sstable corruption in application tables cause schema mismatch?
>
> I would say it should not
Hello Nitan,
1. Can sstable corruption in application tables cause schema mismatch?
>
I would say it should not. I could imagine in the case that the corrupted
table hits some 'system' keyspace sstable. If not I don' see how corrupted
data can impact the schema on the node.
Hi,
Two questions:
1. Can sstable corruption in application tables cause schema mismatch?
2. Do we need to disable repair while adding storage while Cassandra is down?
Regards,
Nitan
Cell: 510 449 9629
which versions of cassandra 2.x and 3.x are best for avoiding sstable
corruption and schema migration slowness?
is this a "cassandra is not a set it and forget it system" concept?
If you've been dropping and recreating tables with the same name, you might
be seeing this: https://issues.apache.org/jira/browse/CASSANDRA-6525
On Tue, Jun 10, 2014 at 12:19 PM, Robert Coli wrote:
> On Tue, Jun 10, 2014 at 7:31 AM, Jeremy Jongsma
> wrote:
>
>> I'm in the process of migrating
On Tue, Jun 10, 2014 at 7:31 AM, Jeremy Jongsma wrote:
> I'm in the process of migrating data over to cassandra for several of our
> apps, and a few of the schemas use secondary indexes. Four times in the
> last couple months I've run into a corrupted sstable belonging to a
> secondary index, but
I'm in the process of migrating data over to cassandra for several of our
apps, and a few of the schemas use secondary indexes. Four times in the
last couple months I've run into a corrupted sstable belonging to a
secondary index, but have never seen this on any other sstables. When it
happens, any
o poke around I can also
arrange to give password as node will be decommissioned anyway? You can then
take a look at the SSTable corruption too etc
On 17 June 2011 18:06, Ryan King wrote:
> Even without lsof, you should be able to get the data from /proc/$pid
>
> -ryan
>
> On
Sylvain
>> >>
>> >>
>> >> On Fri, Jun 17, 2011 at 11:31 AM, Dominic Williams
>> >> wrote:
>> >> > Hi all,
>> >> > Anyone experiencing this..?
>> >> > I noticed one of my 7.6-2 nodes had inexplicable and con
;
> >>
> >> On Fri, Jun 17, 2011 at 11:31 AM, Dominic Williams
> >> wrote:
> >> > Hi all,
> >> > Anyone experiencing this..?
> >> > I noticed one of my 7.6-2 nodes had inexplicable and consistently high
> >> > cpu
> >
>>
>>
>> On Fri, Jun 17, 2011 at 11:31 AM, Dominic Williams
>> wrote:
>> > Hi all,
>> > Anyone experiencing this..?
>> > I noticed one of my 7.6-2 nodes had inexplicable and consistently high
>> > cpu
>> > usage. Checking the
wrote:
> > Hi all,
> > Anyone experiencing this..?
> > I noticed one of my 7.6-2 nodes had inexplicable and consistently high
> cpu
> > usage. Checking the log I found that there was a some kind of SSTable
> > corruption that was stopping a bunch of files from compact
, Jun 17, 2011 at 11:31 AM, Dominic Williams
wrote:
> Hi all,
> Anyone experiencing this..?
> I noticed one of my 7.6-2 nodes had inexplicable and consistently high cpu
> usage. Checking the log I found that there was a some kind of SSTable
> corruption that was stopping a bunc
Hi all,
Anyone experiencing this..?
I noticed one of my 7.6-2 nodes had inexplicable and consistently high cpu
usage. Checking the log I found that there was a some kind of SSTable
corruption that was stopping a bunch of files from compacting (first trace
copied below).
I then tried scrub
Yes, Statistics is convenient because as part of supporting old 0.6
data Cassandra will just build it if it's not there.
Technically you can rebuild filter and index too but it's not automatic.
It looks like when we added statistics we didn't make sure to fsync it
when we fsync the other componen
Just accidently hard resetet a node running 0.7.2 (with some patches from
0.7.3) and had the same problem.
I'm a little hesitating upgrading to 0.7.4
Can I always delete the Statistics.db without any data loss?
Thibaut
On Thu, Mar 24, 2011 at 1:37 AM, Brandon Williams wrote:
> On Wed, Mar 23
On Wed, Mar 23, 2011 at 6:52 PM, Erik Onnen wrote:
> Thanks, so is it the "[Index.db, Statistics.db, Data.db, Filter.db];
> skipped" that indicates it's in Statistics? Basically I need a way to
> know if the same is true of all the other tables showing this issue.
It's the at
org.apache.cassand
Thanks, so is it the "[Index.db, Statistics.db, Data.db, Filter.db];
skipped" that indicates it's in Statistics? Basically I need a way to
know if the same is true of all the other tables showing this issue.
-erik
On Wed, Mar 23, 2011 at 4:59 PM, Erik Onnen wrote:
> After an upgrade from 0.7.3 to 0.7.4, we're seeing the following on
> several data files:
>
> ERROR [main] 2011-03-23 18:58:33,137 ColumnFamilyStore.java (line 235)
> Corrupt sstable
> /mnt/services/cassandra/var/data/0.7.4/data/Helium/dp_idx-f
After an upgrade from 0.7.3 to 0.7.4, we're seeing the following on
several data files:
ERROR [main] 2011-03-23 18:58:33,137 ColumnFamilyStore.java (line 235)
Corrupt sstable
/mnt/services/cassandra/var/data/0.7.4/data/Helium/dp_idx-f-4844=[Index.db,
Statistics.db, Data.db, Filter.db]; skipped
jav
22 matches
Mail list logo
