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 Nitan,
>
tool 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:
>
> Hello Nitan,
&
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 sho
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.
> 2. Do w
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?
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,
On Tue, Jun 10, 2014 at 7:31 AM, Jeremy Jongsma jer...@barchart.com 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
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 rc...@eventbrite.com wrote:
On Tue, Jun 10, 2014 at 7:31 AM, Jeremy Jongsma jer...@barchart.com
wrote:
, Jun 17, 2011 at 11:31 AM, Dominic Williams
dwilli...@system7.co.uk 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
,
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 (before
...@system7.co.uk 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 compacting (first
trace
copied below
On Fri, Jun 17, 2011 at 11:31 AM, Dominic Williams
dwilli...@system7.co.uk 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
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 r...@twitter.com wrote:
Even without lsof, you should be able to get the data from /proc/$pid
-ryan
On Fri, Jun 17, 2011 at 5:08 AM, Dominic Williams
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 dri...@gmail.com wrote:
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
On Wed, Mar 23, 2011 at 4:59 PM, Erik Onnen eon...@gmail.com 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
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 6:52 PM, Erik Onnen eon...@gmail.com 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
19 matches
Mail list logo
