Your questions are pretty fundamental. I recommend reading through the
documentation to get a better understanding of how Cassandra works.
Here's good documentation from DataStax:
http://www.datastax.com/docs/0.7/operations/clustering#adding-capacity
In a nutshell: you only bootstrap new nodes
Right.
On Sun, Apr 17, 2011 at 4:23 AM, David Boxenhorn wrote:
> Thanks, Jonathan. I think I understand now.
>
> To sum up: Everything would work, but if your only equality is on "type"
> (all the rest inequalities), it could be very inefficient.
>
> Is that right?
>
> On Thu, Apr 14, 2011 at 7:2
Very old. https://issues.apache.org/jira/browse/CASSANDRA-494
On Sun, Apr 17, 2011 at 7:49 PM, Tyler Hobbs wrote:
> You are correct, but this is also a limitation with the Thrift API -- it's
> not CQL specific. It turns out that deleting a slice of columns is
> difficult. There's an old JIRA ti
You are correct, but this is also a limitation with the Thrift API -- it's
not CQL specific. It turns out that deleting a slice of columns is
difficult. There's an old JIRA ticket somewhere that describes the issues.
On Sun, Apr 17, 2011 at 7:45 PM, Courtney Robinson wrote:
> Looking at the
Looking at the CQL spec, it doesn’t seem to be possible to delete a range of
columns for a given key without specifying the individual columns to be
removed, for e.g.
DELETE col1 .. col20 from CF WHERE KEY=
Am I correct in thinking so or have I missed that somewhere?
Shimi,
Chag Sameach. Yes, I know that a restart solves this, yet, I think this
is something that must be resolved as a result of 'nodetool move'.
Shalom.
-Original Message-
From: shimi
Reply-to: user@cassandra.apache.org
To: user@cassandra.apache.org
Subject: Re: Cassandra 0.7.4 Bug?
Da
I had the same thing.
Node restart should solve it.
Shimi
On Sun, Apr 17, 2011 at 4:25 PM, Dikang Gu wrote:
> +1.
>
> I also met this problem several days before, and I haven't got a solution
> yet...
>
>
> On Sun, Apr 17, 2011 at 9:17 PM, csharpplusproject <
> csharpplusproj...@gmail.com> wro
James: I feel like I understand what's going on in your code now based on
this discussion, and I'm ok with the fact that DURING a QW you can get
"transitional" results from a QR in another process (or either the before or
after state of the QW). But once the QW succeeds, you must get the new
value
Same process or not: only successful QR reads after successful QW will
behave with this guarantee.
/***
sent from my android...please pardon occasional typos as I respond @ the
speed of thought
/
On Apr 17, 2011 10:04 AM, "James Cipar" wrote:
> For a
> For a second, I thought this thread was saying I could see value(s) < new
> value(s) within the same process on the second read at quorum
That's exactly what I'm saying. Within a single process I see this behavior,
when reading with consistency_level=QUORUM
Read value 1
Read value 2
Read val
Cool, that is exactly what I was thinking/expecting, and I feel better about
the assumptions I've used in my refactor to move from MySQL -> cassandra.
I basically gave up on trying to force my code to assume (even at quorum):
-read value(s) for key from cassandra
-update/add/delete columns for key
William
The issue is regarding whether you will see A or B; with any guarantee of
either. The discussion implies no; until the QW is complete.
/***
sent from my android...please pardon occasional typos as I respond @ the
speed of thought
/
On Apr 17, 20
Successful reads after a successful write @Q have the property of once the
read is seen @ one Q, the same read will be seen at any other Q.
All others are details that will change with implementation; but,imo, are
not bugs.
James: in your case, I would think that you have not completed a successf
I'm pretty new to all of this, and I'm in the process of building my mental
model of Cassandra, but I'm still feeling better about this thread. The way
I figure it:
1. I'm trying to mutate the state of a key's column from A to B from a
thread somewhere (quorum)
2. I'm trying to read the state of a
The bug report suggests a test with write_consistency=ONE,
read_consistency=QUORUM. If one thread is writing at consistency level ONE,
and the other is reading at QUORUM, I wouldn't expect consistent reads. The
problem I was talking about is when both reads and writes are using QUORUM.
Also,
On Sun, Apr 17, 2011 at 6:42 AM, William Oberman
wrote:
> At first I was concerned and was going to +1 on a fix, but I think I was
> confused on one detail and I'd like to confirm it.
> -An unsuccessful write implies readers can see either the old or new value
Yes. Fixing CASSANDRA-2494 will si
Thanks Jonathan, I've filed a bug for this,
https://issues.apache.org/jira/browse/CASSANDRA-2494
Sean
On Sat, Apr 16, 2011 at 10:53 PM, Jonathan Ellis wrote:
> Tyler is correct, because Cassandra doesn't wait until repair writes
> are acked before the answer is returned. This is something we ca
I'm pretty new to Cassandra, but I've also written a client in C++ using the
thrift API directly. From what I've seen, wrapping writes in a retry loop is
pretty much mandatory because if you are pushing a lot of data around, you're
basically guaranteed to have TimedOutExceptions. I suppose wha
At first I was concerned and was going to +1 on a fix, but I think I was
confused on one detail and I'd like to confirm it.
-An unsuccessful write implies readers can see either the old or new value
?
The trick is using a library, it sounds like there is a period of time a
write is unsuccessful b
+1.
I also met this problem several days before, and I haven't got a solution
yet...
On Sun, Apr 17, 2011 at 9:17 PM, csharpplusproject <
csharpplusproj...@gmail.com> wrote:
> Often, I see the following behavior:
>
> (1) Cassandra works, all nodes are up etc
>
> (2) a 'move' operation is being
Often, I see the following behavior:
(1) Cassandra works, all nodes are up etc
(2) a 'move' operation is being run on one of the nodes
(3) following this 'move' operation, even after a couple of hours / days
where it is obvious the operation has ended, the node which had 'moved'
remains with a s
Thanks, Jonathan. I think I understand now.
To sum up: Everything would work, but if your only equality is on "type"
(all the rest inequalities), it could be very inefficient.
Is that right?
On Thu, Apr 14, 2011 at 7:22 PM, Jonathan Ellis wrote:
> On Thu, Apr 14, 2011 at 6:48 AM, David Boxenho
22 matches
Mail list logo
