Re: Cassandra 3.0.0 connection problem

[Tyler Hobbs]

On Thu, Nov 19, 2015 at 1:13 AM, Enrico Sola 
wrote:

> Hi, I'm new to Cassandra and I've recently upgraded to 3.0.0 on Ubuntu
> Linux 14.04 LTS, through apt-get upgrade not manual installation, after the
> update all was fine so I could access to my keyspaces using cqlsh but I
> can't access to Cassandra using DataStax PHP Driver because I get this
> error: "No hosts available for the control connection”.
> The connection parameters are the same of 2.2.3 version (and was working
> fine).
> I don't know if is this a bug or a problem of the PHP driver but my
> systems use Cassandra and are now offline, so it's a known issue with a
> solution?
>

I don't think the PHP driver supports Cassandra 3.0 yet.  There were some
changes to the system schema tables that are probably preventing it from
connecting successfully.


> I tried also to downgrade to 2.2.3 version but after that Cassandra didn't
> start due to keyspace loading problem, I'm just looking for a quick
> solution so doesn't matter if I have to downgrade to 2.2.3, so how can I do
> the downgrade without lose my datas?
>

Downgrading major versions isn't supported, which is why we recommend that
you take a snapshot before upgrading.  Your only real option for
downgrading without data loss is to dump your data (using cqlsh's COPY TO
or something similar) and then re-load it on 2.2 (using cqlsh's COPY FROM
or something similar).


-- 
Tyler Hobbs
DataStax 

Repair service fails with sync failed between X and Y

[Rafael Loureiro]

Hi All,


First, let me apologize for the long message. Repair service is driving me
insane. :)


We are running Cassandra version *2.1.11.908* in 3 data centers. While
running nodetool repair we are receiving the following error:


[2015-11-20 00:25:24,803] Repair session
2ed2f930-8f1d-11e5-a498-4b9679ec178d for range
(4375311677306593380,4384065392379704564] failed with error
org.apache.cassandra.exceptions.RepairException:

[repair #2ed2f930-8f1d-11e5-a498-4b9679ec178d on keyspace/table,
(4375311677306593380,4384065392379704564]] Sync failed between /10.10.8.104
and /10.30.30.6


Unfortunately, not much information online. Any ideas how to fix this issue
or determine root cause?


Thanks!


Detailed log below:


ERROR [AntiEntropySessions:8] 2015-11-20 00:25:24,801
RepairSession.java:303 - [repair #2ed2f930-8f1d-11e5-a498-4b9679ec178d]
session completed with the following
error org.apache.cassandra.exceptions.RepairException: [repair
#2ed2f930-8f1d-11e5-a498-4b9679ec178d on keyspace/table,
(4375311677306593380,4384065392379704564]] Sync failed between /10.10.8.104
and /10.30.30.6 at
org.apache.cassandra.repair.RepairSession.syncComplete(RepairSession.java:223)
~[cassandra-all-2.1.11.908.jar:2.1.11.908] at
 
org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:411)
~[cassandra-all-2.1.11.908.jar:2.1.11.908]

at
org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:134)
~[cassandra-all-2.1.11.908.jar:2.1.11.908]

at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
~[cassandra-all-2.1.11.908.jar:2.1.11.908]

at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
Source) [na:1.8.0_60]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source) [na:1.8.0_60]

at java.lang.Thread.run(Unknown Source) [na:1.8.0_60]

ERROR [AntiEntropySessions:8] 2015-11-20 00:25:24,802
CassandraDaemon.java:227 - Exception in thread
Thread[AntiEntropySessions:8,5,RMI Runtime]

java.lang.RuntimeException:
org.apache.cassandra.exceptions.RepairException: [repair
#2ed2f930-8f1d-11e5-a498-4b9679ec178d on keyspace/table,
(4375311677306593380,4384065392379704564]] Sync failed between /10.10.8.104
and /10.30.30.6

at com.google.common.base.Throwables.propagate(Throwables.java:160)
~[guava-16.0.1.jar:na]

at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
~[cassandra-all-2.1.11.908.jar:2.1.11.908]

at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source) ~[na:1.8.0_60]

at java.util.concurrent.FutureTask.run(Unknown Source)
~[na:1.8.0_60]

at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
Source) [na:1.8.0_60]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source) [na:1.8.0_60]

at java.lang.Thread.run(Unknown Source) [na:1.8.0_60]

Caused by: org.apache.cassandra.exceptions.RepairException: [repair
#2ed2f930-8f1d-11e5-a498-4b9679ec178d on keyspace/table,
(4375311677306593380,4384065392379704564]] Sync failed between /10.10.8.104
and /10.30.30.6

at
org.apache.cassandra.repair.RepairSession.syncComplete(RepairSession.java:223)
~[cassandra-all-2.1.11.908.jar:2.1.11.908]

at
org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:411)
~[cassandra-all-2.1.11.908.jar:2.1.11.908]

at
org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:134)
~[cassandra-all-2.1.11.908.jar:2.1.11.908]

at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
~[cassandra-all-2.1.11.908.jar:2.1.11.908]

... 3 common frames omitted

ERROR [Thread-3128] 2015-11-20 00:25:24,802  StorageService.java:3008 -
Repair session 2ed2f930-8f1d-11e5-a498-4b9679ec178d for range
(4375311677306593380,4384065392379704564] failed with error
org.apache.cassandra.exceptions.RepairException: [repair
#2ed2f930-8f1d-11e5-a498-4b9679ec178d on keyspace/table,
(4375311677306593380,4384065392379704564]] Sync failed between /10.10.8.104
and /10.30.30.6

java.util.concurrent.ExecutionException: java.lang.RuntimeException:
org.apache.cassandra.exceptions.RepairException: [repair
#2ed2f930-8f1d-11e5-a498-4b9679ec178d on keyspace/table,
(4375311677306593380,4384065392379704564]] Sync failed between /10.10.8.104
and /10.30.30.6

at java.util.concurrent.FutureTask.report(Unknown Source)
[na:1.8.0_60]

at java.util.concurrent.FutureTask.get(Unknown Source) [na:1.8.0_60]

at
org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2999)
~[cassandra-all-2.1.11.908.jar:2.1.11.908]

at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
[cassandra-all-2.1.11.908.jar:2.1.11.908]

at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source) [na:1.8.0_60]

at java.util.concurrent.FutureTask.run(Unknown 

Re: Help diagnosing performance issue

[Antoine Bonavita]

Sebastian,

I took into account your suggestion and set max_sstable_age_days to 1.

I left the TTL at 432000 and the gc_grace_seconds at 172800. So, I 
expect SSTable older than 7 days to get deleted. Am I right ?


I did not change dclocal_read_repair_chance because I have only one DC 
at this point in time. Did you mean that I should set read_repair_chance 
to 0 ?


Thanks again for your time and help. Really appreciated.

A.


On 11/19/2015 02:36 AM, Sebastian Estevez wrote:

When you say drop you mean reduce the value (to 1 day for example),
not "don't set the value", right ?


Yes.

If I set max sstable age days to 1, my understanding is that
SSTables with expired data (5 days) are not going to be compacted
ever. And therefore my disk usage will keep growing forever. Did I
miss something here ?


We will expire sstables who's highest TTL is beyond gc_grace_seconds as
of CASSANDRA-5228
. This is nice
because the sstable is just dropped for free, no need to scan it and
remove tombstones which is very expensive and DTCS will guarantee that
all the data within an sstable is close together in time.

So, if I set max sstable age days to 1, I have to run repairs at
least once a day, correct ?

I'm afraid I don't get your point about painful compactions.


I was referring to the problems described here CASSANDRA-9644





All the best,


datastax_logo.png 

Sebastián Estévez

Solutions Architect |954 905 8615 | sebastian.este...@datastax.com


linkedin.png facebook.png
twitter.png
g+.png







DataStax is the fastest, most scalable distributed database technology,
delivering Apache Cassandra to the world’s most innovative enterprises.
Datastax is built to be agile, always-on, and predictably scalable to
any size. With more than 500 customers in 45 countries, DataStax is the
database technology and transactional backbone of choice for the worlds
most innovative companies such as Netflix, Adobe, Intuit, and eBay.

On Wed, Nov 18, 2015 at 5:53 PM, Antoine Bonavita > wrote:

Sebastian,

Your help is very much appreciated. I re-read the blog post and also
https://labs.spotify.com/2014/12/18/date-tiered-compaction/ but some
things are still confusing me.

Please see my questions inline below.

On 11/18/2015 04:21 PM, Sebastian Estevez wrote:

Yep, I think you've mixed up your DTCS levers. I would read, or
re-read
Marcus's post
http://www.datastax.com/dev/blog/datetieredcompactionstrategy

*TL;DR:*

   * *base_time_seconds*  is the size of your initial window
   * *max_sstable_age_days* is the time after which you stop
compacting
 sstables
   * *default_time_to_live* is the time after which data expires and
 sstables will start to become available for GC. (432000 is
5 days)


 Could it be that compaction is putting those in cache
constantly?


Yep, you'll keep compacting sstables until they're 10 days old
per your
current settings and when you compact there are reads and then
writes.



If you aren't doing any updates and most of your reads are within 1
hour, you can probably afford to drop max sstable age days.

When you say drop you mean reduce the value (to 1 day for example),
not "don't set the value", right ?

If I set max sstable age days to 1, my understanding is that
SSTables with expired data (5 days) are not going to be compacted
ever. And therefore my disk usage will keep growing forever. Did I
miss something here ?

Just make
sure you're doing your repairs more often than the max sstable
age days
to avoid some painful compactions.

So, if I set max sstable age days to 1, I have to run repairs at
least once a day, correct ?
I'm afraid I don't get your point about painful compactions.

Along the same lines, you should probably set
dclocal_read_repair_chance
to 0

Will try that.


 Regarding the heap configuration, both are very similar


Probably unrelated but, is there a reason why they're not identical?
Especially the different new gen size could have gc implications.

Both are calculated by cassandra-env.sh. If my bash skills are still
intact, the NewGen size difference comes from the number of cores:
the 64G machine has 12 cores where the 32G machine has 8 

Re: Help diagnosing performance issue

[rock zhang]

unsubscribe.

> On Nov 19, 2015, at 3:58 PM, Antoine Bonavita  wrote:
> 
> Sebastian,
> 
> I took into account your suggestion and set max_sstable_age_days to 1.
> 
> I left the TTL at 432000 and the gc_grace_seconds at 172800. So, I expect 
> SSTable older than 7 days to get deleted. Am I right ?
> 
> I did not change dclocal_read_repair_chance because I have only one DC at 
> this point in time. Did you mean that I should set read_repair_chance to 0 ?
> 
> Thanks again for your time and help. Really appreciated.
> 
> A.
> 
> 
> On 11/19/2015 02:36 AM, Sebastian Estevez wrote:
>>When you say drop you mean reduce the value (to 1 day for example),
>>not "don't set the value", right ?
>> 
>> 
>> Yes.
>> 
>>If I set max sstable age days to 1, my understanding is that
>>SSTables with expired data (5 days) are not going to be compacted
>>ever. And therefore my disk usage will keep growing forever. Did I
>>miss something here ?
>> 
>> 
>> We will expire sstables who's highest TTL is beyond gc_grace_seconds as
>> of CASSANDRA-5228
>> . This is nice
>> because the sstable is just dropped for free, no need to scan it and
>> remove tombstones which is very expensive and DTCS will guarantee that
>> all the data within an sstable is close together in time.
>> 
>>So, if I set max sstable age days to 1, I have to run repairs at
>>least once a day, correct ?
>> 
>>I'm afraid I don't get your point about painful compactions.
>> 
>> 
>> I was referring to the problems described here CASSANDRA-9644
>> 
>> 
>> 
>> 
>> 
>> All the best,
>> 
>> 
>> datastax_logo.png 
>> 
>> Sebastián Estévez
>> 
>> Solutions Architect |954 905 8615 | sebastian.este...@datastax.com
>> 
>> 
>> linkedin.png facebook.png
>> twitter.png
>> g+.png
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> DataStax is the fastest, most scalable distributed database technology,
>> delivering Apache Cassandra to the world’s most innovative enterprises.
>> Datastax is built to be agile, always-on, and predictably scalable to
>> any size. With more than 500 customers in 45 countries, DataStax is the
>> database technology and transactional backbone of choice for the worlds
>> most innovative companies such as Netflix, Adobe, Intuit, and eBay.
>> 
>> On Wed, Nov 18, 2015 at 5:53 PM, Antoine Bonavita > > wrote:
>> 
>>Sebastian,
>> 
>>Your help is very much appreciated. I re-read the blog post and also
>>https://labs.spotify.com/2014/12/18/date-tiered-compaction/ but some
>>things are still confusing me.
>> 
>>Please see my questions inline below.
>> 
>>On 11/18/2015 04:21 PM, Sebastian Estevez wrote:
>> 
>>Yep, I think you've mixed up your DTCS levers. I would read, or
>>re-read
>>Marcus's post
>>http://www.datastax.com/dev/blog/datetieredcompactionstrategy
>> 
>>*TL;DR:*
>> 
>>   * *base_time_seconds*  is the size of your initial window
>>   * *max_sstable_age_days* is the time after which you stop
>>compacting
>> sstables
>>   * *default_time_to_live* is the time after which data expires and
>> sstables will start to become available for GC. (432000 is
>>5 days)
>> 
>> 
>> Could it be that compaction is putting those in cache
>>constantly?
>> 
>> 
>>Yep, you'll keep compacting sstables until they're 10 days old
>>per your
>>current settings and when you compact there are reads and then
>>writes.
>> 
>> 
>> 
>>If you aren't doing any updates and most of your reads are within 1
>>hour, you can probably afford to drop max sstable age days.
>> 
>>When you say drop you mean reduce the value (to 1 day for example),
>>not "don't set the value", right ?
>> 
>>If I set max sstable age days to 1, my understanding is that
>>SSTables with expired data (5 days) are not going to be compacted
>>ever. And therefore my disk usage will keep growing forever. Did I
>>miss something here ?
>> 
>>Just make
>>sure you're doing your repairs more often than the max sstable
>>age days
>>to avoid some painful compactions.
>> 
>>So, if I set max sstable age days to 1, I have to run repairs at
>>least once a day, correct ?
>>I'm afraid I don't get your point about painful compactions.
>> 
>>Along the same lines, you should probably set
>>dclocal_read_repair_chance
>>to 0
>> 
>>Will try 

Re: Cqlsh copy to and copy from

[Tyler Hobbs]

If the fields are null, COPY TO should just be generating "{field1: null,
field2: null}".

Would you mind opening a ticket here with steps to reproduce:
https://issues.apache.org/jira/browse/CASSANDRA

On Thu, Nov 19, 2015 at 1:05 AM, Vova Shelgunov  wrote:

> Hi all,
>
> I have a trouble with copy functionality in cassandra 3.0.
>
> When I am trying to copy my table to file, some of UDTs have the following
> representation:
>
> {field1: , field2: }
>
> They have no values, and when I tried to restore this table, this rows was
> not imported.
>
> Do you plan to fix that, e.g. fill with default values or exclude them?
>
> Thanks.
>



-- 
Tyler Hobbs
DataStax 

RE: Strategy tools for taking snapshots to load in another cluster instance

[Peer, Oded]

Have you read the DataStax documentation?
http://docs.datastax.com/en/cassandra/2.0/cassandra/operations/ops_snapshot_restore_new_cluster.html


From: Romain Hardouin [mailto:romainh...@yahoo.fr]
Sent: Wednesday, November 18, 2015 3:59 PM
To: user@cassandra.apache.org
Subject: Re: Strategy tools for taking snapshots to load in another cluster 
instance

You can take a snapshot via nodetool then load sstables on your test cluster 
with sstableloader:
docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsBulkloader_t.html



Sent from Yahoo Mail on 
Android


From:"Anishek Agarwal" >
Date:Wed, Nov 18, 2015 at 11:24
Subject:Strategy tools for taking snapshots to load in another cluster instance
Hello

We have 5 node prod cluster and 3 node test cluster. Is there a way i can take 
snapshot of a table in prod and load it test cluster. The cassandra versions 
are same.

Even if there is a tool that can help with this it will be great.

If not, how do people handle scenarios where data in prod is required in 
staging/test clusters for testing to make sure things are correct ? Does the 
cluster size have to be same to allow copying of relevant snapshot data etc?


thanks
anishek

Re: [Marketing Mail] Migrating to incremental repairs

[Stefano Ortolani]

As far as I know, docs is quite inconsistent on the matter.
Based on some research here and on IRC, recent versions of Cassandra do no
require anything specific when migrating to incremental repairs but the the
-inc switch even on LCS.

Any confirmation on the matter is more than welcome.

Regards,
Stefano

On Wed, Nov 18, 2015 at 3:59 PM, Reynald Bourtembourg <
reynald.bourtembo...@esrf.fr> wrote:

> Well,
>
> By re-reading my e-mail, I understood the rationale behind doing a full
> sequential repair for each node.
> I was confused by the fact that in our case, we have 3 nodes with RF = 3,
> so all the nodes are storing all replicas.
> So we are in a special case.
> As soon as you have more than 3 nodes, this is no longer the case.
>
> In any case, in our special case (3 nodes and RF=3), could we apply the
> following migration procedure?:
> - disableautocompaction on all nodes at the same time
>  - run the full sequential repair
>  - For each node:
> - stop the node
> - Use the tool sstablerepairedset to mark all the SSTables that
> were created before you disabled compaction.
> - Restart Cassandra
>
> I'd be glad if someone could answer to my other questions in any case ;-).
>
> Thanks in advance for your help
>
> Reynald
>
>
>
> On 18/11/2015 16:45, Reynald Bourtembourg wrote:
>
> Hi,
>
> We currently have a 3 nodes Cassandra cluster with RF = 3.
> We are using Cassandra 2.1.7.
>
> We would like to start using incremental repairs.
> We have some tables using LCS compaction strategy and some others using
> STCS.
>
> Here is the procedure written in the documentation:
>
> To migrate to incremental repair, one node at a time:
>
>1. Disable compaction on the node using nodetool disableautocompaction.
>2. Run the default full, sequential repair.
>3. Stop the node.
>4. Use the tool sstablerepairedset to mark all the SSTables that were
>created before you disabled compaction.
>5. Restart cassandra
>
>
> In our case, a full sequential repair takes about 5 days.
> If I follow the procedure described above and if my understanding is
> correct, it's gonna take at least 15 days (3 repairs of 5 days) before to
> be able to use the incremental repairs, right(?), since we need to do it
> one node at a time (one full sequential repair per node?).
>
> If my understanding is correct, what is the rationale behind the fact that
> we need to run a full sequential repair once for each node?
> I understood a full sequential repair would repair all the sstables on all
> the nodes. So doing it only once should be enough, right?
>
> Is it possible to do the following instead of what is written in the
> documentation?:
>  - disableautocompaction on all nodes at the same time
>  - run the full sequential repair
>  - For each node:
> - stop one node
> - Use the tool sstablerepairedset to mark all the SSTables that
> were created before you disabled compaction.
> - Restart Cassandra
> Without having to run the full sequential repair 3 times?
>
> The documentation states that if we don't execute this migration
> procedure, the first time we will run incremental repair, Cassandra will
> perform size-tiering on all SSTables because the repair/unrepaired status
> is unknown and this operation can take a long time.
> Do you think this operation could take more than 15 days in our case?
>
> I understood that we only need to use sstablerepairedset on the SSTables
> related to the tables using LCS compaction strategy and which were created
> before the auto compaction was disabled.
> Is my understanding correct?
>
> The documentation is not very explicit but I suppose the following
> sentence:
> "4. Use the tool sstablerepairedset to mark all the SSTables that were
> created before you disabled compaction."
> means we need to invoke "sstablerepairedset --is-repaired -f
> list_of_sstable_names.txt" on the LCS SSTables that were created before the
> compaction was disabled.
>
> Is this correct?
>
> Do we need to enableautocompaction again after the Cassandra restart or is
> it done automatically?
>
> Would you recommend us to upgrade our Cassandra version before starting
> the incremental repair migration?
>
> Thank you for your help and sorry for the long e-mail.
>
> Reynald
>
>
>
>
>
>
>

Re: Range scans

[Anuj Wadehra]

Hi Chandra,


I will comment on some points. Someone else can take remaining ones:


1. Secondary Index are only useful when data returned by the index query is in 
hundreds. Fetching large data using secondary index would be very slow. 
Secondary indexes dont scale well.


2.token query should be of form:


Where token(key) > «some token»



You are again applying token function on right side of comparison operator and 
thats why 

getting unexpected results.



Thanks

Anuj



Sent from Yahoo Mail on Android

From:"Chandra Sekar KR" 
Date:Thu, 19 Nov, 2015 at 3:16 pm
Subject:Range scans

Hi,


I would like to run a range scan on timestamp column b with secondary indexes 
without passing the partition key. I'm aware that Cassandra does not support 
range scans on secondary indexes unless one more column (primary/secondary 
index) clause with an = operator is supplied.


CREATE TABLE test (
    a timeuuid PRIMARY KEY,
    b timestamp,
    c varint
);
CREATE INDEX indx_b ON test (b);


INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 100);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 101);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 102);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 103);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 104);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 105);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 106);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 107);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 108);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 109);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 110);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 111);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 112);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 113);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 114);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 115);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 116);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 117);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 118);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 119);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 120);


Also, is there any alternate way of running range scans on column a using TOKEN 
function, similar to below. I tried running the same, but was getting 
unexpected results.


SELECT * FROM test 

  WHERE TOKEN(a) >= TOKEN(3b84a5b0-8e8d-11e5-b494-c9d29cfa4efd) 

  AND TOKEN(a) <= TOKEN(3b8c94f0-8e8d-11e5-b494-c9d29cfa4efd);


Regards, Chandra Sekar KR

Running sstableloader from every node when migrating?

[George Sigletos]

Hello,

We would like to migrate one keyspace from a 6-node cluster to a 3-node one.

Since an individual node does not contain all data, this means that we
should run the sstableloader 6 times, one for each node of our cluster.

To be precise, do "nodetool flush " then run sstableloader -d <3
target nodes> 

Would that be the correct approach?

Thank you in advance,
George

Re: Range scans

[Anuj Wadehra]

Chandra,


I feel that you are trying to implement time series data pattern using 
secondary index and one column per row. I think a much better solution would be 
to partition data based on some logical row key ..if thats not availabke it may 
be hour/day + a bucket id (too prevent hot spots).. You should use timeuuid as 
clustering key and you will be able to query data based on clustering key 
(time) most efficiently..


To understand data modelling of time series data using clustering key, Please 
visit 
https://academy.datastax.com/demos/getting-started-time-series-data-modeling


And


http://intellidzine.blogspot.in/2014/01/cassandra-data-modelling-primary-keys.html?m=1


Thanks

Anuj


Sent from Yahoo Mail on Android

From:"Anuj Wadehra" 
Date:Thu, 19 Nov, 2015 at 5:31 pm
Subject:Re: Range scans

Hi Chandra,


I will comment on some points. Someone else can take remaining ones:


1. Secondary Index are only useful when data returned by the index query is in 
hundreds. Fetching large data using secondary index would be very slow. 
Secondary indexes dont scale well.


2.token query should be of form:


Where token(key) > «some token»



You are again applying token function on right side of comparison operator and 
thats why 

getting unexpected results.



Thanks

Anuj



Sent from Yahoo Mail on Android

From:"Chandra Sekar KR" 
Date:Thu, 19 Nov, 2015 at 3:16 pm
Subject:Range scans

Hi,


I would like to run a range scan on timestamp column b with secondary indexes 
without passing the partition key. I'm aware that Cassandra does not support 
range scans on secondary indexes unless one more column (primary/secondary 
index) clause with an = operator is supplied.


CREATE TABLE test (
    a timeuuid PRIMARY KEY,
    b timestamp,
    c varint
);
CREATE INDEX indx_b ON test (b);


INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 100);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 101);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 102);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 103);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 104);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 105);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 106);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 107);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 108);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 109);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 110);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 111);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 112);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 113);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 114);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 115);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 116);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 117);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 118);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 119);

INSERT INTO TEST(a,b,c) VALUES (now(), unixTimestampOf(now()), 120);


Also, is there any alternate way of running range scans on column a using TOKEN 
function, similar to below. I tried running the same, but was getting 
unexpected results.


SELECT * FROM test 

  WHERE TOKEN(a) >= TOKEN(3b84a5b0-8e8d-11e5-b494-c9d29cfa4efd) 

  AND TOKEN(a) <= TOKEN(3b8c94f0-8e8d-11e5-b494-c9d29cfa4efd);


Regards, Chandra Sekar KR

unsubscribe

[Sheck, Jacob]

unsubscribe



CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended 
recipient(s) and may contain confidential and privileged information. Any 
unauthorized review, use, disclosure or distribution of any kind is strictly 
prohibited. If you are not the intended recipient, please contact the sender 
via reply e-mail and destroy all copies of the original message. Thank you.