We use describe_schema_versions thrift request:
/**
* for each schema version present in the cluster, returns a list of nodes at
that version.
* hosts that do not respond will be under the key
DatabaseDescriptor.INITIAL_VERSION.
* the cluster is all on the same version if the size of
Thank you for your detailed response!
On Jun 4, 2013 12:00 PM, "Shahab Yunus" wrote:
> Thanks Eric for the detailed explanation but can you point to a source or
> document for this restriction in CQL3 tables? Doesn't it take away the main
> feature of the NoSQL store? Or am I am missing something
Further the question below, the same thing seems to happen with
ColumnFamily: If I make a ColumnFamily, and then don't wait long enough,
an attempt to query it can fail if the particular node that gets queried
does not know about it yet. Is there something smarter to do than just
try/excep
Hello,
I am on a 64 Bit Ubuntu server 12.04 with 50% of memory free, 2 core CPU idling
(it is running on old hardware).
C* 1.2.4 has 1 local node. All worked until I bulk-loaded ~3K rows of 210
columns.
I created the data and index files off a CSV file as per more or less
http://www.datastax.
Thanks Eric for the detailed explanation but can you point to a source or
document for this restriction in CQL3 tables? Doesn't it take away the main
feature of the NoSQL store? Or am I am missing something obvious here?
Regards,
Shahab
On Tue, Jun 4, 2013 at 2:12 PM, Eric Stevens wrote:
> If
If this is a standard column family, not a CQL3 table, then using CQL3 will
not give you the results you expect.
>From cassandra-cli, let's set up some test data:
[default@unknown] create keyspace test;
[default@unknown] use test;
[default@test] create column family test;
[default@test] set test[
I run a 1.1 cluster and currently testing out a 1.2 cluster. I have
noticed that with 1.2 it switched to CQL3 which is acting differently than
I would expect. When I do "select key from \"cf\";" I get many many
duplicate keys. When I did the same with CQL 2 I only get the keys
defined. This see
On Jun 4, 2013, at 4:54 PM, horschi wrote:
> this sounds like the following issue:
>
> https://issues.apache.org/jira/browse/CASSANDRA-4905
Thanks! Another good reason to upgrade.
André
Hi,
this sounds like the following issue:
https://issues.apache.org/jira/browse/CASSANDRA-4905
cheers,
Ch
On Tue, Jun 4, 2013 at 5:50 PM, André Cruz wrote:
> 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 slow
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 plac
right ! authorizer was still set. I didn't know there was 2 different classes
for handling logging and access.
thanks
--
Cyril SCETBON
On Jun 4, 2013, at 12:00 PM, Michal Michalski
mailto:mich...@opera.com>> wrote:
How about authorizer? Is it set to
org.apache.cassandra.auth.AllowAllAuthorizer
"I see a lot of hinted handoff compactions too."
I might have not been clear enough, I see a lot of "compaction of
system.hints" that I interpret as being due to a lot of data that couldn't
reach their destination.
2013/6/4 Alain RODRIGUEZ
> Hi,
>
> I have an issue since switch to multiple DC.
Hi,
I deleted a column family from the keyspace and the error has gone
now.
Thanks for the reply.
--
Thanks & Regards,
Himanshu Joshi
On 05/31/2013 08:16 PM, S C wrote:
What was the node doing right before the ERROR? Can you post some more
log?
Thanks,
SC
--
Hi,
I have an issue since switch to multiple DC. I use AWS EC2 instances,
C*1.2.2, 12 nodes eu-west + 6 nodes us-east (new DC).
Datacenter: eu-west
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Owns Host ID
UN public ip 133.43 G
How about authorizer? Is it set to
org.apache.cassandra.auth.AllowAllAuthorizer?
Authenticator is responsible for handling logging in as a specific user.
Authorizer checks if logged user has appriopriate permissions.
M.
W dniu 04.06.2013 11:54, cscetbon@orange.com pisze:
Hi,
What's the
Hi,
What's the procedure to remove authentification ?
I have set authenticator to org.apache.cassandra.auth.AllowAllAuthenticator in
cassandra.yaml, however I still get
cqlsh:pns_fr> select * from t1 limit 1;
Bad Request: User anonymous has no SELECT permission on or any of
its parents
Perhaps
16 matches
Mail list logo