Re: Output of "select token from system.local where key = 'local' "

[Alexander DEJANOVSKI]

Hi Siddharth,

yes, we are sure token ranges will never overlap (I think the start token
in describering output is excluded and the end token included).

You can get per host information in the Datastax Java driver using :

Set rangesForKeyspace =  cluster.getMetadata().getTokenRanges(
keyspaceName, host);
Bye,

Alex

Le mar. 30 août 2016 à 10:04, Siddharth Verma 
a écrit :

> Hi ,
> Can we be sure that, token ranges in nodetool describering will be non
> overlapping?
>
> Thanks
> Siddharth Verma
>

RE: How to get information of each read/write request?

[Jun Wu]

Hi Chris,
  Thank you so much for the reply.  For the tracing on in cqlsh, it gives a 
very high-level information. I do need more other detailed information.
  For the ticket, that's exactly what I want: the waiting time for the 
thread pool queue. Actually I do want to the waiting time for each stage for 
each query. That could be awesome.
  Again, your information is quite useful. Thanks!
Jun

From: clohfin...@gmail.com
Date: Tue, 30 Aug 2016 14:31:17 -0500
Subject: Re: How to get information of each read/write request?
To: user@cassandra.apache.org

Running a query with trace (`TRACING ON` in cqlsh) can give you a lot of the 
information for an individual request. There has been a ticket to track time in 
queue (https://issues.apache.org/jira/browse/CASSANDRA-8398) but no ones worked 
on it yet.
Chris
On Tue, Aug 30, 2016 at 12:20 PM, Jun Wu  wrote:



Hi there,
 I'm very interested in the read/write path of Cassandra. Specifically, I'd 
like to know the whole process when a read/write request comes in. 
I noticed that for reach request it could go through multiple stages. For 
example, for read request, it could be in ReadStage, RequestResponseStage, 
ReadRepairStage. For each stage, actually it's a queue and thread pool to serve 
the request. 
   First question is how to track each request in which stage.Also I'm very 
interested int the waiting time for each request to be in the queue, also the 
total queue in each stage. I noticed that in nodetool tpstats will have this 
information. However, I may want to get the real-time information of this, like 
print it out in the terminal. 
I'm wondering  whether someone has hints on this. 
   Thanks in advance!
Jun
  

  

RE: How to get information of each read/write request?

[Jun Wu]

Hi Matija,
 Thank you so much for the reply. The zipking seems to be a very useful 
tool and I'll take a close look at it.
 Meanwhile, I know how to use the Jconsole to get the information exposing 
to JMX. However, for the Jconsole, I need to click the refresh button to get 
the updated value for each metrics. I'm wondering whether there's a convenient 
way that I can print the time-series value out through the terminal of some 
metrics.  
 Thanks!
Jun

From: matija0...@gmail.com
Date: Tue, 30 Aug 2016 21:08:45 +0200
Subject: Re: How to get information of each read/write request?
To: user@cassandra.apache.org

Hi Jun,
If you are looking to track each request zipking is your best bet. The last 
pickle has a blog about tracing using zipkin.Regarding the stats you see in 
nodetool did you check the metrics package in cassandra and what it exposes 
over JMX?
Regards,Matija
On Tue, Aug 30, 2016 at 7:20 PM, Jun Wu  wrote:



Hi there,
 I'm very interested in the read/write path of Cassandra. Specifically, I'd 
like to know the whole process when a read/write request comes in. 
I noticed that for reach request it could go through multiple stages. For 
example, for read request, it could be in ReadStage, RequestResponseStage, 
ReadRepairStage. For each stage, actually it's a queue and thread pool to serve 
the request. 
   First question is how to track each request in which stage.Also I'm very 
interested int the waiting time for each request to be in the queue, also the 
total queue in each stage. I noticed that in nodetool tpstats will have this 
information. However, I may want to get the real-time information of this, like 
print it out in the terminal. 
I'm wondering  whether someone has hints on this. 
   Thanks in advance!
Jun
  

  

Re: Can Sqoop be used in cassandra only cluster for data migration?

[G P]

You can look into using the open Talend big data package.

--
Enviado do aplicação myMail para Android

Terça-feira, 30 Agosto 2016, 09:42PM +01:00 de Amit Trivedi 
tria...@gmail.com:

I am working on a POC and would like to move data from a relational database to 
Cassandra. I was wondering if I can use Sqoop for this since it is one time 
thing and it would be easy to just give a select query to Sqoop to pull data 
from relational database.
However, it looks like I need to setup a new analytics (Hadoop) cluster to use 
Sqoop. Is there any way to use Sqoop in cassandra only node? I am on DSE 4.8.1

I know there are other ways to migrate data like using sstable loader or COPY 
command (I am looking moving less than million rows).

Can Sqoop be used in cassandra only cluster for data migration?

[Amit Trivedi]

I am working on a POC and would like to move data from a relational
database to Cassandra. I was wondering if I can use Sqoop for this since it
is one time thing and it would be easy to just give a select query to Sqoop
to pull data from relational database.
However, it looks like I need to setup a new analytics (Hadoop) cluster to
use Sqoop. Is there any way to use Sqoop in cassandra only node? I am on
DSE 4.8.1

I know there are other ways to migrate data like using sstable loader or
COPY command (I am looking moving less than million rows).

Re: How to get information of each read/write request?

[Chris Lohfink]

Running a query with trace (`TRACING ON` in cqlsh) can give you a lot of
the information for an individual request. There has been a ticket to track
time in queue (https://issues.apache.org/jira/browse/CASSANDRA-8398) but no
ones worked on it yet.

Chris

On Tue, Aug 30, 2016 at 12:20 PM, Jun Wu  wrote:

> Hi there,
>
>  I'm very interested in the read/write path of Cassandra.
> Specifically, I'd like to know the whole process when a read/write request
> comes in.
>
> I noticed that for reach request it could go through multiple stages.
> For example, for read request, it could be in ReadStage,
> RequestResponseStage, ReadRepairStage. For each stage, actually it's a
> queue and thread pool to serve the request.
>
>First question is how to track each request in which stage.
>
>Also I'm very interested int the waiting time for each request to be in
> the queue, also the total queue in each stage. I noticed that in nodetool
> tpstats will have this information. However, I may want to get the
> real-time information of this, like print it out in the terminal.
>
> I'm wondering  whether someone has hints on this.
>
>Thanks in advance!
>
> Jun
>
>
>

Re: How to get information of each read/write request?

[Matija Gobec]

Hi Jun,

If you are looking to track each request zipking is your best bet. The last
pickle has a blog

about tracing using zipkin.
Regarding the stats you see in nodetool did you check the metrics package
in cassandra and what it exposes over JMX?

Regards,
Matija

On Tue, Aug 30, 2016 at 7:20 PM, Jun Wu  wrote:

> Hi there,
>
>  I'm very interested in the read/write path of Cassandra.
> Specifically, I'd like to know the whole process when a read/write request
> comes in.
>
> I noticed that for reach request it could go through multiple stages.
> For example, for read request, it could be in ReadStage,
> RequestResponseStage, ReadRepairStage. For each stage, actually it's a
> queue and thread pool to serve the request.
>
>First question is how to track each request in which stage.
>
>Also I'm very interested int the waiting time for each request to be in
> the queue, also the total queue in each stage. I noticed that in nodetool
> tpstats will have this information. However, I may want to get the
> real-time information of this, like print it out in the terminal.
>
> I'm wondering  whether someone has hints on this.
>
>Thanks in advance!
>
> Jun
>
>
>

Re: Read timeouts on primary key queries

[Joseph Tech]

On further analysis, this issue happens only on 1 table in the KS which has
the max reads.

@Atul, I will look at system health, but didnt see anything standing out
from GC logs. (using JDK 1.8_92 with G1GC).

@Patrick , could you please elaborate the "mismatch on node count + RF"
part.

On Tue, Aug 30, 2016 at 5:35 PM, Atul Saroha 
wrote:

> There could be many reasons for this if it is intermittent. CPU usage +
> I/O wait status. As read are I/O intensive, your IOPS requirement should be
> met that time load. Heap issue if CPU is busy for GC only. Network health
> could be the reason. So better to look system health during that time when
> it comes.
>
> 
> -
> Atul Saroha
> *Lead Software Engineer*
> *M*: +91 8447784271 *T*: +91 124-415-6069 *EXT*: 12369
> Plot # 362, ASF Centre - Tower A, Udyog Vihar,
>  Phase -4, Sector 18, Gurgaon, Haryana 122016, INDIA
>
> On Tue, Aug 30, 2016 at 5:10 PM, Joseph Tech 
> wrote:
>
>> Hi Patrick,
>>
>> The nodetool status shows all nodes up and normal now. From OpsCenter
>> "Event Log" , there are some nodes reported as being down/up etc. during
>> the timeframe of timeout, but these are Search workload nodes from the
>> remote (non-local) DC. The RF is 3 and there are 9 nodes per DC.
>>
>> Thanks,
>> Joseph
>>
>> On Mon, Aug 29, 2016 at 11:07 PM, Patrick McFadin 
>> wrote:
>>
>>> You aren't achieving quorum on your reads as the error is explains. That
>>> means you either have some nodes down or your topology is not matching up.
>>> The fact you are using LOCAL_QUORUM might point to a datacenter mis-match
>>> on node count + RF.
>>>
>>> What does your nodetool status look like?
>>>
>>> Patrick
>>>
>>> On Mon, Aug 29, 2016 at 10:14 AM, Joseph Tech 
>>> wrote:
>>>
 Hi,

 We recently started getting intermittent timeouts on primary key
 queries (select * from table where key=)

 The error is : com.datastax.driver.core.exceptions.ReadTimeoutException:
 Cassandra timeout during read query at consistency LOCAL_QUORUM (2
 responses were required but only 1 replica
 a responded)

 The same query would work fine when tried directly from cqlsh. There
 are no indications in system.log for the table in question, though there
 were compactions in progress for tables in another keyspace which is more
 frequently accessed.

 My understanding is that the chances of primary key queries timing out
 is very minimal. Please share the possible reasons / ways to debug this
 issue.

 We are using Cassandra 2.1 (DSE 4.8.7).

 Thanks,
 Joseph




>>>
>>
>

How to get information of each read/write request?

[Jun Wu]

Hi there,
 I'm very interested in the read/write path of Cassandra. Specifically, I'd 
like to know the whole process when a read/write request comes in. 
I noticed that for reach request it could go through multiple stages. For 
example, for read request, it could be in ReadStage, RequestResponseStage, 
ReadRepairStage. For each stage, actually it's a queue and thread pool to serve 
the request. 
   First question is how to track each request in which stage.Also I'm very 
interested int the waiting time for each request to be in the queue, also the 
total queue in each stage. I noticed that in nodetool tpstats will have this 
information. However, I may want to get the real-time information of this, like 
print it out in the terminal. 
I'm wondering  whether someone has hints on this. 
   Thanks in advance!
Jun
  

ApacheCon Seville CFP closes September 9th

[Rich Bowen]

It's traditional. We wait for the last minute to get our talk proposals
in for conferences.

Well, the last minute has arrived. The CFP for ApacheCon Seville closes
on September 9th, which is less than 2 weeks away. It's time to get your
talks in, so that we can make this the best ApacheCon yet.

It's also time to discuss with your developer and user community whether
there's a track of talks that you might want to propose, so that you
have more complete coverage of your project than a talk or two.

For Apache Big Data, the relevant URLs are:
Event details:
http://events.linuxfoundation.org/events/apache-big-data-europe
CFP:
http://events.linuxfoundation.org/events/apache-big-data-europe/program/cfp

For ApacheCon Europe, the relevant URLs are:
Event details: http://events.linuxfoundation.org/events/apachecon-europe
CFP: http://events.linuxfoundation.org/events/apachecon-europe/program/cfp

This year, we'll be reviewing papers "blind" - that is, looking at the
abstracts without knowing who the speaker is. This has been shown to
eliminate the "me and my buddies" nature of many tech conferences,
producing more diversity, and more new speakers. So make sure your
abstracts clearly explain what you'll be talking about.

For further updated about ApacheCon, follow us on Twitter, @ApacheCon,
or drop by our IRC channel, #apachecon on the Freenode IRC network.

-- 
Rich Bowen
WWW: http://apachecon.com/
Twitter: @ApacheCon

Select..IN query specs

[Atul Saroha]

I understand *IN* query only allowed on clustering columns. Just want to
understand:
why is it not allowed on non-primary columns with ALLOW FILTERING in case
of "where clause" containing all partition keys with it.

Can someone guide me to a DOC/Blog for better understanding
-
Atul Saroha
*Lead Software Engineer*
*M*: +91 8447784271 *T*: +91 124-415-6069 *EXT*: 12369
Plot # 362, ASF Centre - Tower A, Udyog Vihar,
 Phase -4, Sector 18, Gurgaon, Haryana 122016, INDIA

Re: Read timeouts on primary key queries

[Atul Saroha]

There could be many reasons for this if it is intermittent. CPU usage + I/O
wait status. As read are I/O intensive, your IOPS requirement should be met
that time load. Heap issue if CPU is busy for GC only. Network health could
be the reason. So better to look system health during that time when it
comes.

-
Atul Saroha
*Lead Software Engineer*
*M*: +91 8447784271 *T*: +91 124-415-6069 *EXT*: 12369
Plot # 362, ASF Centre - Tower A, Udyog Vihar,
 Phase -4, Sector 18, Gurgaon, Haryana 122016, INDIA

On Tue, Aug 30, 2016 at 5:10 PM, Joseph Tech  wrote:

> Hi Patrick,
>
> The nodetool status shows all nodes up and normal now. From OpsCenter
> "Event Log" , there are some nodes reported as being down/up etc. during
> the timeframe of timeout, but these are Search workload nodes from the
> remote (non-local) DC. The RF is 3 and there are 9 nodes per DC.
>
> Thanks,
> Joseph
>
> On Mon, Aug 29, 2016 at 11:07 PM, Patrick McFadin 
> wrote:
>
>> You aren't achieving quorum on your reads as the error is explains. That
>> means you either have some nodes down or your topology is not matching up.
>> The fact you are using LOCAL_QUORUM might point to a datacenter mis-match
>> on node count + RF.
>>
>> What does your nodetool status look like?
>>
>> Patrick
>>
>> On Mon, Aug 29, 2016 at 10:14 AM, Joseph Tech 
>> wrote:
>>
>>> Hi,
>>>
>>> We recently started getting intermittent timeouts on primary key queries
>>> (select * from table where key=)
>>>
>>> The error is : com.datastax.driver.core.exceptions.ReadTimeoutException:
>>> Cassandra timeout during read query at consistency LOCAL_QUORUM (2
>>> responses were required but only 1 replica
>>> a responded)
>>>
>>> The same query would work fine when tried directly from cqlsh. There are
>>> no indications in system.log for the table in question, though there were
>>> compactions in progress for tables in another keyspace which is more
>>> frequently accessed.
>>>
>>> My understanding is that the chances of primary key queries timing out
>>> is very minimal. Please share the possible reasons / ways to debug this
>>> issue.
>>>
>>> We are using Cassandra 2.1 (DSE 4.8.7).
>>>
>>> Thanks,
>>> Joseph
>>>
>>>
>>>
>>>
>>
>

Re: Read timeouts on primary key queries

[Joseph Tech]

Hi Patrick,

The nodetool status shows all nodes up and normal now. From OpsCenter
"Event Log" , there are some nodes reported as being down/up etc. during
the timeframe of timeout, but these are Search workload nodes from the
remote (non-local) DC. The RF is 3 and there are 9 nodes per DC.

Thanks,
Joseph

On Mon, Aug 29, 2016 at 11:07 PM, Patrick McFadin 
wrote:

> You aren't achieving quorum on your reads as the error is explains. That
> means you either have some nodes down or your topology is not matching up.
> The fact you are using LOCAL_QUORUM might point to a datacenter mis-match
> on node count + RF.
>
> What does your nodetool status look like?
>
> Patrick
>
> On Mon, Aug 29, 2016 at 10:14 AM, Joseph Tech 
> wrote:
>
>> Hi,
>>
>> We recently started getting intermittent timeouts on primary key queries
>> (select * from table where key=)
>>
>> The error is : com.datastax.driver.core.exceptions.ReadTimeoutException:
>> Cassandra timeout during read query at consistency LOCAL_QUORUM (2
>> responses were required but only 1 replica
>> a responded)
>>
>> The same query would work fine when tried directly from cqlsh. There are
>> no indications in system.log for the table in question, though there were
>> compactions in progress for tables in another keyspace which is more
>> frequently accessed.
>>
>> My understanding is that the chances of primary key queries timing out is
>> very minimal. Please share the possible reasons / ways to debug this issue.
>>
>> We are using Cassandra 2.1 (DSE 4.8.7).
>>
>> Thanks,
>> Joseph
>>
>>
>>
>>
>

Re: Read Repairs and CL

[Ben Slater]

Thanks Sam - a couple of subtleties there that we missed in our review.

Cheers
Ben

On Tue, 30 Aug 2016 at 19:42 Sam Tunnicliffe  wrote:

> Just to clarify a little further, it's true that read repair queries are
> performed at CL ALL, but this is slightly different to a regular,
> user-initiated query at that CL.
>
> Say you have RF=5 and you issue read at CL ALL, the coordinator will send
> requests to all 5 replicas and block until it receives a response from each
> (or a timeout occurs) before replying to the client. This is the
> straightforward and intuitive case.
>
> If instead you read at CL QUORUM, the # of replicas required for CL is 3,
> so the coordinator only contacts 3 nodes. In the case where a speculative
> retry is activated, an additional replica is added to the initial set. The
> coordinator will still only wait for 3 out of the 4 responses before
> proceeding, but if a digest mismatch occurs the read repair queries are
> sent to all 4. It's this follow up query that the coordinator executes at
> CL ALL, i.e. it requires all 4 replicas to respond to the read repair query
> before merging their results to figure out the canonical, latest data.
>
> You can see that the number of replicas queried/required for read repair
> is different than if the client actually requests a read at CL ALL (i.e.
> here it's 4, not 5), it's the behaviour of waiting for all *contacted*
> replicas to respond which is significant here.
>
> There are addtional considerations when constructing that initial replica
> set (which you can follow in
> o.a.c.Service.AbstractReadExecutor::getReadExecutor), involving the table's
> read_repair_chance, dclocal_read_repair_chance and speculative_retry
> options. THe main gotcha is global read repair (via read_repair_chance)
> which will trigger cross-dc repairs at CL ALL in the case of a digest
> mismatch, even if the requested CL is DC-local.
>
>
> On Sun, Aug 28, 2016 at 11:55 AM, Ben Slater 
> wrote:
>
>> In case anyone else is interested - we figured this out. When C* decides
>> it need to do a repair based on a digest mismatch from the initial reads
>> for the consistency level it does actually try to do a read at CL=ALL in
>> order to get the most up to date data to use to repair.
>>
>> This led to an interesting issue in our case where we had one node in an
>> RF3 cluster down for maintenance (to correct data that became corrupted due
>> to a severe write overload) and started getting occasional “timeout during
>> read query at consistency LOCAL_QUORUM” failures. We believe this due to
>> the case where data for a read was only available on one of the two up
>> replicas which then triggered an attempt to repair and a failed read at
>> CL=ALL. It seems that CASSANDRA-7947 (a while ago) change the behaviour so
>> that C* reports a failure at the originally request level even when it was
>> actually the attempted repair read at CL=ALL which could not read
>> sufficient replicas - a bit confusing (although I can also see how getting
>> CL=ALL errors when you thought you were reading at QUORUM or ONE would be
>> confusing).
>>
>> Cheers
>> Ben
>>
>> On Sun, 28 Aug 2016 at 10:52 kurt Greaves  wrote:
>>
>>> Looking at the wiki for the read path (
>>> http://wiki.apache.org/cassandra/ReadPathForUsers), in the bottom
>>> diagram for reading with a read repair, it states the following when
>>> "reading from all replica nodes" after there is a hash mismatch:
>>>
>>> If hashes do not match, do conflict resolution. First step is to read
 all data from all replica nodes excluding the fastest replica (since 
 CL=ALL)

>>>
>>>  In the bottom left of the diagram it also states:
>>>
 In this example:

>>> RF>=2

>>> CL=ALL

>>>
>>> The (since CL=ALL) implies that the CL for the read during the read
>>> repair is based off the CL of the query. However I don't think that makes
>>> sense at other CLs. Anyway, I just want to clarify what CL the read for the
>>> read repair occurs at for cases where the overall query CL is not ALL.
>>>
>>> Thanks,
>>> Kurt.
>>>
>>> --
>>> Kurt Greaves
>>> k...@instaclustr.com
>>> www.instaclustr.com
>>>
>> --
>> 
>> Ben Slater
>> Chief Product Officer
>> Instaclustr: Cassandra + Spark - Managed | Consulting | Support
>> +61 437 929 798
>>
>
> --

Ben Slater
Chief Product Officer
Instaclustr: Cassandra + Spark - Managed | Consulting | Support
+61 437 929 798

Re: Read Repairs and CL

[Sam Tunnicliffe]

Just to clarify a little further, it's true that read repair queries are
performed at CL ALL, but this is slightly different to a regular,
user-initiated query at that CL.

Say you have RF=5 and you issue read at CL ALL, the coordinator will send
requests to all 5 replicas and block until it receives a response from each
(or a timeout occurs) before replying to the client. This is the
straightforward and intuitive case.

If instead you read at CL QUORUM, the # of replicas required for CL is 3,
so the coordinator only contacts 3 nodes. In the case where a speculative
retry is activated, an additional replica is added to the initial set. The
coordinator will still only wait for 3 out of the 4 responses before
proceeding, but if a digest mismatch occurs the read repair queries are
sent to all 4. It's this follow up query that the coordinator executes at
CL ALL, i.e. it requires all 4 replicas to respond to the read repair query
before merging their results to figure out the canonical, latest data.

You can see that the number of replicas queried/required for read repair is
different than if the client actually requests a read at CL ALL (i.e. here
it's 4, not 5), it's the behaviour of waiting for all *contacted* replicas
to respond which is significant here.

There are addtional considerations when constructing that initial replica
set (which you can follow in
o.a.c.Service.AbstractReadExecutor::getReadExecutor), involving the table's
read_repair_chance, dclocal_read_repair_chance and speculative_retry
options. THe main gotcha is global read repair (via read_repair_chance)
which will trigger cross-dc repairs at CL ALL in the case of a digest
mismatch, even if the requested CL is DC-local.


On Sun, Aug 28, 2016 at 11:55 AM, Ben Slater 
wrote:

> In case anyone else is interested - we figured this out. When C* decides
> it need to do a repair based on a digest mismatch from the initial reads
> for the consistency level it does actually try to do a read at CL=ALL in
> order to get the most up to date data to use to repair.
>
> This led to an interesting issue in our case where we had one node in an
> RF3 cluster down for maintenance (to correct data that became corrupted due
> to a severe write overload) and started getting occasional “timeout during
> read query at consistency LOCAL_QUORUM” failures. We believe this due to
> the case where data for a read was only available on one of the two up
> replicas which then triggered an attempt to repair and a failed read at
> CL=ALL. It seems that CASSANDRA-7947 (a while ago) change the behaviour so
> that C* reports a failure at the originally request level even when it was
> actually the attempted repair read at CL=ALL which could not read
> sufficient replicas - a bit confusing (although I can also see how getting
> CL=ALL errors when you thought you were reading at QUORUM or ONE would be
> confusing).
>
> Cheers
> Ben
>
> On Sun, 28 Aug 2016 at 10:52 kurt Greaves  wrote:
>
>> Looking at the wiki for the read path (http://wiki.apache.org/
>> cassandra/ReadPathForUsers), in the bottom diagram for reading with a
>> read repair, it states the following when "reading from all replica nodes"
>> after there is a hash mismatch:
>>
>> If hashes do not match, do conflict resolution. First step is to read all
>>> data from all replica nodes excluding the fastest replica (since CL=ALL)
>>>
>>
>>  In the bottom left of the diagram it also states:
>>
>>> In this example:
>>>
>> RF>=2
>>>
>> CL=ALL
>>>
>>
>> The (since CL=ALL) implies that the CL for the read during the read
>> repair is based off the CL of the query. However I don't think that makes
>> sense at other CLs. Anyway, I just want to clarify what CL the read for the
>> read repair occurs at for cases where the overall query CL is not ALL.
>>
>> Thanks,
>> Kurt.
>>
>> --
>> Kurt Greaves
>> k...@instaclustr.com
>> www.instaclustr.com
>>
> --
> 
> Ben Slater
> Chief Product Officer
> Instaclustr: Cassandra + Spark - Managed | Consulting | Support
> +61 437 929 798
>

Re: Output of "select token from system.local where key = 'local' "

[Siddharth Verma]

Hi ,
Can we be sure that, token ranges in nodetool describering will be non
overlapping?

Thanks
Siddharth Verma

Re: Output of "select token from system.local where key = 'local' "

[Siddharth Verma]

Hi Alex,
Thanks for your reply.
I saw describering yesterday, but didn't know "the first endpoint being the
primary". Thanks for that.
Is there anyway to get the same information in application?
If there isn't any way to get the same information at application layer, I
would be using this as a backup.

Siddharth Verma

Re: Output of "select token from system.local where key = 'local' "

[Alexander DEJANOVSKI]

Hi Siddarth,

I would recommend running "nodetool describering keyspace_name" as its
output is much simpler to reason about :

Schema Version:9a091b4e-3712-3149-b187-d2b09250a19b

TokenRange:

TokenRange(start_token:1943978523300203561, end_token:2137919499801737315,
endpoints:[127.0.0.3, 127.0.0.6, 127.0.0.7, 127.0.0.2, 127.0.0.5,
127.0.0.1], rpc_endpoints:[127.0.0.3, 127.0.0.6, 127.0.0.7, 127.0.0.2,
127.0.0.5, 127.0.0.1], endpoint_details:[EndpointDetails(host:127.0.0.3,
datacenter:dc1, rack:r1), EndpointDetails(host:127.0.0.6, datacenter:dc2,
rack:r1), EndpointDetails(host:127.0.0.7, datacenter:dc2, rack:r1),
EndpointDetails(host:127.0.0.2, datacenter:dc1, rack:r1),
EndpointDetails(host:127.0.0.5, datacenter:dc2, rack:r1),
EndpointDetails(host:127.0.0.1, datacenter:dc1, rack:r1)])

TokenRange(start_token:6451470843510300950, end_token:7799236518897713874,
endpoints:[127.0.0.6, 127.0.0.4, 127.0.0.1, 127.0.0.3, 127.0.0.5,
127.0.0.2], rpc_endpoints:[127.0.0.6, 127.0.0.4, 127.0.0.1, 127.0.0.3,
127.0.0.5, 127.0.0.2], endpoint_details:[EndpointDetails(host:127.0.0.6,
datacenter:dc2, rack:r1), EndpointDetails(host:127.0.0.4, datacenter:dc2,
rack:r1), EndpointDetails(host:127.0.0.1, datacenter:dc1, rack:r1),
EndpointDetails(host:127.0.0.3, datacenter:dc1, rack:r1),
EndpointDetails(host:127.0.0.5, datacenter:dc2, rack:r1),
EndpointDetails(host:127.0.0.2, datacenter:dc1, rack:r1)])

TokenRange(start_token:-2494488779943368698,
end_token:-2344803022847488784, endpoints:[127.0.0.1, 127.0.0.4, 127.0.0.6,
127.0.0.5, 127.0.0.3, 127.0.0.2], rpc_endpoints:[127.0.0.1, 127.0.0.4,
127.0.0.6, 127.0.0.5, 127.0.0.3, 127.0.0.2],
endpoint_details:[EndpointDetails(host:127.0.0.1, datacenter:dc1, rack:r1),
EndpointDetails(host:127.0.0.4, datacenter:dc2, rack:r1),
EndpointDetails(host:127.0.0.6, datacenter:dc2, rack:r1),
EndpointDetails(host:127.0.0.5, datacenter:dc2, rack:r1),
EndpointDetails(host:127.0.0.3, datacenter:dc1, rack:r1),
EndpointDetails(host:127.0.0.2, datacenter:dc1, rack:r1)])

TokenRange(start_token:-3354341409828719744,
end_token:-3001704612215276412, endpoints:[127.0.0.7, 127.0.0.1, 127.0.0.4,
127.0.0.6, 127.0.0.3, 127.0.0.2], rpc_endpoints:[127.0.0.7, 127.0.0.1,
127.0.0.4, 127.0.0.6, 127.0.0.3, 127.0.0.2],
endpoint_details:[EndpointDetails(host:127.0.0.7, datacenter:dc2, rack:r1),
EndpointDetails(host:127.0.0.1, datacenter:dc1, rack:r1),
EndpointDetails(host:127.0.0.4, datacenter:dc2, rack:r1),
EndpointDetails(host:127.0.0.6, datacenter:dc2, rack:r1),
EndpointDetails(host:127.0.0.3, datacenter:dc1, rack:r1),
EndpointDetails(host:127.0.0.2, datacenter:dc1, rack:r1)])


It will give you the start and end token of each range (vnode) and the list
of the replicas for each (the first endpoint being the primary).

Hope this helps you figuring out your token distribution.

Alex

Le mar. 30 août 2016 à 09:11, Siddharth Verma 
a écrit :

> Hi,
> I saw that in cassandra-driver-core,(3.1.0) Metadata.TokenMap has
> primaryToTokens which has the value for ALL the nodes.
> I tried to find (primary)range ownership for nodes in one DC.
> And executed the following in debug mode in IDE.
>
> TreeMap primaryTokenMap = new TreeMap<>();
> for(Host host :
> main.cluster.getMetadata().tokenMap.primaryToTokens.keySet()){
> if(!host.getDatacenter().equals("dc2"))
> continue;
> for(Token token :
> main.cluster.getMetadata().tokenMap.primaryToTokens.get(host)){
> primaryTokenMap.put((Long) token.getValue(),host);
>
> }
> }
> primaryTokenMap //this printed the map in evaluate code fragment window
>
> dc2 has 3 nodes, RF is 3
> Sample entries :
> 244925668410340093 -> /10.0.3.79:9042
> 291047688656337660 -> /10.0.3.217:9042
> 317775761591844910 -> /10.0.3.135:9042
> 328177243900091789 -> /10.0.3.79:9042
> 329239043633655596 -> /10.0.3.135:9042
> 
>
> Can I safely assume
> Token
> Range
> Host
> 244925668410340093 to 291047688656337660 -1 belongs to 10.0.3.79:9042
> 291047688656337660 to 317775761591844910 -1 belongs to 10.0.3.135:9042
> 317775761591844910 to 328177243900091789 -1 belongs to 10.0.3.135:9042
> And so on.
>
> Is the above assumption ABSOLUTELY correct?
> (Kindly suggest changes/errors, if any)
>
> Any help would be great.
> Thanks and Regards,
> Siddharth Verma
>

Re: Output of "select token from system.local where key = 'local' "

[Siddharth Verma]

Hi,
I saw that in cassandra-driver-core,(3.1.0) Metadata.TokenMap has
primaryToTokens which has the value for ALL the nodes.
I tried to find (primary)range ownership for nodes in one DC.
And executed the following in debug mode in IDE.

TreeMap primaryTokenMap = new TreeMap<>();
for(Host host :
main.cluster.getMetadata().tokenMap.primaryToTokens.keySet()){
if(!host.getDatacenter().equals("dc2"))
continue;
for(Token token :
main.cluster.getMetadata().tokenMap.primaryToTokens.get(host)){
primaryTokenMap.put((Long) token.getValue(),host);

}
}
primaryTokenMap //this printed the map in evaluate code fragment window

dc2 has 3 nodes, RF is 3
Sample entries :
244925668410340093 -> /10.0.3.79:9042
291047688656337660 -> /10.0.3.217:9042
317775761591844910 -> /10.0.3.135:9042
328177243900091789 -> /10.0.3.79:9042
329239043633655596 -> /10.0.3.135:9042


Can I safely assume
Token
Range
Host
244925668410340093 to 291047688656337660 -1 belongs to 10.0.3.79:9042
291047688656337660 to 317775761591844910 -1 belongs to 10.0.3.135:9042
317775761591844910 to 328177243900091789 -1 belongs to 10.0.3.135:9042
And so on.

Is the above assumption ABSOLUTELY correct?
(Kindly suggest changes/errors, if any)

Any help would be great.
Thanks and Regards,
Siddharth Verma

Re: Bootstrapping multiple C* nodes in AWS

[Jeff Jirsa]

Related reading: https://issues.apache.org/jira/browse/CASSANDRA-2434 and  
https://issues.apache.org/jira/browse/CASSANDRA-7069

 

 

From: Ben Slater 
Reply-To: "user@cassandra.apache.org" 
Date: Monday, August 29, 2016 at 11:48 PM
To: "user@cassandra.apache.org" 
Subject: Re: Bootstrapping multiple C* nodes in AWS

 

Hi Aiman, 

 

Best practice would be to map cassandra racks to AWS availability zones. If you 
are following this then you would add one node per AZ to keep the number of 
nodes in each rack balanced.

 

It is technically possible to add multiple nodes simultaneously (at least 
joining simultaneously - you need to leave a gap between starting) if your 
configuration meets some restrictions (although I can’t remember exactly what 
those are) and also requires setting cassandra.consistent.rangemovement=false. 
However, in general I’d recommend adding one node at a time unless you’re 
really confident in what you are doing, particular if you’re working with a 
production cluster.

 

Cheers

Ben

 

On Tue, 30 Aug 2016 at 16:09 Aiman Parvaiz  wrote:

Hi all 

I am running C* 2.1.12 in AWS EC2 Classic with RF=3 and vnodes(256 
tokens/node). My nodes are distributed in three different availability zones. I 
want to scale up the cluster size, given the data size per node it takes around 
24 hours to add one node. 

 

I wanted to know if its safe to add multiple nodes at once in AWS and should I 
add them in the same availability zone. Would be grateful to hear your 
experiences here.

 

Thanks
 

-- 

 

Ben Slater 

Chief Product Officer

Instaclustr: Cassandra + Spark - Managed | Consulting | Support

+61 437 929 798



smime.p7s
Description: S/MIME cryptographic signature

Re: Bootstrapping multiple C* nodes in AWS

[Ben Slater]

Hi Aiman,

Best practice would be to map cassandra racks to AWS availability zones. If
you are following this then you would add one node per AZ to keep the
number of nodes in each rack balanced.

It is technically possible to add multiple nodes simultaneously (at least
joining simultaneously - you need to leave a gap between starting) if your
configuration meets some restrictions (although I can’t remember exactly
what those are) and also requires setting
cassandra.consistent.rangemovement=false. However, in general I’d recommend
adding one node at a time unless you’re really confident in what you are
doing, particular if you’re working with a production cluster.

Cheers
Ben

On Tue, 30 Aug 2016 at 16:09 Aiman Parvaiz  wrote:

> Hi all
> I am running C* 2.1.12 in AWS EC2 Classic with RF=3 and vnodes(256
> tokens/node). My nodes are distributed in three different availability
> zones. I want to scale up the cluster size, given the data size per node it
> takes around 24 hours to add one node.
>
> I wanted to know if its safe to add multiple nodes at once in AWS and
> should I add them in the same availability zone. Would be grateful to hear
> your experiences here.
>
> Thanks
>
> --

Ben Slater
Chief Product Officer
Instaclustr: Cassandra + Spark - Managed | Consulting | Support
+61 437 929 798

Bootstrapping multiple C* nodes in AWS

[Aiman Parvaiz]

Hi all
I am running C* 2.1.12 in AWS EC2 Classic with RF=3 and vnodes(256
tokens/node). My nodes are distributed in three different availability
zones. I want to scale up the cluster size, given the data size per node it
takes around 24 hours to add one node.

I wanted to know if its safe to add multiple nodes at once in AWS and
should I add them in the same availability zone. Would be grateful to hear
your experiences here.

Thanks