You should probably make a new thread for this. This is an announcement
for a new Cassandra release.
On Mon, Mar 16, 2015 at 10:34 AM, jean paul wrote:
> OK.
> I have tens of nodes in my cluster. i'd like to get the states of these
> nodes(alive, not etc ..). (it is just a first step to test ca
Just send an email to user-unsubscr...@cassandra.apache.org
It will respond back if there were any issues.
On Thu, Feb 19, 2015 at 12:06 PM, Steve Ryder wrote:
> Unsubscribe
>
>
>
> What is it going to take to get my address off this list? You’re
> instructions are not working for me.
>
>
>
>
Astyanax isn't deprecated; that user is wrong and is downvoted--and has a
comment mentioning the same.
What you're describing doesn't sound like you need a data store at all; it
/sounds/ like you need a file store. Why not use S3 or similar to store
your images? What benefits are you expecting t
Furthermore, people ask questions about monitoring and management utilities
for Cassandra all the time--this is in the same vein.
On Tue, Oct 28, 2014 at 8:52 AM, Ken Hancock
wrote:
> Your criteria for what is appropriate for production may differ from
> others, but it's equally incorrect of you
le ID" from the table's files to see if
there's more than one for a given table. If there are, it means there are
multiple sstables that can be compacted.
On Mon, Oct 20, 2014 at 12:03 PM, Robert Coli wrote:
> On Mon, Oct 20, 2014 at 10:24 AM, Redmumba wrote:
>
>> I ran i
Based on lots of good feedback from this list, I moved to a date-based set
of tables, which a unique per day. However, I am manually compacting
previous days' tables to keep the amount of files required to be opened to
a minimum.
I ran into an interesting issue--when I run compaction on a table t
Using query tracing, as many have recommended here, will tell you where the
query is spending it's time. If there's a bottleneck somewhere, you'll see
it there.
On Tue, Sep 2, 2014 at 6:57 AM, eduardo.cusa <
eduardo.c...@usmediaconsulting.com> wrote:
> Hi Thanks for the response.
>
> For that
Just to chime in, I also ran into this issue when I was migrating to the
Datastax client. Instead of reusing the session, I was opening a new
session each time. For some reason, even though I was still closing the
session on the client side, I was getting the same error.
Plus, the only way I could
The Cassandra wiki is notoriously out of date. The Datastax documentation
is generally more correct on most things.
On Fri, Aug 1, 2014 at 9:27 AM, Donald Smith <
donald.sm...@audiencescience.com> wrote:
> According to datastax’s documentation at
> http://www.datastax.com/documentation/cassand
After much help from this list, I've moved to a date-based table schema.
Once a date has passed, there will be very little, if any, writing to that
table. As such, I have a nightly process that goes through a performs a
major compaction to move it down to a single table.
I've tried manipulating t
A lot of the information about the compaction strategies would be
incredibly useful in the docs as well:
http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra
On Thu, Jul 24, 2014 at 9:45 AM, Peter Lin wrote:
> for example, this old blog entry from way back in 2012
>
> http://
Obvious troll is obvious.
On Wed, Jul 23, 2014 at 3:50 PM, jcllings wrote:
> Keep seeing refs to C*.
>
> I assume that C* == Cassandra? IMHO not a good ref to use what with C,
> C++, C#. A language called C* can't be far behind assuming it doesn't
> already exist.
> ;-)
>
> Jim C.
>
>
Thank you both!
Robert, I read through the bug--it sounds like this behavior has been fixed
(or the impact reduced) in 2.1, but given that our data is pretty uniform
(with no overlap between rows/values), it doesn't look like we'll suffer
from that. At least, that's what I understood from the bug
I am having an issue on multiple machines where it's simply filling up the
disk space during what I can only assume is a compaction. For example, the
average node cluster-wide is around 900GB according to DSE
OpsCenter--however, after coming in after the three day weekend, I noticed
that there wer
The current RPM spec actually has a dependency on "java", which is not a
package--rather, it is a piece of metadata called "provides" that multiple
packages can share. For example, Oracle's JVM, OpenJDK, ICedTea, etc.--can
all be used to fulfill the requirement for "java".
There is a reverse-engi
36 AM, Robert Coli wrote:
> On Tue, Jun 17, 2014 at 11:26 AM, Redmumba wrote:
>
>> Alright, that's perfectly reasonable--I'm not quite sure which settings
>> will affect the number of writes. I have set the compaction throughput in
>> the past to 999, but I'm not
1:19 AM, Robert Coli wrote:
> On Tue, Jun 17, 2014 at 11:14 AM, Redmumba wrote:
>
>> I have a very write heavy workload, and noticed that the default settings
>> for min_ and max_compaction_threshold resulted in around 47k files in my
>> table directory. In general, files
I have a very write heavy workload, and noticed that the default settings
for min_ and max_compaction_threshold resulted in around 47k files in my
table directory. In general, files were fairly small (ranging in the
single digits of megabytes to gigabytes).
What is the best way to tweak these val
his will help the community help you a little better.
>
> Jonathan Lacefield
> Solutions Architect, DataStax
> (404) 822 3487
> <http://www.linkedin.com/in/jlacefield>
>
> <http://www.datastax.com/cassandrasummit14>
>
>
>
> On Mon, Jun 9, 2014 at 7:51 PM, Redmumba
s that you would like to serve via
> Cassandra. This will help the community help you a little better.
>
> Jonathan Lacefield
> Solutions Architect, DataStax
> (404) 822 3487
> <http://www.linkedin.com/in/jlacefield>
>
> <http://www.datastax.com/cassandrasummit14&
If I keep 60 days worth of
auditing data, for example, I'd need to query all 60 tables--can I do that
smoothly? Or do I have to have 60 different select statements? Is there a
way for me to run the same query against all the tables?
On Mon, Jun 9, 2014 at 3:42 PM, Redmumba wrote:
>
ver, your query does not require index *IF* you provide a row key -
> you can use "<" or ">" like you did for the date column, as long as you
> refer to a single row. However, if you don't provide it, it's not going to
> work.
>
> M.
>
> Ki
I have a table with a timestamp column on it; however, when I try to query
based on it, it fails saying that I must use ALLOW FILTERING--which to me,
means its not using the secondary index. Table definition is (snipping out
irrelevant parts)...
CREATE TABLE audit (
> id bigint,
> date ti
g 1 table per day, and dropping the tables you don't
> need once you're done.
>
>
> On Wed, Jun 4, 2014 at 10:44 AM, Redmumba wrote:
>
>> Sorry, yes, that is what I was looking to do--i.e., create a
>> "TopologicalCompactionStrategy" or similar.
cause they data from January 1st
> to exist in only one SSTable and not have data from other days in the
> SSTable as well? Are you talking about making a new compaction strategy
> that creates SSTables by day?
>
>
>
> On June 4, 2014 at 1:36:10 PM, Redmumba (redmu...@gmail.com
’t be able to write out a new SSTable with the older
> information compacted out. Also, there is more to an SSTable than just
> data, the SSTable could have tombstones and other relics that haven’t been
> cleaned up from nodes coming or going.
>
>
>
>
> On June 4, 2014 at 1:10:58 P
nt toolset
before I actually dived in and started tinkering.
Andrew
On Wed, Jun 4, 2014 at 10:04 AM, Russell Bradberry
wrote:
> hmm, I see. So something similar to Capped Collections in MongoDB.
>
>
>
> On June 4, 2014 at 1:03:46 PM, Redmumba (redmu...@gmail.com) wrote:
>
&g
verbosity of auditing, etc.. I'd like to
maximize the disk space--not optimize the cleanup process.
Andrew
On Wed, Jun 4, 2014 at 9:47 AM, Russell Bradberry
wrote:
> You mean this:
>
> https://issues.apache.org/jira/browse/CASSANDRA-5228
>
> ?
>
>
>
> On Ju
Good morning!
I've asked (and seen other people ask) about the ability to drop old
sstables, basically creating a FIFO-like clean-up process. Since we're
using Cassandra as an auditing system, this is particularly appealing to us
because it means we can maximize the amount of auditing data we can
Repairing the range is an expensive operation and don't forget--just
because a node is down does not mean it's dead. I take nodes down for
maintenance all the time--maybe there was a security update that needed to
be applied, for example, or perhaps a kernel update. There are a multitude
of reaso
Another thing to keep in mind--even core pieces like the Linux kernel are
dominated by corporations. Less than 20% of contributions last year were
made by non-corporate sponsored contributors. Obviously, this is a bit
different, but many parts of the open source world depend on upstream
contribut
s might help
>
>
> On 04/17/2014 06:06 PM, Redmumba wrote:
>
>> Good afternoon,
>>
>> I'm attempting to integrate the metrics generated via JMX into our
>> internal
>> framework; however, the information for several of the metrics includes a
>> One
In the system we're using, we have a large fleet of servers constantly
appending time-based data to our database--it's largely writes, very few
reads (it's auditing data). However, our cluster max space is around 80TB,
and we'd like to maximize how much data we can retain.
One option is to delete
ble: and
> default_time_to_live=86400 .
>
>
>
> *From:* Redmumba [mailto:redmu...@gmail.com]
> *Sent:* Monday, April 28, 2014 12:51 PM
> *To:* user@cassandra.apache.org
> *Subject:* Re: Cassandra data retention policy
>
>
>
> Have you looked into using a TTL? You can set this
Have you looked into using a TTL? You can set this per insert
(unfortunately, it can't be set per CF) and values will be tombstoned after
that amount of time. I.e.,
INSERT INTO VALUES ... TTL 15552000
Keep in mind, after the values have expired, they will essentially become
tombstones-
Good afternoon,
I'm attempting to integrate the metrics generated via JMX into our internal
framework; however, the information for several of the metrics includes a
One/Five/Fifteen-minute "rate", with the RateUnit in "SECONDS". For
example:
$>get -b
> org.apache.cassandra.metrics:name=Latency,
Cassandra 1.2.15, using commodity hardware.
On Tue, Apr 1, 2014 at 6:37 PM, Robert Coli wrote:
> On Tue, Apr 1, 2014 at 3:24 PM, Redmumba wrote:
>
>> Is it possible to have true "drop in" node replacements? For example, I
>> have a cluster of 51 Cassandra nodes
Is it possible to have true "drop in" node replacements? For example, I
have a cluster of 51 Cassandra nodes, 17 in each data center. I had one
host go down on DC3, and when it came back up, it joined the ring, etc.,
but was not receiving any data. Even after multiple restarts and forcing a
repa
I currently have a group of about 51 hosts on Cassandra 1.2.15, 17 in each
EC2 AZ (us-east-1a, 1d, 1e). These are m2.4xlarge machines, so they have
basically a 10G partition on /, and then two ~800G partitions on /dev/sdb
and /dev/sdc.
When I first started, I was expecting the commitlog to take u
39 matches
Mail list logo
