“replica” here means “a node that has a copy of the data for a given
partition”. The scenario being discussed hear is CL > 1. In this case,
rather than using up network and processing capacity sending all the data
from all the nodes required to meet the consistency level, Cassandra gets
the full da
Yes, I think for my case, at least two nodes need to be contacted to get the
full set of data.
But another thing comes up about dynamic snitch. It's the wrapped snitch and
enabled by default and it'll choose the fastest/closest node to read data from.
Another post is about this.
http://www.da
If your read operation requires data from multiple partitions and the
partitions are spread across multiple nodes then the coordinator has the
job of contacting the multiple nodes to get the data and return to the
client. So, in your scenario, if you did a select * from table (with no
where clause)
Hi Ben,
Thanks for the quick response.
It's clear about the example for single row/partition. However, normally
data are not single row. Then for this case, I'm still confused.
http://docs.datastax.com/en/cassandra/2.1/cassandra/dml/architectureClientRequestsRead_c.html
The link abov
Each individual read (where a read is a single row or single partition)
will read from one node (ignoring read repairs) as each partition will be
contained entirely on a single node. To read the full set of data, reads
would hit at least two nodes (in practice, reads would likely end up being
dist
Hi there,
I have a question about the replica and replication factor.
For example, I have a cluster of 6 nodes in the same data center.
Replication factor RF is set to 3 and the consistency level is default 1.
According to this calculator http://www.ecyrd.com/cassandracalculator/, every
I put together a shell wrapper around nodetool/sstableloader that I’ve been
running for the past few years –
https://github.com/AppliedInfrastructure/cassandra-snapshot-tools
Always seemed to work well for these kinds of scenarios… Never really had
to think about where SSTables were on the filesy
I am running
cqlsh 5.0.1 | Cassandra 2.1.11.969 | DSE 4.8.3 | CQL spec 3.2.1 |
Doing the below command seemed to work
sstableloader -d
Thanks for the help!
From: Jeff Jirsa [mailto:jeff.ji...@crowdstrike.com]
Sent: Monday, September 19, 2016 5:49 PM
To: user@cassandra.apache.org
Subject: Re:
Something like that, depending on your version (which you didn’t specify).
Note, though, that sstableloader is notoriously picky about the path to
sstables. In particular, it really really really wants a directory structure
that matches the directory structure on disk, and wants you to be at
So if I rsync the the sstables say from source node 1 and source node 2 to
target node 1. Would I just run the command like this?
From target host
sstableloader -d
From: Jeff Jirsa [mailto:jeff.ji...@crowdstrike.com]
Sent: Monday, September 19, 2016 4:45 PM
To: user@cassandra.apache.org
Subjec
You can ship the sstables to the destination (or any other server with
Cassandra binary tools installed) via ssh/rsync and run sstableloader on the
destination cluster as well.
From: Justin Sanciangco
Reply-To: "user@cassandra.apache.org"
Date: Monday, September 19, 2016 at 2:49 PM
To: "
CQLSH COPY FROM / COPY TO? There are some significant performance
improvements in recent versions:
https://issues.apache.org/jira/browse/CASSANDRA-11053
On Tue, 20 Sep 2016 at 07:49 Justin Sanciangco
wrote:
> Hello,
>
>
>
> Assuming I can’t get ports opened from source to target cluster to run
>
The reason for large partitions is that the partition key is just the uuid of
the target node
More recent (I think 2.2) don't have this problem since they write hints to the
file system as per the commit log
Sadly the large partitions make things worse when you are hinting hence
presumably und
Hello,
Assuming I can't get ports opened from source to target cluster to run
sstableloader, what methods can I use to load a single keyspace from one
cluster to another cluster of different size?
Appreciate the help...
Thanks,
Justin
Hi Pranay,
I'll try to answer the more precisely as I can.
Note that what I'm going to explain is valid only for reads, write requests
work differently.
I'm assuming you have only one DC.
1. The coordinator gets a list of sorted live replicas. Replicas are
sorted by proximity.
(I'm not
Hi Josh,
I too have had this issue on several clusters I manage, particularly when
making schema changes. The worst part is, those nodes don't restart, and
the tables can't be dropped. Basically you have to rebuild your whole
cluster which often takes down time. Others have seen this on 3.0.x and i
i always have this doubt when a cassandra node got a read request for local
quorum consistency does coordinator node asks all nodes with replicas in
that DC for response or just the fastest responding nodes to it who's count
satisfy the local quorum.
In this case RF is 3 Cassandra timeout during r
I have an automated tool we created which will create a keyspace, its tables,
and add indexes in solr. But when I run the tool even for a new keyspace I end
up getting ghost tables with the name “”. If I look in system_schema.tables I
see a bunch of tables all named
(\x00\x00\x00\x00\x00\x00\
Thanks for the input. I just kicked off another repair for one keyspace.
Per the log, there are 1536 ranges to repair through. This makes sense:
there are 6 nodes in the cluster, each having 256 token ranges, so 6*256 =
1536. So far, it is averaging 1 range per minute. So repair the keyspace
will t
I was able to see most used partitions but the nodes with less load are
serving more read and write requests for that particular partitions when
compared to nodes with high load, how can i find if these nodes are serving
as co-coordinators for those read and write requests ?? how can i find the
tok
On Wed, Sep 14, 2016 at 1:49 PM, jerome wrote:
> I was curious if anyone had any kind of statistics or ballpark figures on
> how long it takes information to propagate through a cluster with Gossip?
> I'm particularly interested in how fast information about the liveness of a
> node spreads. For e
Hai Jeff,
Thank, we are using RF 3 and cassandra version 2.1.8.
Thanks
Pranay.
On Mon, Sep 19, 2016 at 10:55 AM, Jeff Jirsa
wrote:
> Is your replication_factor 2? Or is it 3? What version are you using?
>
>
>
> The most likely answer is some individual partition that’s either being
> written/
Hi Jaydeep.
> Now when I read using quorum then sometimes it returns data D1 and
> sometimes it returns empty results. After tracing I found that when N1 and
> N2 are chosen then we get empty data, when (N1/N2) and N3 are chosen then
> D1 data is returned.
This is an acceptable situation (ie. a
Is your replication_factor 2? Or is it 3? What version are you using?
The most likely answer is some individual partition that’s either being
written/read more than others, or is somehow impacting the cluster (wide rows
are a natural candidate).
You don’t mention your version, but most
when our cluster was under load i am seeing 1 or 2 nodes are on more load
consistently when compared to others in dc i am not seeing any GC pauses or
wide partitions is this can be those nodes are continuously serving as
coordinators ?? how can i find what is the reason for high load on those
t
> If you do not feel ready for incremental repairs, just adding the '-full'
option to your 'nodetool repair' command should be enough to continue
repairing as you currently are once using 3.0.7.
This is not entirely true on 2.2+ after CASSANDRA-7586, since
anti-compaction is always executed after
Hi Jean,
Our concern is the repair, in 3.0.7 repairs inc are by default. Then it
> means that once we do the upgrade to 3.0.7 we must follow the migration
> process of repairs inc for all our data in order to mark the sstables as
> repaired ?
If you do not feel ready for incremental repairs, jus
Hi,
Have you solved this issue? Sorry we did not answered you earlier.
Is it a bug of Cassandra 2.1.11
Not that I am aware of.
or I misused this command?
What does your command look like? I could try it locally if that helps.
C*heers,
---
Alain Rodriguez - @arodream - al
Hello,
Until 3.0, we had a nice formula to estimate partition size :
sizeof(partition keys)
+ sizeof(static columns)
+ countof(rows) * sizeof(regular columns)
+ countof(rows) * countof(regular columns) * sizeof(clustering columns)
+ 8 * count(values in partition)
With the 3
Hi Lokesh,
Repair is a regular, very common and yet non trivial operations in
Cassandra. A lot of people are struggling with it.
Some good talks were done about repairs during the summit, you might want
to have a look in the Datastax youtube channel in a few days :-).
https://www.youtube.com/user
Hi Lokesh,
Which version of Cassandra are you using? Which compaction strategy are you
using?
AFAIK, a repair doesn't trigger a major compaction, but I might be wrong
here.
What you could do is to run a repair for a subset of the ring (see `-st`
and `-et` `nodetool repair` parameters). If you re
31 matches
Mail list logo
