Hi,
It seems like dropping a column can cause a "java.io.IOException:
Corrupt empty row found in unfiltered partition" exception when existing
SSTables are later compacted.
This seems to happen with all Cassandra 3.x versions and is very easy to
replicate. I've created a jira with all the d
On 18/12/14 21:45, Robert Coli wrote:
> On Tue, Dec 16, 2014 at 12:38 AM, Jonas Borgström <mailto:jo...@borgstrom.se>> wrote:
>
> That said, I've done some testing and it appears to be possible to
> perform an in place conversion as long as all nodes contain a
Hi,
I know that adding a new vnode enabled DC is the recommended method to
convert and existing cluster to vnode. And that the cassandra-shuffle
utility has been removed.
That said, I've done some testing and it appears to be possible to
perform an in place conversion as long as all nodes contain
Hi,
Can someone give some more details about the CASSANDRA-4116 bug fixed in
this release? Could this cause resurrection of deleted data for example?
https://issues.apache.org/jira/browse/CASSANDRA-4116
/ Jonas
On 2012-05-08 11:04 , Sylvain Lebresne wrote:
> The Cassandra team is pleased to an
or a feature?
To me it just looks like a wast of disk space...
/ Jonas
best regards,
坚果云 <https://jianguopuzi.com/>, 最简捷易用的云存储
无限空间, 文件同步, 备份和分享!
2012/3/30 Jonas Borgström mailto:jo...@borgstrom.se>>
Let me rephrase my question:
Is it true that deleted rows will still b
Let me rephrase my question:
Is it true that deleted rows will still be present in the sstable after
a major compaction with 1.0.8 (not just tombstones)?
Or did I mess up my test below?
/ Jonas
On 2012-03-28 10:23 , Jonas Borgström wrote:
Hi all,
I've noticed a change in behavior be
Hi all,
I've noticed a change in behavior between 0.8.10 and 1.0.8 when it comes
to sstable2json output and major compactions. Is this a bug or intended
behavior?
With 1.0.8:
create keyspace ks;
use ks;
create column family foo;
set foo[1][1] = 1;
nodetool -h localhost flush
sstable2json foo
Hi,
I have some questions about SSTable compatibility when doing a minor
version upgrade. For example when upgrading from 1.0.3 (Uses version
"hb") to 1.0.6 (uses version "hc").
1. Will I need to upgrade all nodes before performing streaming/repair?
2. Will it be possible to downgrade a node
On 2011-12-28 12:52 , Dominic Williams wrote:
Hmm interesting could be some variation on 3510 (which caught me out).
Actually after making some further reading of the changelog 2786 looks
like a likely culprit.
If I'm reading the jira correctly all versions < 0.8.8 and < 1.0.4 are
at risk of
Hi,
I Have a 3 node cluster running Cassandra 1.0.3 and using replication
factor=3.
Recently I've noticed that some previously deleted rows have started to
reappear for some reason. And now I wonder if this is a known issue with
1.0.3?
Repairs have been running every weekend (gc_grace is 1
Hi
While testing the proposed 1.0.3 version I got the following exception
while running repair: (StackOverflowError)
http://pastebin.com/raw.php?i=35Rt7ryB
The affected column family is denfined like this:
create column family FileStore
with comparator=UTF8Type and key_validation_class = '
On 09/22/2011 01:25 AM, aaron morton wrote:
*snip*
> When you start a repair it will repair will the other nodes it
> replicates data with. So you only need to run it every RF nodes. Start
> it one one, watch the logs to see who it talks to and then start it on
> the first node it does not talk to.
On 09/19/2011 04:26 AM, Anand Somani wrote:
> In my tests I have seen repair sometimes take a lot of space (2-3
> times), cleanup did not clean it, the only way I could clean that was
> using major compaction.
Do you remember with what version you saw these problems?
I've had the same problems wi
On 09/13/2011 05:21 PM, Jonathan Ellis wrote:
> More or less. NEWS.txt explains upgrade procedure in more detail.
When moving from 0.7.x to 0.8.5 do I need to scrub all sstables post
upgrade?
NEWS.txt doesn't mention anything about that but your comment here seems
to indicate so:
https://issues
On 04/05/2011 03:49 PM, Jonathan Ellis wrote:
> Sounds like https://issues.apache.org/jira/browse/CASSANDRA-2324
Yes, that sounds like the issue I'm having. Any chance for a fix for
this being backported to 0.7.x?
Anyway, I guess I might as well share the test case I've used to
reproduce this pr
Hi,
I have a 6 node 0.7.4 cluster with replication_factor=3 where "nodetool
repair keyspace" behaves really strange.
The keyspace contains three column families and about 60GB data in total
(i.e 30GB on each node).
Even though no data has been added or deleted since the last repair, a
repair tak
On 02/16/2011 03:54 PM, Jonathan Ellis wrote:
> It does look a lot like 1932. Make sure everything is really running
> 0.7.2, 0.7.0 can't read data files created by 0.7.1+.
All nodes are running 0.7.2
> If the versions are ok, take a snapshot, then compact, and see if the
> problem still occurs
org/jira/browse/CASSANDRA-1932 ?
Regards,
Jonas
> Hoping this is quick enough.
>
>
>
> 2011/2/15 Jonathan Ellis mailto:jbel...@gmail.com>>
>
> I can reproduce with your script. Thanks!
>
> 2011/2/15 Jonas Borgström <mailto:jona
Hi all,
While testing the new 0.7.1 release I got the following exception:
ERROR [ReadStage:11] 2011-02-15 16:39:18,105
DebuggableThreadPoolExecutor.java (line 103) Error in ThreadPoolExecutor
java.io.IOError: java.io.EOFException
at
org.apache.cassandra.db.columniterator.SSTableNamesIter
19 matches
Mail list logo
