On Aug 27, 2012, at 4:11 PM, Eric Evans eev...@acunu.com wrote:
Since I am not in a position to unsubscribe anyone, I can only assume
that I have received this message in error. As per the frightening
legalese quoted above, I hereby notify you by email, and will now
proceed to destroy the
On Aug 27, 2012, at 4:16 PM, Nikolaidis, Christos cnikolai...@epsilon.com
wrote:
No worries :-) I was replying to the list so whoever manages it can
unsubscribe me.
That's not how you unsubscribe. You need to send an email to
user-unsubscr...@cassandra.apache.org.
André
I'm also having AssertionErrors.
ERROR [ReadStage:51687] 2012-09-10 14:33:54,211 AbstractCassandraDaemon.java
(line 134) Exception in thread Thread[ReadStage:51687,5,main]
java.io.IOError: java.io.EOFException
at
On Sep 12, 2012, at 1:53 AM, Jason Axelson ja...@engagestage.com wrote:
That looks like something that I've run into as well on previous
versions of Cassandra. Our workaround was to not drop a keyspace and
the re-use it (which we were doing as part of a test suite).
Thanks, I'll keep that in
Hello.
I have a schema that represents a filesystem and one example of a Super CF is:
CF FilesPerDir: (DIRNAME - (FILENAME - (attribute1: value1, attribute2:
value2))
And in cases of directory moves, I have to fetch all files of that directory
and subdirectories. This implies one cassandra
On Sep 17, 2012, at 3:04 AM, aaron morton aa...@thelastpickle.com wrote:
I have a schema that represents a filesystem and one example of a Super CF
is:
This may help with some ideas
http://www.datastax.com/dev/blog/cassandra-file-system-design
In general we advise to avoid Super Columns
On Sep 17, 2012, at 3:04 AM, aaron morton aa...@thelastpickle.com wrote:
I have a schema that represents a filesystem and one example of a Super CF
is:
This may help with some ideas
http://www.datastax.com/dev/blog/cassandra-file-system-design
Could you explain the usage of the sentinel?
On Sep 18, 2012, at 3:06 AM, aaron morton aa...@thelastpickle.com wrote:
select filename from inode where filename ‘/tmp’ and filename ‘/tmq’ and
sentinel = ‘x’;
Wouldn't that return files from directories '/tmp1', '/tmp2', for example? I
thought the goal was to return files and
On Nov 7, 2012, at 2:12 AM, Chuan-Heng Hsiao hsiao.chuanh...@gmail.com wrote:
I assume you are using cassandra-cli and connecting to some specific node.
You can check the following steps:
1. Can you still reproduce this issue? (not - maybe the system/node issue)
Yes. I can reproduce this
On Nov 7, 2012, at 12:15 PM, André Cruz andre.c...@co.sapo.pt wrote:
This error also happens on my application that uses pycassa, so I don't think
this is the same bug.
I have narrowed it down to a slice between two consecutive columns. Observe
this behaviour using pycassa
with wide rows littered
with column tombstones (you could check with dumping the sstables...)
Just a thought...
Josep M.
On Thu, Nov 8, 2012 at 12:23 PM, André Cruz andre.c...@co.sapo.pt wrote:
These are the two columns in question:
= (super_column=13957152-234b-11e2-92bc-e0db550199f4
On Nov 11, 2012, at 12:01 AM, Binh Nguyen binhn...@gmail.com wrote:
FYI: Repair does not remove tombstones. To remove tombstones you need to run
compaction.
If you have a lot of data then make sure you run compaction on all nodes
before running repair. We had a big trouble with our system
On Nov 13, 2012, at 8:54 AM, aaron morton aa...@thelastpickle.com wrote:
I don't think that statement is accurate.
Which part ?
Probably this part:
After running a major compaction, automatic minor compactions are no longer
triggered, frequently requiring you to manually run major compactions
a
counter update occurs or is just invalidated?
Best regards,
André Cruz
On 29/12/2012, at 16:59, rohit bhatia rohit2...@gmail.com wrote:
Reads during a write still occur during a counter increment with CL ONE, but
that latency is not counted in the request latency for the write. Your local
node write latency of 45 microseconds is pretty quick. what is your
Does anyone see anything wrong in these settings? Anything to account for a 8s
timeout during a counter increment?
Thanks,
André
On 31/12/2012, at 14:35, André Cruz andre.c...@co.sapo.pt wrote:
On Dec 29, 2012, at 8:53 PM, Mohit Anchlia mohitanch...@gmail.com wrote:
Can you post gc
and queries to that row are
efficient again.
Thanks,
André Cruz
On Jan 10, 2013, at 8:01 PM, aaron morton aa...@thelastpickle.com wrote:
So, one column represents a file in that directory and it has no value.
Just so I understand, the file contents are *not* stored in the column value ?
No, on that particular CF the columns are SuperColumns with 5 sub
Thanks,
André Cruz
Hello.
In my application it sometimes happens that I execute a multiget (I use
pycassa) to fetch data that I have just inserted. I use quorum writes and
reads, and my RF is 3.
I've noticed that sometimes (1 in 1000 perhaps) an insert followed (300ms
after) by a multiget will not find the just
Yes, same thread. Cassandra 1.1.5 btw.
Sent from my iPhone
On 10/03/2013, at 16:47, Dave Brosius dbros...@mebigfatguy.com wrote:
is the read and write happening on the same thread?
On 03/10/2013 12:00 PM, André Cruz wrote:
Hello.
In my application it sometimes happens that I execute
On 10/03/2013, at 16:49, Chuan-Heng Hsiao hsiao.chuanh...@gmail.com wrote:
However, my guess is that cassandra only guarantee that
if you successfully write and you successfully read, then quorum will
give you the latest data.
That's what I thought, but that's not what I'm seeing all the time.
On Mar 11, 2013, at 5:02 PM, Tyler Hobbs ty...@datastax.com wrote:
What kind of inserts and multiget queries are you running?
I use the ColumnFamily objects. The pool is initialised with
write_consistency_level=ConsistencyLevel.QUORUM.
The insert is a regular insert, so the QUORUM is used.
for compactions than I would if the SSTables were
larger.
Am I missing something here? Is this the best way to deal with this (abnormal)
use case?
Thanks and best regards,
André Cruz
smime.p7s
Description: S/MIME cryptographic signature
Hello.
Since I upgraded to Cassandra 1.1, I get the following error when
trying to delete a CF. After this happens the CF is not accessible
anymore, but I cannot create another one with the same name until I
restart the server.
INFO [MigrationStage:1] 2012-05-07 18:10:12,682
On May 10, 2013, at 7:24 PM, Robert Coli rc...@eventbrite.com wrote:
1) What version of Cassandra do you run, on what hardware?
1.1.5 - 6 nodes, 32GB RAM, 300GB data per node, 900GB 10k RAID1, Intel(R)
Xeon(R) CPU E5-2609 0 @ 2.40GHz.
2) What consistency level do you write at? Do you do
Hello.
I deleted a lot of data from one of my CFs, waited the gc_grace_period, and as
the compactions were deleting the data slowly, ran a major compaction on that
CF. It reduced the size to what I expected. I did not run a major compaction on
the other 2 nodes (RF = 3) before repairs took
On Jun 4, 2013, at 4:54 PM, horschi hors...@gmail.com wrote:
this sounds like the following issue:
https://issues.apache.org/jira/browse/CASSANDRA-4905
Thanks! Another good reason to upgrade.
André
Hello.
I have a cluster with 3 nodes and RF is 3. I've noticed that when I run a
repair on a node (I don't use -pr), all nodes are involved.
So, does this mean the other nodes are repaired as well? Do I still need to
run repair on the other 2 nodes inside the gc_grace_period?
Thanks,
André
threads were stopped: 0.0264510 seconds
Thanks for the help,
André Cruz
signature.asc
Description: Message signed with OpenPGP using GPGMail
On Sep 24, 2013, at 5:05 AM, 谢良 xieli...@xiaomi.com wrote:
it looks to me that MaxTenuringThreshold is too small, do you have any
chance to try with a bigger one, like 4 or 8 or sth else?
MaxTenuringThreshold=1 seems a bit odd, yes. But it is the Cassandra default,
maybe there is a reason
On Sep 24, 2013, at 5:18 AM, Mohit Anchlia mohitanch...@gmail.com wrote:
Your ParNew size is way too small. Generally 4GB ParNew (-Xmn) works out best
for 16GB heap
I was afraid that a 4GB ParNew would cause Young GCs to take too long. I'm
going to test higher ParNew values.
Thanks,
André
Hello.
I have been looking into the memory patterns of Cassandra (1.1.5), and I have a
suggestion that I haven't seen discussed here.
Cassandra is configured by default with a GC tailored for pauseless operation
instead of throughput, and this makes sense since it needs to answer client
,
André Cruz
replica has the
original value (!), with the original timestamp…
Is there a logical explanation for this behaviour?
Thank you,
André Cruz
On 14 Nov 2014, at 18:29, Michael Shuler mich...@pbandjelly.org wrote:
On 11/14/2014 12:12 PM, André Cruz wrote:
Some extra info. I checked the backups and on the 8th of November, all 3
replicas had the tombstone of the deleted column. So:
1 November - column is deleted - gc_grace_period
On 14 Nov 2014, at 18:44, André Cruz andre.c...@co.sapo.pt wrote:
On 14 Nov 2014, at 18:29, Michael Shuler mich...@pbandjelly.org wrote:
On 11/14/2014 12:12 PM, André Cruz wrote:
Some extra info. I checked the backups and on the 8th of November, all 3
replicas had the tombstone
On 18 Nov 2014, at 01:08, Michael Shuler mich...@pbandjelly.org wrote:
André, does `nodetool gossipinfo` show all the nodes in schema agreement?
Yes:
$ nodetool -h XXX.XXX.XXX.XXX gossipinfo |grep -i schema
SCHEMA:8ef63726-c845-3565-9851-91c0074a9b5e
, is there a easy way to fix this? Shouldn’t repair also propagate this
zombie column to the other nodes?
Thank you and best regards,
André Cruz
On 19 Nov 2014, at 11:37, André Cruz andre.c...@co.sapo.pt wrote:
All the nodes were restarted on 21-23 October, for the upgrade (1.2.16 -
1.2.19) I mentioned. The delete happened after. I should also point out that
we were experiencing problems related to CASSANDRA-4206 and CASSANDRA-7808
On 19 Nov 2014, at 19:53, Robert Coli rc...@eventbrite.com wrote:
My hunch is that you originally triggered this by picking up some obsolete
SSTables during the 1.2 era. Probably if you clean up the existing zombies
you will not encounter them again, unless you encounter another obsolete
On 21 Nov 2014, at 19:01, Robert Coli rc...@eventbrite.com wrote:
2- Why won’t repair propagate this column value to the other nodes? Repairs
have run everyday and the value is still missing on the other nodes.
No idea. Are you sure it's not expired via TTL or masked in some other way?
On 24 Nov 2014, at 18:54, Robert Coli rc...@eventbrite.com wrote:
But for any given value on any given node, you can verify the value it has in
100% of SStables... that's what both the normal read path and repair should
do when reconciling row fragments into the materialized row? Hard to
On 26 Nov 2014, at 19:07, Robert Coli rc...@eventbrite.com wrote:
Yes. Do you know if 5748 was created as a result of compaction or via a flush
from a memtable?
It was the result of a compaction:
INFO [CompactionExecutor:22422] 2014-11-13 13:08:41,926 CompactionTask.java
(line 262)
44 matches
Mail list logo
