No problem. IS there a JIRA ticket already for this?
On Mon, Aug 24, 2015 at 6:06 AM, Jonathan Haddad j...@jonhaddad.com wrote:
Can you post your findings to JIRA as well? Would be good to see some
real numbers from production.
The refactor of the storage engine (8099) may completely
At this point, it is only/automatically managed by cassandra, but if you’re
clever with mount points you can probably work around the limitation.
From: Ahmed Eljami
Reply-To: user@cassandra.apache.org
Date: Tuesday, August 25, 2015 at 2:09 AM
To: user@cassandra.apache.org
Subject: How can
What an excellent explanation!!, thank you a lot.
By the way, I do not understand why in lightweight transactions in
Cassandra has round-trip commit/acknowledgment?
For me, I think we can commit the value within phase propose/accept. Do you
agree? If not agree can you explain why we need
So you meant that the older ballot will not only reject in round-trip1
(prepare/promise), it also can be reject in propose/accept round-trips2, Is
that correct?
Yes.
You Said : Or more precisely, you got step 8 wrong: when a replica
PROMISE, the promise is not that they won't promise a
The rationale of the last commit/ack phase is to set the chosen value (here
the mutation) in a durable storage (here into Cassandra) and reset this
value to allow another round of Paxos.
More explanation in this blog post:
http://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0
Hi, anybody knows how to resolve this problem?
2015-08-23 1:35 GMT+08:00 joseph gao gaojf.bok...@gmail.com:
I'm using cassandra 2.1.7 and datastax java drive 2.1.6
Here is the problem:
I use PrepareStatement for query like : SELECT * FROM somespace.sometable
where id = ?
And I Cached the
I have the same problem.
When I bulk load my data, I have a problem with Cassandra Datastax driver.
dependency
groupIdcom.datastax.cassandra/groupId
artifactIdcassandra-driver-core/artifactId
version2.1.4/version !-- Driver 2.1.6, 2.1.7.1 gives problems. Some data
is lost. --
/dependency
With
I'm trying to run nodetool from one node, connecting to another. I
can successfully connect to the majority of nodes in my ring, but two
nodes throw the following error.
nodetool: Failed to connect to 'IP:7199' NoSuchObjectException: 'no
such object in table'.
Any idea why this is happening?
When I defines several file_data_directories in cassandra.yaml, would it be
possible to specify the location keyspace and tables ? or it is * only* and
*automatically* managed by Cassandra.
Thx.
--
Ahmed ELJAMI
Hi, I am facing the same issue on 2.0.16.
Did you solve this ? How ?
I plan to try a rolling restart and see if gossip state recover from this.
C*heers,
Alain
2015-06-19 11:40 GMT+02:00 曹志富 cao.zh...@gmail.com:
I have a C* 2.1.5 with 24 nodes.A few days ago ,I have remove a node from
this
On Tue, Aug 25, 2015 at 2:44 PM, Bryan Cheng br...@blockcypher.com wrote:
[2015-08-25 21:36:43,433] It is not possible to mix sequential repair and
incremental repairs.
Is this a limitation around a specific configuration? Or is it generally
true that incremental and sequential repairs are
On 08/25/2015 02:19 PM, Jason Lewis wrote:
I'm trying to run nodetool from one node, connecting to another. I
can successfully connect to the majority of nodes in my ring, but two
nodes throw the following error.
nodetool: Failed to connect to 'IP:7199' NoSuchObjectException: 'no
such object
Hi folks,
To achieve linearizable consistency in Cassandra, there are four
round-trips must be performed:
1. Prepare/promise
2. Read/result
3. Propose/accept
*4. **Commit/acknowledgment *
In the last phase in Paxos protocol (white paper), there is decide phase
Thanks Robert! To clarify, you're referring to the process using
sstablerepairedset to mark sstables as repaired after a full repair with
autocompaction off? We're in the process of doing that throughout our
cluster now.
On Tue, Aug 25, 2015 at 3:30 PM, Robert Coli rc...@eventbrite.com wrote:
On Tue, Aug 25, 2015 at 4:05 PM, Bryan Cheng br...@blockcypher.com wrote:
Thanks Robert! To clarify, you're referring to the process using
sstablerepairedset to mark sstables as repaired after a full repair with
autocompaction off? We're in the process of doing that throughout our
cluster
Hey all,
Got a question about incremental repairs, a quick google search turned up
nothing conclusive.
In the docs, in a few places, sequential, incremental repairs are mentioned.
From
http://docs.datastax.com/en/cassandra/2.1/cassandra/operations/ops_repair_nodes_c.html
(indirectly):
You can
Hi folks,
Cassandra provides *linearizable consistency (CAS, Compare-and-Set) by
using Paxos 4 round-trips as following*
*1. **Prepare/promise*
*2. **Read/result*
*3. **Propose/accept*
*4. **Commit/acknowledgment *
Assume we have an application for resistering new
That scenario cannot happen. More specifically, your step 12 cannot happen
if
step 8 has happen. Or more precisely, you got step 8 wrong: when a replica
PROMISE, the promise is not that they won't promise a ballot older than 2,
it's that they won't accept a ballot older than 2. Therefore, after
OK, I see.
So you meant that the older ballot will not only reject in round-trip1
(prepare/promise), it also can be reject in propose/accept round-trips2, Is
that correct?
You Said : Or more precisely, you got step 8 wrong: when a replica PROMISE,
the promise is not that they won't promise a
19 matches
Mail list logo
