Hi all,
My team is trying to determine whether to use size-tiered or leveled
compaction for some tables in an app that will be moving to production
soon. using C* 2.1.
We have a few tables that look like this:
CREATE TABLE ks.counters (
id timeuuid PRIMARY KEY,
count counter
)
The
With CASSANDRA-12580: 16 hours (yes, hours!)
The improvement is not always dramatic (e.g. 8 hours instead of 39 hours on
another set) but still significant and valuable.
Moreover, considering that:
* repair is a mandatory operation in many use cases
* Paulo already made the patch for 2.1
* C* 2.1
s does the trick.
Best,
On Tue, Aug 9, 2016 at 8:50 AM, INDRANIL BASU wrote:
> Thanks Rajath. We have atleast 20 millions of records, so count(*) with
> limit and token is getting cumbersome.
> Yes using nodetool snapshot. I know there is a nodetool verify, but i m
> using C
Thanks Rajath. We have atleast 20 millions of records, so count(*) with limit
and token is getting cumbersome.
Yes using nodetool snapshot. I know there is a nodetool verify, but i m using
C * 2.1
Copy commands sometimes fails as well.
So any better easy mechanism?
Thanks and regards
Hi Indranil,
One approach is to do a row count on the original source table and the
table that is restored from backup. How are you backing up data ? I am
assuming you are issuing snapshot commands (either incremental or
otherwise).
I hope this helps.
- Rajath
Rajath Su
Hello,
How can we verify that cassandra data is backed up and restored correctly?
-- IB
Hi,
We recently discovered that there are some differences in gossip behavior
between C* 2.0 and C* 2.1. In some cases of network instability or a node
reboot, we can observe some behavioral differences from Cassandra/system.log.
2.0.17
We can observe this log of similar pattern in log :
DEBUG
YYY | | 999 | 1460088862025940
but with C*2.1 for the same insertions I get the row without TTL, therefore the
first row.
a| b | ttl(b) | writetime(b)
++-+---
: user@cassandra.apache.org
Objet : Re: [C*2.1]memtable_allocation_type: offheap_objects
We use them. No signs of stability problems in 2.1 that we’ve attributed to
offheap objects.
From: "aeljami@orange.com<mailto:aeljami@orange.com>"
Reply-To: "user@cassandra.a
We use them. No signs of stability problems in 2.1 that we’ve attributed to
offheap objects.
From: "aeljami@orange.com"
Reply-To: "user@cassandra.apache.org"
Date: Wednesday, March 9, 2016 at 1:54 AM
To: user
Subject: [C*2.1]memtable_allocation_type:
Check out Al's Tuning Guide. He discusses offheap objects.
https://tobert.github.io/pages/als-cassandra-21-tuning-guide.html
On Wed, Mar 9, 2016 at 1:54 AM wrote:
> Hi,
>
>
>
> offheap_objects was removed in releases 3.2.x then reintroduced in
> release 3.4: I vould like to know if someone ha
Hi,
offheap_objects was removed in releases 3.2.x then reintroduced in release
3.4: I vould like to know if someone has used offheap_objects in Cassandra 2.1:
stable or not, improvement observed or not...
Thanks.
Ahmed
_
, September 17, 2014 5:25 PM
To: user
Subject: Re: C 2.1
Thanks Rob for pointing me to that link. I haven't gone through all the JIRAs
but I guess it talks about adv & disadv of Secondary Index in Cassandra which I
understand by now but doesn't really talk about why the default impl
ng queries across the cluster. And... Lucene (underneath Solr) is
> optimal for queries that span multiple fields. DSE/Solr supports CQL3 wide
> rows (clustering columns.)
>
> -- Jack Krupansky
>
> *From:* Ram N
> *Sent:* Monday, September 15, 2014 4:34 PM
> *To:* user
> *
distributing
queries across the cluster. And... Lucene (underneath Solr) is optimal for
queries that span multiple fields. DSE/Solr supports CQL3 wide rows (clustering
columns.)
-- Jack Krupansky
From: Ram N
Sent: Monday, September 15, 2014 4:34 PM
To: user
Subject: Re: C 2.1
Jack,
Using Solr
On Mon, Sep 15, 2014 at 1:34 PM, Ram N wrote:
> Would be great to understand the design decision to go with present
> implementation on Secondary Index when the alternative is better? Looking
> at JIRAs is still confusing to come up with the why :)
>
http://mail-archives.apache.org/mod_mbox/incu
it's been done, but most of the
apps written for C* are greenfield or v2.0 rewrites.
Thanks, James Briggs
--
Cassandra/MySQL DBA. Available in San Jose area or remote.
From: Ram N
To: user
Sent: Monday, September 15, 2014 1:34 PM
Subject: Re: C
ert Coli
> *Sent:* Monday, September 15, 2014 11:07 AM
> *To:* user@cassandra.apache.org
> *Subject:* Re: C 2.1
>
> On Sat, Sep 13, 2014 at 3:49 PM, Ram N wrote:
>
>> Is 2.1 a production ready release?
>>
>
> https://engineering.eventbrite.com/what-version-of-cas
: Re: C 2.1
On Sat, Sep 13, 2014 at 3:49 PM, Ram N wrote:
Is 2.1 a production ready release?
https://engineering.eventbrite.com/what-version-of-cassandra-should-i-run/
Datastax Java driver - I get too confused with CQL and the underlying
storage model. I am also not clear on the
On Sat, Sep 13, 2014 at 3:49 PM, Ram N wrote:
> Is 2.1 a production ready release?
>
https://engineering.eventbrite.com/what-version-of-cassandra-should-i-run/
> Datastax Java driver - I get too confused with CQL and the underlying
> storage model. I am also not clear on the indexing stru
le in San Jose area or remote.
From: Ram N
To: user@cassandra.apache.org
Sent: Saturday, September 13, 2014 3:49 PM
Subject: C 2.1
Team,
I am pretty new to cassandra (with just 2 weeks of playing around with it on
and off) and planning a fresh deployment
Team,
I am pretty new to cassandra (with just 2 weeks of playing around with it
on and off) and planning a fresh deployment with 2.1 release. The
data-model is pretty simple for my use-case. Questions I have in mind are
Is 2.1 a production ready release?
Driver selection?
I played around wit
aemon.main(CassandraDaemon.java:544)
> Exception encountered during startup: null
>
> I do not now if it can help.
>
>
> Fabrice LARCHER
>
>
> 2014-07-18 7:23 GMT+02:00 Fabrice Larcher :
>
> Hello,
>>
>> I still experience a similar issue after a 'D
brice LARCHER
2014-07-18 7:23 GMT+02:00 Fabrice Larcher :
> Hello,
>
> I still experience a similar issue after a 'DROP KEYSPACE' command with C*
> 2.1-rc3. Connection to the node may fail after a 'DROP'.
>
> But I did not see this issue with 2.1-rc1 (
Hello,
I still experience a similar issue after a 'DROP KEYSPACE' command with C*
2.1-rc3. Connection to the node may fail after a 'DROP'.
But I did not see this issue with 2.1-rc1 (-> it seems like to be a
regression brought with 2.1-rc2).
Fabrice LARCHER
2014-07-17
Also https://issues.apache.org/jira/browse/CASSANDRA-7437 and
https://issues.apache.org/jira/browse/CASSANDRA-7465 for rc3, although the
CounterCacheKey assertion looks like an independent (though comparatively
benign) bug I will file a ticket for.
Can you try this against rc3 to see if the proble
This looks like https://issues.apache.org/jira/browse/CASSANDRA-6959, but
that was fixed for 2.1.0-rc1.
Is there any chance you can put together a script to reproduce the issue?
On Thu, Jul 10, 2014 at 8:51 AM, Pavel Kogan
wrote:
> It seems that memtable tries to flush itself to SSTable of not
It seems that memtable tries to flush itself to SSTable of not existing
keyspace. I don't know why it is happens, but probably running nodetool
flush before drop should prevent this issue.
Pavel
On Thu, Jul 10, 2014 at 4:09 AM, Fabrice Larcher
wrote:
> Hello,
>
> I am using the 'development'
Hello,
I am using the 'development' version 2.1-rc2.
With one node (=localhost), I get timeouts trying to connect to C* after
running a 'DROP KEYSPACE' command. I have following error messages in
system.log :
INFO [SharedPool-Worker-3] 2014-07-09 16:29:36,578
MigrationManager.java:319 - Drop K
29 matches
Mail list logo
