For testing here and describing the question simple, I used two nodes to
build a cassandra(2.1.11) cluster (192.168.56.110 and 192.168.56.111), Now
I added one additional node(192.168.56.112) to this cluster, and I hope my
new ring balanced through using nodetool move command, but when I using the
Hi, all
After I added one node into the existed cluster, I want to use "nodetool
move" command:
../cassandra-2.1.11/bin/nodetool -h 192.168.56.110 move -2696407920004217295
I hope move -2696407920004217295 (existed in 192.168.56.110) into
192.168.56.112, but I got the following error:
[root@
Hi,
I recently upgraded from 2.1.12 to 3.2, and one issue I'm having is I can
no longer read certain rows from a table. A simple SELECT * FROM `table`
times out, only when the bad partition keys are reached. Trying to query
the affected partition keys directly also causes a timeout.
I think the S
+1 for doc update. I added some comments to the seemingly most relevant
Jira ticket to confirm best practice that we can then forward to the doc
team:
https://issues.apache.org/jira/browse/CASSANDRA-10699
-- Jack Krupansky
On Mon, Jan 25, 2016 at 1:12 PM, Eric Stevens wrote:
> It seems like th
Thank, I appreciate the correction to my understanding.
Sean Durity
From: Jeff Jirsa [mailto:jeff.ji...@crowdstrike.com]
Sent: Friday, January 22, 2016 1:04 PM
To: user@cassandra.apache.org
Subject: Re: Using TTL for data purge
"As I understand TTL, if there is a compaction of a cell (or row) w
It seems like this exact problem pops up every few weeks on this list. I
think the documentation does a dangerously bad job of describing the
limitations of CREATE TABLE...IF NOT EXISTS.
CREATE TABLE...IF NOT EXISTS is a dangerous construct because it seems to
advertise atomicity and isolation, n
Paulo is correct in saying that C* doesn't have a direct equivalent of
SecurityContextHolder. Authenticated principal info is retrievable from the
QueryState during query execution but a) this isn't available to every
method in the call chain and b) its scope is limited to the coordinator for
the r
That would work, but afaik Cassandra doesn't have an equivalent of
RequestContextHolder/SecurityContextHolder that is able to retrieve the
user/session of a given thread/request (maybe I'm wrong as I'm no auth
expert), so if these don't exist we'd need to add equivalent to those or do
it via MDC (s
Paulo,
Ideally - all the actions (security purposes, preserving completness of the
audit trail). How about this approach:
http://www.codelord.net/2010/08/27/logging-with-a-context-users-in-logback-and-spring-security/
?
Would that work? Or you would rather suggest to go MDC way?
Thanks,
Oleg
On
What kind of actions? nodetool/system actions or cql statements?
You could probably achieve identity-based logging with logback Mapped
Diagnostic Context (MDC - logback.qos.ch/manual/mdc.html), but you'd need
to patch your own Cassandra jars in many locations to provide that
information to the log
I want to try to re-phrase my question here... what I'm trying to achieve
is identity-based logging. I.e. every log message in file should start with
username of the user, who initiated this action. Would that be possible to
achieve? If so, can you give me a brief example?
Thanks,
Oleg
On Thu, J
You have to wait for schema agreement which most drivers should do by
default. At least have a check schema agreement method you can use.
https://datastax.github.io/java-driver/2.1.9/features/metadata/
The new cqlsh uses the python driver so the same should apply:
https://datastax.github.io/pyth
12 matches
Mail list logo
