Re: How is the coordinator node in LOCAL_QUORUM chosen?

[Johnny Miller]

I always explicitly specify the local DC in my apps for the DC aware round 
robin policy in a multi DC deployment (localDC arg on the constructor)

http://docs.datastax.com/en/drivers/nodejs/3.0/module-policies_loadBalancing-DCAwareRoundRobinPolicy.html

Maybe just do that if you want to specify it.


> On 29 Mar 2016, at 23:04, Eric Stevens  wrote:
> 
> How this works is probably documented in greater detail at the link I 
> provided before than I can do justice to here. 
> 
> TokenAware uses its configured child strategy to determine node locality.  
> DCAwareRoundRobin uses a configuration property, or if all of its seed nodes 
> are in the same DC it assumes nodes in that DC to be local.  LatencyAware 
> uses latency metrics to determine locality.
> 
> LOCAL_XXX consistency, as the name implies is considered satisfied if _XXX 
> replicas in the coordinator node's local datacenter have acknowledged the 
> write (or answered for the read).  If your load balancer considers nodes from 
> multiple datacenters local (i.e. it's shipping queries to nodes that belong 
> in several DC's), local consistency is considered only against the local 
> datacenter of the node which is coordinating the query - that is to say that 
> consistency is not a driver level property, but a coordinator level property 
> that is supplied by the driver.
> 
>> On Tue, Mar 29, 2016 at 8:01 AM X. F. Li  wrote:
>> Thanks for the explanation. My question is
>> * How the client driver would determine which cassandra node is considered 
>> "local". Is it auto discovered (if so, how?) or manually specified somewhere?
>> * Whether local_xxx consistencies always fail when a partition is not 
>> replicated in the local DC, as specified in its replication strategy.
>> 
>>  Perhaps I should ask the node.js client authors about this.
>> 
>> 
>>> On Monday, March 28, 2016 07:47 PM, Eric Stevens wrote:
>>> > Local quorum works in the same data center as the coordinator node, but 
>>> > when an app server execute the write query, how is the coordinator node 
>>> > chosen?
>>> 
>>> It typically depends on the driver, and decent drivers offer you several 
>>> options for this, usually called load balancing strategy.  You indicate 
>>> that you're using the node.js driver (presumably the DataStax version), 
>>> which is documented here: 
>>> http://docs.datastax.com/en/developer/nodejs-driver/3.0/common/drivers/reference/tuningPolicies.html
>>> 
>>> I'm not familiar with the node.js driver, but I am familiar with the Java 
>>> driver, and since they use the same terminology RE load balancing, I'll 
>>> assume they work the same.
>>> 
>>> A typical way to set that up is to use TokenAware policy with 
>>> DCAwareRoundRobinPolicy as its child policy.  This will prefer to route 
>>> queries to the primary replica (or secondary replica if the primary is 
>>> offline) in the local datacenter for that query if it can be discovered 
>>> automatically by the driver, such as with prepared statements.  
>>> 
>>> Where the replica discovery can't be accomplished, TokenAware defers to the 
>>> child policy to choose the host.  In the case of DCAwareRoundRobinPolicy 
>>> that means it iterates through the hosts of the configured local datacenter 
>>> (defaulted to the DC of the seed nodes if they're all in the same DC) for 
>>> each subsequent execution.
>>> 
 On Fri, Mar 25, 2016 at 2:04 PM X. F. Li  wrote:
 Hello,
 
 Local quorum works in the same data center as the coordinator node, but
 when an app server execute the write query, how is the coordinator node
 chosen?
 
 I use the node.js driver. How do the driver client determine which
 cassandra nodes are in the same DC as the client node? Does it use
 private network IP [192.168.x.x etc] to auto detect, or must I manually
 provide a localBalancing policy by `new DCAwareRoundRobinPolicy(
 localDcName )`?
 
 If a partition is not available in the local DC, i.e. if the local
 replica node fails or all replica nodes are in remote DC, will local
 quorum fail? If it doesn't fail, there is no guarantee that it all
 queries on a partition will be directed to the same data center, so does
 it means strong consistency cannot be expected?
 
 Another question:
 
 Suppose I have replication factor 3. If one of the node fails, will
 queries with ALL consistency fail if the queried partition is on the
 failed node? Or would they continue to work with 2 replicas during the
 time while cassandra is replicating the partitions on the failed node to
 re-establish 3 replicas?
 
 Thank you.
 Regards,
 
 X. F. Li

Re: NTP Synchronization Setup Changes

[Jan Kesten]

Hi Mickey,

I would strongly suggest to setup a NTP server on your site - this is not 
really a big deal and with some tutorials on the net done quickly. Then 
configure your cassandra nodes (and all the rest if you like) to use your ntp 
instead of public ones. As I have learned the hard way - cassandra is not 
really happy when nodes have different times in some cases.

Benefit of this is, that your nodes will keep time in sync even without 
connection to the internet. Of course "your time" may drift without a proper 
timesource or connection but all nodes will have the same drift and so no 
problems with consistency. If your ntp syncs your nodes will be adjusted 
smoothly.

Pro(?)-solution (what I did before): Attach a gps mouse to your ntp server and 
use that as time source. So you can have synchronized _and_ accurate time 
without any connection to public ntp servers as the gps satellites are flying 
atom clocks :)

Just my 2 cents,
Jan

Von meinem iPhone gesendet

> Am 31.03.2016 um 03:07 schrieb Mukil Kesavan :
> 
> Hi,
> 
> We run a 3 server cassandra cluster that is initially NTP synced to a single 
> physical server over LAN. This server does not have connectivity to the 
> internet for a few hours to sometimes even days. In this state we perform 
> some schema operations and reads/writes with QUORUM consistency.
> 
> Later on, the physical server has connectivity to the internet and we 
> synchronize its time to an external NTP server on the internet. 
> 
> Are there any issues if this causes a huge time correction on the cassandra 
> cluster? I know that NTP gradually corrects the time on all the servers. I 
> just wanted to understand if there were any corner cases that will cause us 
> to lose data/schema updates when this happens. In particular, we seem to be 
> having some issues around missing secondary indices at the moment (not all 
> but some).
> 
> Also, for our situation where we have to work with cassandra for a while 
> without internet connectivity, what is the preferred NTP architecture/steps 
> that have worked for you in the field?
> 
> Thanks,
> Micky

NTP Synchronization Setup Changes

[Mukil Kesavan]

Hi,

We run a 3 server cassandra cluster that is initially NTP synced to a
single physical server over LAN. This server does not have connectivity to
the internet for a few hours to sometimes even days. In this state we
perform some schema operations and reads/writes with QUORUM consistency.

Later on, the physical server has connectivity to the internet and we
synchronize its time to an external NTP server on the internet.

Are there any issues if this causes a huge time correction on the cassandra
cluster? I know that NTP gradually corrects the time on all the servers. I
just wanted to understand if there were any corner cases that will cause us
to lose data/schema updates when this happens. In particular, we seem to be
having some issues around missing secondary indices at the moment (not all
but some).

Also, for our situation where we have to work with cassandra for a while
without internet connectivity, what is the preferred NTP architecture/steps
that have worked for you in the field?

Thanks,
Micky

Re: Speeding up "nodetool rebuild"

[Robert Coli]

On Wed, Mar 30, 2016 at 1:44 PM, Anubhav Kale 
wrote:

> Will changing compactionthroughput and streamingthroughput help with
> reducing the “rebuild” time on a brand new node ? We will do it both on the
> new node, and the nodes in source DC from where data is streamed.
>

 streamingthroughput yes, compactionthroughput pretty sure no.

As to other ways to make it faster, nope.

=Rob

Thrift composite partition key to cql migration

[Jan Kesten]

Hi,

while migrating the reminder of thrift operations in my application I 
came across a point where I cant find a good hint.


In our old code we used a composite with two strings as row / partition 
key and a similar composite as column key like this:


public Composite rowKey() {
final Composite composite = new Composite();
composite.addComponent(key1, StringSerializer.get());
composite.addComponent(key2, StringSerializer.get());
return composite;
}

public Composite columnKey() {
final Composite composite = new Composite();
composite.addComponent(key3, StringSerializer.get());
composite.addComponent(key4, StringSerializer.get());
return composite;
}

In cql this columnfamiliy looks like this:

CREATE TABLE foo.bar (
key blob,
column1 text,
column2 text,
value blob,
PRIMARY KEY (key, column1, column2)
)

For the columns key3 and key4 became column1 and column2 - but the old 
rowkey is presented as blob (I can put it into a hex editor and see that 
key1 and key2 values are in there).


Any pointers to handle this or is this a known issue? I am using now 
DataStax Java driver for CQL, old connector used thrift. Is there any 
way to get key1 and key2 back apart from completly rewriting the table? 
This is what I had expected it to be:


CREATE TABLE foo.bar (
key1 text,
key2 text,
column1 text,
column2 text,
value blob,
PRIMARY KEY ((key1, key2), column1, column2)
)

Cheers,
Jan

Speeding up "nodetool rebuild"

[Anubhav Kale]

Hello,

Will changing compactionthroughput and streamingthroughput help with reducing 
the "rebuild" time on a brand new node ? We will do it both on the new node, 
and the nodes in source DC from where data is streamed.

Any other ways to make the "rebuild" faster ?

Thanks !

Thrift row cache in Cassandra 2.1

[AJ]

Hi,

I am having to tune a legacy app to use row caching (the why is unimportant). I 
know Thrift is EOL etc.. However, I have to do it.

I am unable to work out what the values to set on the column family are now 
with the changes in Caching (i.e. rows_per_partition). Previously you would set 
them to all, keys_only, rows_only, or none - is this still the case? The docs 
seem to indicate you can only set it to keys or rows_per_partition… When I set 
it to all n CF via cassandra-cli it says rows_per_partition: 0 when I look at 
the CQL for the same CF.

Just a bit confused - if anyone can clarify it, would be appreciated.

Thanks,

AJ

Re: Inconsistent query results and node state

[Tyler Hobbs]

>
> org.apache.cassandra.service.DigestMismatchException: Mismatch for key
> DecoratedKey(-4908797801227889951, 4a41534b414e)
> (6a6c8ab013d7757e702af50cbdae045c vs 2ece61a01b2a640ac10509f4c49ae6fb)


That key matches the row you mentioned, so it seems like all of the
replicas should have converged on the same value for that row.  Do you
consistently get the *1969-12-31 19:00 *timestamp back now?  If not, try
selecting both "time" and "writetime(time)}" from that row and see what
write timestamps each of the values have.

The ArrayIndexOutOfBoundsException in response to nodetool compact looks
like a bug.  What version of Cassandra are you running?

On Wed, Mar 30, 2016 at 9:59 AM, Kai Wang  wrote:

> Do you have NTP setup on all nodes?
>
> On Tue, Mar 29, 2016 at 11:48 PM, Jason Kania 
> wrote:
>
>> We have encountered a query inconsistency problem wherein the following
>> query returns different results sporadically with invalid values for a
>> timestamp field looking like the field is uninitialized (a zero timestamp)
>> in the query results.
>>
>> Attempts to repair and compact have not changed the results.
>>
>> select "subscriberId","sensorUnitId","sensorId","time" from
>> "sensorReadingIndex" where "subscriberId"='JASKAN' AND "sensorUnitId"=0 AND
>> "sensorId"=0 ORDER BY "time" LIMIT 10;
>>
>> Invalid Query Results
>> subscriberIdsensorUnitIdsensorIdtime
>> JASKAN002015-05-24 2:09
>> JASKAN00*1969-12-31 19:00*
>> JASKAN002016-01-21 2:10
>> JASKAN002016-01-21 2:10
>> JASKAN002016-01-21 2:10
>> JASKAN002016-01-21 2:11
>> JASKAN002016-01-21 2:22
>> JASKAN002016-01-21 2:22
>> JASKAN002016-01-21 2:22
>> JASKAN002016-01-21 2:22
>>
>> Valid Query Results
>> subscriberIdsensorUnitIdsensorIdtime
>> JASKAN002015-05-24 2:09
>> JASKAN002015-05-24 2:09
>> JASKAN002015-05-24 2:10
>> JASKAN002015-05-24 2:10
>> JASKAN002015-05-24 2:10
>> JASKAN002015-05-24 2:10
>> JASKAN002015-05-24 2:11
>> JASKAN002015-05-24 2:13
>> JASKAN002015-05-24 2:13
>> JASKAN002015-05-24 2:14
>>
>> We have confirmed that the 1969-12-31 timestamp is not within the data
>> based on running and number of queries so it looks like the invalid
>> timestamp value is generated by the query. The query below returns no row.
>>
>> select * from "sensorReadingIndex" where "subscriberId"='JASKAN' AND
>> "sensorUnitId"=0 AND "sensorId"=0 AND time='1969-12-31 19:00:00-0500';
>>
>> No logs are coming out but the following was observed intermittently in
>> the tracing output, but not correlated to the invalid query results:
>>
>>  Digest mismatch: org.apache.cassandra.service.DigestMismatchException:
>> Mismatch for key DecoratedKey(-7563144029910940626,
>> 00064a41534b414e040400)
>> (be22d379c18f75c2f51dd6942d2f9356 vs da4e95d571b41303b908e0c5c3fff7ba)
>> [ReadRepairStage:3179] | 2016-03-29 23:12:35.025000 | 192.168.10.10 |
>>
>> An error from the debug log that might be related is:
>>
>> org.apache.cassandra.service.DigestMismatchException: Mismatch for key
>> DecoratedKey(-4908797801227889951, 4a41534b414e)
>> (6a6c8ab013d7757e702af50cbdae045c vs 2ece61a01b2a640ac10509f4c49ae6fb)
>> at
>> org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java:85)
>> ~[apache-cassandra-3.0.3.jar:3.0.3]
>> at
>> org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:225)
>> ~[apache-cassandra-3.0.3.jar:3.0.3]
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> [na:1.8.0_74]
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> [na:1.8.0_74]
>> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_74]
>>
>> The tracing files are attached and seem to show that in the failed case,
>> content is skipped because of tombstones if we understand it correctly.
>> This could be an inconsistency problem on 192.168.10.9 Unfortunately,
>> attempts to compact on 192.168.10.9 only give the following error without
>> any stack trace detail and are not fixed with repair.
>>
>> root@cutthroat:/usr/local/bin/analyzer/bin# nodetool compact
>> error: null
>> -- StackTrace --
>> java.lang.ArrayIndexOutOfBoundsException
>>
>> Any suggestions on how to fix or what to search for would be much
>> appreciated.
>>
>> Thanks,
>>
>> Jason
>>
>>
>>
>>
>


-- 
Tyler Hobbs
DataStax 

Re: auto_boorstrap when a node is down

[Paulo Motta]

When you add a node it will take over the range of an existing node, and
thus it should stream data from it to maintain consistency. If the existing
node is unavailable, the new node may fetch the data from a different
replica, which may not have some of data from the node which you are taking
the range for, what may break consistency.

For example, imagine a ring with nodes A, B and C, RF=3. The row X=1 maps
to node A and is replicated in nodes B and C, so the initial arrangement
will be:

A(X=1), B(X=1) and C(X=1)

Node B is down and you write X=2 to A, which replicates the data only to C
since B is down (and hinted handoff is disabled). The write succeeds at
QUORUM. The new arragement becomes:

A(X=2), B(X=1), C(X=2) (if any of the nodes is down, any read at QUORUM
will fetch the correct value of X=2)

Now imagine you add a new node D between A and B. If D streams data from A,
the new replica group will become:

A, D(X=2), B(X=1), C(X=2) (if any of the nodes is down, any read at QUORUM
will fetch the correct value of X=2)

But if A is down when you bootstrap D and you have
-Dcassandra.consistent.rangemovement=false, D may stream data from B, so
the new replica group will be:

A, D(X=1), B(X=1), C(X=2)

Now, if C becomes down, reads at QUORUM will succeed but return the stale
value of X=1, so consistency is broken.

If you're continuously running repair, have hinted handoff and read repair
enabled, the probability of something like this happening will decrease,
but it may still happen. If this is not a problem you may use option
-Dcassandra.consistent.rangemovement=false to bootstrap a node when another
node is down. See CASSANDRA-2434 for more background.

2016-03-30 11:14 GMT-03:00 Peddi, Praveen :

> Hello all,
> We just upgraded to 2.2.4 (from 2.0.9) and we noticed one issue when new
> nodes are added. When we add a new node when no nodes are down in the
> cluster, everything works fine but when we add new node while 1 node is
> down, I am seeing following error. My understanding was when auto_bootstrap
> is enabled, bootstrapping process uses QUORUM consistency so it should work
> when one node is down. Is that not correct? Is there a way to add a new
> node with bootstrapping, but not using replace address option? We use auto
> scaling and new node gets added automatically when one node goes down and
> since its all scripted I can’t use replace address in cassandra-env.sh file
> as a one-time option.
>
> One fallback mechanism we could use is to disable auto bootstrap and let
> read repairs populate the data over time but its not ideal. Is this even a
> good alternative to this failure?
>
> ERROR 20:30:45 Exception encountered during startup
> java.lang.RuntimeException: A node required to move the data consistently
> is down (/xx.xx.xx.xx). If you wish to move the data from a potentially
> inconsistent replica, restart the node with
> -Dcassandra.consistent.rangemovement=false
>
> Praveen
>

Re: Inconsistent query results and node state

[Kai Wang]

Do you have NTP setup on all nodes?

On Tue, Mar 29, 2016 at 11:48 PM, Jason Kania  wrote:

> We have encountered a query inconsistency problem wherein the following
> query returns different results sporadically with invalid values for a
> timestamp field looking like the field is uninitialized (a zero timestamp)
> in the query results.
>
> Attempts to repair and compact have not changed the results.
>
> select "subscriberId","sensorUnitId","sensorId","time" from
> "sensorReadingIndex" where "subscriberId"='JASKAN' AND "sensorUnitId"=0 AND
> "sensorId"=0 ORDER BY "time" LIMIT 10;
>
> Invalid Query Results
> subscriberIdsensorUnitIdsensorIdtime
> JASKAN002015-05-24 2:09
> JASKAN00*1969-12-31 19:00*
> JASKAN002016-01-21 2:10
> JASKAN002016-01-21 2:10
> JASKAN002016-01-21 2:10
> JASKAN002016-01-21 2:11
> JASKAN002016-01-21 2:22
> JASKAN002016-01-21 2:22
> JASKAN002016-01-21 2:22
> JASKAN002016-01-21 2:22
>
> Valid Query Results
> subscriberIdsensorUnitIdsensorIdtime
> JASKAN002015-05-24 2:09
> JASKAN002015-05-24 2:09
> JASKAN002015-05-24 2:10
> JASKAN002015-05-24 2:10
> JASKAN002015-05-24 2:10
> JASKAN002015-05-24 2:10
> JASKAN002015-05-24 2:11
> JASKAN002015-05-24 2:13
> JASKAN002015-05-24 2:13
> JASKAN002015-05-24 2:14
>
> We have confirmed that the 1969-12-31 timestamp is not within the data
> based on running and number of queries so it looks like the invalid
> timestamp value is generated by the query. The query below returns no row.
>
> select * from "sensorReadingIndex" where "subscriberId"='JASKAN' AND
> "sensorUnitId"=0 AND "sensorId"=0 AND time='1969-12-31 19:00:00-0500';
>
> No logs are coming out but the following was observed intermittently in
> the tracing output, but not correlated to the invalid query results:
>
>  Digest mismatch: org.apache.cassandra.service.DigestMismatchException:
> Mismatch for key DecoratedKey(-7563144029910940626,
> 00064a41534b414e040400)
> (be22d379c18f75c2f51dd6942d2f9356 vs da4e95d571b41303b908e0c5c3fff7ba)
> [ReadRepairStage:3179] | 2016-03-29 23:12:35.025000 | 192.168.10.10 |
>
> An error from the debug log that might be related is:
>
> org.apache.cassandra.service.DigestMismatchException: Mismatch for key
> DecoratedKey(-4908797801227889951, 4a41534b414e)
> (6a6c8ab013d7757e702af50cbdae045c vs 2ece61a01b2a640ac10509f4c49ae6fb)
> at
> org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java:85)
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at
> org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:225)
> ~[apache-cassandra-3.0.3.jar:3.0.3]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_74]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_74]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_74]
>
> The tracing files are attached and seem to show that in the failed case,
> content is skipped because of tombstones if we understand it correctly.
> This could be an inconsistency problem on 192.168.10.9 Unfortunately,
> attempts to compact on 192.168.10.9 only give the following error without
> any stack trace detail and are not fixed with repair.
>
> root@cutthroat:/usr/local/bin/analyzer/bin# nodetool compact
> error: null
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException
>
> Any suggestions on how to fix or what to search for would be much
> appreciated.
>
> Thanks,
>
> Jason
>
>
>
>

Adding Options to Create Statements...

[James Carman]

I am trying to perform the following operation:

public Create createCreate() {
  Create create =
SchemaBuilder.createTable("foo").addPartitionColumn("bar",
varchar()).addClusteringColumn("baz", varchar);
  if(descending) {
create.withOptions().clusteringOrder("baz", Direction.DESC);
  return create;
}

I don't want to have to return the Create.Options object from this method
(as I may need to add other columns).  Is there a way to have the options
"decorate" the Create directly without having to return the Create.Options?

RE: Migration from 2.0.10 to 2.1.12

[aeljami.ext]

full is a reserved word in apache Cassandra / cql 3.1

https://cassandra.apache.org/doc/cql3/CQL.html#appendixA

*Reserved keywords cannot be used as identifier , they are truly reserved for 
the language (but one can enclose a reserved keyword by double-quotes to use it 
as an identifier)

De : Jean Carlo [mailto:jean.jeancar...@gmail.com]
Envoyé : mercredi 30 mars 2016 16:08
À : user@cassandra.apache.org
Objet : Re: Migration from 2.0.10 to 2.1.12

@Laing thx for the info.
@Carlos I also check that page and I did not find it. I was asking to know if 
someone has done smth to avoid change the column name everytime cassandra adds 
new words to the list.



Saludos

Jean Carlo

"The best way to predict the future is to invent it" Alan Kay

On Wed, Mar 30, 2016 at 4:02 PM, Carlos Alonso 
> wrote:
Well...

I guess that if full is a reserved word there's nothing you can do to change 
that but then, checking which are the keywords for that version it turns out 
that full is not there!!
https://docs.datastax.com/en/cql/3.1/cql/cql_reference/keywords_r.html

Maybe a bug?

Regards

Carlos Alonso | Software Engineer | @calonso

On 30 March 2016 at 15:41, Jean Carlo 
> wrote:
Yes we did some reads and writes, the problem is that adding double quotes 
force us to modify our code to change and insert like that

INSERT INTO table1 (bill_id, full, name,provider_date ,total) values 
('qs','full','name','2015-02-23','toltal');
to this

INSERT INTO table1 (bill_id, "full", name,provider_date ,total) values 
('qs','full','name','2015-02-23','toltal');
this last one is ok, but obviously the first one makes an error:

cqlsh:pns_fr_2_jean> INSERT INTO table1 (bill_id, full, name,provider_date 
,total) values ('qs','full','name','2015-02-23','toltal');
SyntaxException: 
and it is because the name of the column is not longer full, is "full"


Best regards

Jean Carlo

"The best way to predict the future is to invent it" Alan Kay

On Wed, Mar 30, 2016 at 3:26 PM, Eric Evans 
> wrote:
On Wed, Mar 30, 2016 at 8:08 AM, Jean Carlo 
> wrote:
> With double quotes it doesn't show error
>
> CREATE TABLE table1 ( bill_id text, "full" text, name text,
> provider_date timestamp, total text, PRIMARY KEY ( bill_id) ) ;
>
> but it changes the name of the column

I don't think it does though; You're meant to be able to use the
output of DESC TABLE to (re)create these tables, so it's quoted below
for the same reason you did so above.

Obviously it would be better to have column names that parse without
needing to be double quoted, but it should work.  Have you tried some
reads and writes?

> desc table table1;
>
> CREATE TABLE pns_fr_2_jean.table1 (
> bill_id text PRIMARY KEY,
> "full" text,
> name text,
> provider_date timestamp,
> total text
> )
>
> instead of
>
> CREATE TABLE pns_fr_2_jean.table1 (
> bill_id text PRIMARY KEY,
> full text,
> name text,
> provider_date timestamp,
> total text
> )

--
Eric Evans
eev...@wikimedia.org




_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

auto_boorstrap when a node is down

[Peddi, Praveen]

Hello all,
We just upgraded to 2.2.4 (from 2.0.9) and we noticed one issue when new nodes 
are added. When we add a new node when no nodes are down in the cluster, 
everything works fine but when we add new node while 1 node is down, I am 
seeing following error. My understanding was when auto_bootstrap is enabled, 
bootstrapping process uses QUORUM consistency so it should work when one node 
is down. Is that not correct? Is there a way to add a new node with 
bootstrapping, but not using replace address option? We use auto scaling and 
new node gets added automatically when one node goes down and since its all 
scripted I can't use replace address in cassandra-env.sh file as a one-time 
option.

One fallback mechanism we could use is to disable auto bootstrap and let read 
repairs populate the data over time but its not ideal. Is this even a good 
alternative to this failure?

ERROR 20:30:45 Exception encountered during startup
java.lang.RuntimeException: A node required to move the data consistently is 
down (/xx.xx.xx.xx). If you wish to move the data from a potentially 
inconsistent replica, restart the node with 
-Dcassandra.consistent.rangemovement=false

Praveen

Re: cqlsh problem

[Alain RODRIGUEZ]

Hi Joseph,

why cassandra using tcp6 for 9042 port like :
> tcp6   0  0 0.0.0.0:9042:::*LISTEN
>

if I remember correctly, in 2.1 and higher, cqlsh uses native transport,
port 9042  (instead of thrift port 9160) and your clients (if any) are also
probably using native transport (port 9042). So yes, this could be an issue
indeed.

You should have something like:

tcp0  0  1.2.3.4:9042   :::*LISTEN

You are using IPv6 and no rpc address. Try setting it to the listen address
and using IPv4.

C*heers,

---

Alain Rodriguez - al...@thelastpickle.com

France

The Last Pickle - Apache Cassandra Consulting

http://www.thelastpickle.com

2016-03-30 6:09 GMT+02:00 joseph gao :

> why cassandra using tcp6 for 9042 port like :
> tcp6   0  0 0.0.0.0:9042:::*LISTEN
> would this be the problem
>
> 2016-03-30 11:34 GMT+08:00 joseph gao :
>
>> still have not fixed it . cqlsh: error: no such option: --connect-timeout
>> cqlsh version 5.0.1
>>
>>
>>
>> 2016-03-25 16:46 GMT+08:00 Alain RODRIGUEZ :
>>
>>> Hi Joseph.
>>>
>>> As I can't reproduce here, I believe you are having network issue of
>>> some kind.
>>>
>>> MacBook-Pro:~ alain$ cqlsh --version
>>> cqlsh 5.0.1
>>> MacBook-Pro:~ alain$ echo 'DESCRIBE KEYSPACES;' | cqlsh
>>> --connect-timeout=5 --request-timeout=10
>>> system_traces  system
>>> MacBook-Pro:~ alain$
>>>
>>> It's been a few days, did you manage to fix it ?
>>>
>>> C*heers,
>>> ---
>>> Alain Rodriguez - al...@thelastpickle.com
>>> France
>>>
>>> The Last Pickle - Apache Cassandra Consulting
>>> http://www.thelastpickle.com
>>>
>>> 2016-03-21 9:59 GMT+01:00 joseph gao :
>>>
 cqlsh version 5.0.1. nodetool tpstats looks good, log looks good. And
 I used specified port 9042. And it immediately returns fail (less than 3
 seconds). By the way where should I use '--connect-timeout', cqlsh seems
 don't have such parameters.

 2016-03-18 17:29 GMT+08:00 Alain RODRIGUEZ :

> Is the node fully healthy or rejecting some requests ?
>
> What are the outputs for "grep -i "ERROR"
> /var/log/cassandra/system.log" and "nodetool tpstats"?
>
> Any error? Any pending / blocked or dropped messages?
>
> Also did you try using distinct ports (9160 for thrift, 9042 for
> native) - out of curiosity, not sure this will help.
>
> What is your version of cqlsh "cqlsh --version" ?
>
> doesn't work most times. But some time it just work fine
>>
>
> Do you fill like this is due to a timeout (query being too big,
> cluster being to busy)? Try setting this higher:
>
> --connect-timeout=CONNECT_TIMEOUT
>
> Specify the connection timeout in seconds
> (default: 5 seconds).
>
>   --request-timeout=REQUEST_TIMEOUT
>
> Specify the default request timeout in seconds 
> (default:
> 10 seconds).
>
> C*heers,
> ---
> Alain Rodriguez - al...@thelastpickle.com
> France
>
> The Last Pickle - Apache Cassandra Consulting
> http://www.thelastpickle.com
>
> 2016-03-18 4:49 GMT+01:00 joseph gao :
>
>> Of course yes.
>>
>> 2016-03-17 22:35 GMT+08:00 Vishwas Gupta 
>> :
>>
>>> Have you started the Cassandra service?
>>>
>>> sh cassandra
>>> On 17-Mar-2016 7:59 pm, "Alain RODRIGUEZ" 
>>> wrote:
>>>
 Hi, did you try with the address of the node rather than 127.0.0.1

 Is the transport protocol used by cqlsh (not sure if it is thrift
 or binary - native in 2.1)  active ? What is the "nodetool info" 
 output ?

 C*heers,
 ---
 Alain Rodriguez - al...@thelastpickle.com
 France

 The Last Pickle - Apache Cassandra Consulting
 http://www.thelastpickle.com

 2016-03-17 14:26 GMT+01:00 joseph gao :

> hi, all
> cassandra version 2.1.7
> When I use cqlsh to connect cassandra, something is wrong
>
> Connection error: ( Unable to connect to any servers',
> {'127.0.0.1': OperationTimedOut('errors=None, last_host=None,)})
>
> This happens lots of times, but sometime it works just fine.
> Anybody knows why?
>
> --
> --
> Joseph Gao
> PhoneNum:15210513582
> QQ: 409343351
>


>>
>>
>> --
>> --
>> Joseph Gao
>> PhoneNum:15210513582
>> QQ: 409343351
>>
>
>


 --
 --
 Joseph 

Re: Migration from 2.0.10 to 2.1.12

[Jean Carlo]

@Laing thx for the info.

@Carlos I also check that page and I did not find it. I was asking to know
if someone has done smth to avoid change the column name everytime
cassandra adds new words to the list.




Saludos

Jean Carlo

"The best way to predict the future is to invent it" Alan Kay

On Wed, Mar 30, 2016 at 4:02 PM, Carlos Alonso  wrote:

> Well...
>
> I guess that if full is a reserved word there's nothing you can do to
> change that but then, checking which are the keywords for that version it
> turns out that full is not there!!
> https://docs.datastax.com/en/cql/3.1/cql/cql_reference/keywords_r.html
>
> Maybe a bug?
>
> Regards
>
> Carlos Alonso | Software Engineer | @calonso 
>
> On 30 March 2016 at 15:41, Jean Carlo  wrote:
>
>> Yes we did some reads and writes, the problem is that adding double
>> quotes force us to modify our code to change and insert like that
>>
>> INSERT INTO table1 (bill_id, *full*, name,provider_date ,total) values
>> ('qs','full','name','2015-02-23','toltal');
>>
>> to this
>>
>> INSERT INTO table1 (bill_id, *"full"*, name,provider_date ,total) values
>> ('qs','full','name','2015-02-23','toltal');
>>
>> this last one is ok, but obviously the first one makes an error:
>>
>> cqlsh:pns_fr_2_jean> INSERT INTO table1 (bill_id, full,
>> name,provider_date ,total) values
>> ('qs','full','name','2015-02-23','toltal');
>> SyntaxException: > message="line 1:29 no viable alternative at input '*full*' (INSERT INTO
>> table1 (bill_id, [full]...)">
>>
>> and it is because the name of the column is not longer full, is "full"
>>
>>
>>
>> Best regards
>>
>> Jean Carlo
>>
>> "The best way to predict the future is to invent it" Alan Kay
>>
>> On Wed, Mar 30, 2016 at 3:26 PM, Eric Evans  wrote:
>>
>>> On Wed, Mar 30, 2016 at 8:08 AM, Jean Carlo 
>>> wrote:
>>> > With double quotes it doesn't show error
>>> >
>>> > CREATE TABLE table1 ( bill_id text, "full" text, name text,
>>> > provider_date timestamp, total text, PRIMARY KEY ( bill_id) ) ;
>>> >
>>> > but it changes the name of the column
>>>
>>> I don't think it does though; You're meant to be able to use the
>>> output of DESC TABLE to (re)create these tables, so it's quoted below
>>> for the same reason you did so above.
>>>
>>> Obviously it would be better to have column names that parse without
>>> needing to be double quoted, but it should work.  Have you tried some
>>> reads and writes?
>>>
>>> > desc table table1;
>>> >
>>> > CREATE TABLE pns_fr_2_jean.table1 (
>>> > bill_id text PRIMARY KEY,
>>> > "full" text,
>>> > name text,
>>> > provider_date timestamp,
>>> > total text
>>> > )
>>> >
>>> > instead of
>>> >
>>> > CREATE TABLE pns_fr_2_jean.table1 (
>>> > bill_id text PRIMARY KEY,
>>> > full text,
>>> > name text,
>>> > provider_date timestamp,
>>> > total text
>>> > )
>>>
>>>
>>> --
>>> Eric Evans
>>> eev...@wikimedia.org
>>>
>>
>>
>

Re: Migration from 2.0.10 to 2.1.12

[Carlos Alonso]

Well...

I guess that if full is a reserved word there's nothing you can do to
change that but then, checking which are the keywords for that version it
turns out that full is not there!!
https://docs.datastax.com/en/cql/3.1/cql/cql_reference/keywords_r.html

Maybe a bug?

Regards

Carlos Alonso | Software Engineer | @calonso 

On 30 March 2016 at 15:41, Jean Carlo  wrote:

> Yes we did some reads and writes, the problem is that adding double quotes
> force us to modify our code to change and insert like that
>
> INSERT INTO table1 (bill_id, *full*, name,provider_date ,total) values
> ('qs','full','name','2015-02-23','toltal');
>
> to this
>
> INSERT INTO table1 (bill_id, *"full"*, name,provider_date ,total) values
> ('qs','full','name','2015-02-23','toltal');
>
> this last one is ok, but obviously the first one makes an error:
>
> cqlsh:pns_fr_2_jean> INSERT INTO table1 (bill_id, full, name,provider_date
> ,total) values ('qs','full','name','2015-02-23','toltal');
> SyntaxException:  message="line 1:29 no viable alternative at input '*full*' (INSERT INTO
> table1 (bill_id, [full]...)">
>
> and it is because the name of the column is not longer full, is "full"
>
>
>
> Best regards
>
> Jean Carlo
>
> "The best way to predict the future is to invent it" Alan Kay
>
> On Wed, Mar 30, 2016 at 3:26 PM, Eric Evans  wrote:
>
>> On Wed, Mar 30, 2016 at 8:08 AM, Jean Carlo 
>> wrote:
>> > With double quotes it doesn't show error
>> >
>> > CREATE TABLE table1 ( bill_id text, "full" text, name text,
>> > provider_date timestamp, total text, PRIMARY KEY ( bill_id) ) ;
>> >
>> > but it changes the name of the column
>>
>> I don't think it does though; You're meant to be able to use the
>> output of DESC TABLE to (re)create these tables, so it's quoted below
>> for the same reason you did so above.
>>
>> Obviously it would be better to have column names that parse without
>> needing to be double quoted, but it should work.  Have you tried some
>> reads and writes?
>>
>> > desc table table1;
>> >
>> > CREATE TABLE pns_fr_2_jean.table1 (
>> > bill_id text PRIMARY KEY,
>> > "full" text,
>> > name text,
>> > provider_date timestamp,
>> > total text
>> > )
>> >
>> > instead of
>> >
>> > CREATE TABLE pns_fr_2_jean.table1 (
>> > bill_id text PRIMARY KEY,
>> > full text,
>> > name text,
>> > provider_date timestamp,
>> > total text
>> > )
>>
>>
>> --
>> Eric Evans
>> eev...@wikimedia.org
>>
>
>

Re: Migration from 2.0.10 to 2.1.12

[Laing, Michael]

fyi the list of reserved keywords is at:

https://cassandra.apache.org/doc/cql3/CQL.html#appendixA

ml

On Wed, Mar 30, 2016 at 9:41 AM, Jean Carlo 
wrote:

> Yes we did some reads and writes, the problem is that adding double quotes
> force us to modify our code to change and insert like that
>
> INSERT INTO table1 (bill_id, *full*, name,provider_date ,total) values
> ('qs','full','name','2015-02-23','toltal');
>
> to this
>
> INSERT INTO table1 (bill_id, *"full"*, name,provider_date ,total) values
> ('qs','full','name','2015-02-23','toltal');
>
> this last one is ok, but obviously the first one makes an error:
>
> cqlsh:pns_fr_2_jean> INSERT INTO table1 (bill_id, full, name,provider_date
> ,total) values ('qs','full','name','2015-02-23','toltal');
> SyntaxException:  message="line 1:29 no viable alternative at input '*full*' (INSERT INTO
> table1 (bill_id, [full]...)">
>
> and it is because the name of the column is not longer full, is "full"
>
>
>
> Best regards
>
> Jean Carlo
>
> "The best way to predict the future is to invent it" Alan Kay
>
> On Wed, Mar 30, 2016 at 3:26 PM, Eric Evans  wrote:
>
>> On Wed, Mar 30, 2016 at 8:08 AM, Jean Carlo 
>> wrote:
>> > With double quotes it doesn't show error
>> >
>> > CREATE TABLE table1 ( bill_id text, "full" text, name text,
>> > provider_date timestamp, total text, PRIMARY KEY ( bill_id) ) ;
>> >
>> > but it changes the name of the column
>>
>> I don't think it does though; You're meant to be able to use the
>> output of DESC TABLE to (re)create these tables, so it's quoted below
>> for the same reason you did so above.
>>
>> Obviously it would be better to have column names that parse without
>> needing to be double quoted, but it should work.  Have you tried some
>> reads and writes?
>>
>> > desc table table1;
>> >
>> > CREATE TABLE pns_fr_2_jean.table1 (
>> > bill_id text PRIMARY KEY,
>> > "full" text,
>> > name text,
>> > provider_date timestamp,
>> > total text
>> > )
>> >
>> > instead of
>> >
>> > CREATE TABLE pns_fr_2_jean.table1 (
>> > bill_id text PRIMARY KEY,
>> > full text,
>> > name text,
>> > provider_date timestamp,
>> > total text
>> > )
>>
>>
>> --
>> Eric Evans
>> eev...@wikimedia.org
>>
>
>

Re: Migration from 2.0.10 to 2.1.12

[Jean Carlo]

Yes we did some reads and writes, the problem is that adding double quotes
force us to modify our code to change and insert like that

INSERT INTO table1 (bill_id, *full*, name,provider_date ,total) values
('qs','full','name','2015-02-23','toltal');

to this

INSERT INTO table1 (bill_id, *"full"*, name,provider_date ,total) values
('qs','full','name','2015-02-23','toltal');

this last one is ok, but obviously the first one makes an error:

cqlsh:pns_fr_2_jean> INSERT INTO table1 (bill_id, full, name,provider_date
,total) values ('qs','full','name','2015-02-23','toltal');
SyntaxException: 

and it is because the name of the column is not longer full, is "full"



Best regards

Jean Carlo

"The best way to predict the future is to invent it" Alan Kay

On Wed, Mar 30, 2016 at 3:26 PM, Eric Evans  wrote:

> On Wed, Mar 30, 2016 at 8:08 AM, Jean Carlo 
> wrote:
> > With double quotes it doesn't show error
> >
> > CREATE TABLE table1 ( bill_id text, "full" text, name text,
> > provider_date timestamp, total text, PRIMARY KEY ( bill_id) ) ;
> >
> > but it changes the name of the column
>
> I don't think it does though; You're meant to be able to use the
> output of DESC TABLE to (re)create these tables, so it's quoted below
> for the same reason you did so above.
>
> Obviously it would be better to have column names that parse without
> needing to be double quoted, but it should work.  Have you tried some
> reads and writes?
>
> > desc table table1;
> >
> > CREATE TABLE pns_fr_2_jean.table1 (
> > bill_id text PRIMARY KEY,
> > "full" text,
> > name text,
> > provider_date timestamp,
> > total text
> > )
> >
> > instead of
> >
> > CREATE TABLE pns_fr_2_jean.table1 (
> > bill_id text PRIMARY KEY,
> > full text,
> > name text,
> > provider_date timestamp,
> > total text
> > )
>
>
> --
> Eric Evans
> eev...@wikimedia.org
>

Re: Migration from 2.0.10 to 2.1.12

[Eric Evans]

On Wed, Mar 30, 2016 at 8:08 AM, Jean Carlo  wrote:
> With double quotes it doesn't show error
>
> CREATE TABLE table1 ( bill_id text, "full" text, name text,
> provider_date timestamp, total text, PRIMARY KEY ( bill_id) ) ;
>
> but it changes the name of the column

I don't think it does though; You're meant to be able to use the
output of DESC TABLE to (re)create these tables, so it's quoted below
for the same reason you did so above.

Obviously it would be better to have column names that parse without
needing to be double quoted, but it should work.  Have you tried some
reads and writes?

> desc table table1;
>
> CREATE TABLE pns_fr_2_jean.table1 (
> bill_id text PRIMARY KEY,
> "full" text,
> name text,
> provider_date timestamp,
> total text
> )
>
> instead of
>
> CREATE TABLE pns_fr_2_jean.table1 (
> bill_id text PRIMARY KEY,
> full text,
> name text,
> provider_date timestamp,
> total text
> )


-- 
Eric Evans
eev...@wikimedia.org

Re: Acceptable repair time

[Anishek Agarwal]

we have about 380GB / RF = 3 ~ 1200 GB on disk. since we are on 2.0.17
there is no incremental repair :(

On Tue, Mar 29, 2016 at 6:05 PM, Kai Wang  wrote:

> IIRC when we switched to LCS and ran the first full repair with
> 250GB/RF=3, it took at least 12 hours for the repair to finish, then
> another 3+ days for all the compaction to catch up. I called it "the big
> bang of LCS".
>
> Since then we've been running nightly incremental repair.
>
> For me as long as it's reliable (no streaming error, better progress
> reporting etc), I actually don't mind it it takes more than a few hours to
> do a full repair. But I am not sure about 4 days... I guess it depends on
> the size of the cluster and data...
>
> On Tue, Mar 29, 2016 at 6:04 AM, Anishek Agarwal 
> wrote:
>
>> I would really like to know the answer for above because on some nodes
>> repair takes almost 4 days for us :(.
>>
>> On Tue, Mar 29, 2016 at 8:34 AM, Jack Krupansky > > wrote:
>>
>>> Someone recently asked me for advice when their repair time was 2-3
>>> days. I thought that was outrageous, but not unheard of. Personally, to me,
>>> 2-3 hours would be about the limit of what I could tolerate, and my
>>> personal goal would be that a full repair of a node should take no longer
>>> than an hour, maybe 90 minutes tops. But... achieving those more
>>> abbreviated repair times would strongly suggest that the amount of data on
>>> each node be kept down to a tiny fraction of a typical spinning disk drive,
>>> or even a fraction of a larger SSD drive.
>>>
>>> So, my question here is what people consider acceptable full repair
>>> times for nodes and what the resulting node data size is.
>>>
>>> What impact vnodes has on these numbers is a bonus question.
>>>
>>> Thanks!
>>>
>>> -- Jack Krupansky
>>>
>>
>>
>

Re: Migration from 2.0.10 to 2.1.12

[Jean Carlo]

With double quotes it doesn't show error

CREATE TABLE table1 ( bill_id text, "full" text, name text,
provider_date timestamp, total text, PRIMARY KEY ( bill_id) ) ;

but it changes the name of the column

desc table table1;

CREATE TABLE pns_fr_2_jean.table1 (
bill_id text PRIMARY KEY,
*"full" text,*
name text,
provider_date timestamp,
total text
)

instead of

CREATE TABLE pns_fr_2_jean.table1 (
bill_id text PRIMARY KEY,
*full text,*
name text,
provider_date timestamp,
total text
)

and with singles quotes the result is an error

CREATE TABLE table1 ( bill_id text,   *  'full' text*, name
text, provider_date timestamp, total text, PRIMARY KEY (
bill_id) ) ;
SyntaxException: 


So far using double quotes doesn't resolve my problem



Saludos

Jean Carlo

"The best way to predict the future is to invent it" Alan Kay

On Wed, Mar 30, 2016 at 12:53 PM, Carlos Alonso  wrote:

> Try surrounding it with quotes.
>
> Didn't know about the reserved keyword full though.
>
> Regards
>
> Carlos Alonso | Software Engineer | @calonso 
>
> On 30 March 2016 at 10:36, Jean Carlo  wrote:
>
>> Hi!
>>
>> I am creating my new tables on cassandra 2.1.12 and I have this one
>>
>> CREATE TABLE table1 (
>> bill_id text,
>> full text,
>> name text,
>> provider_date timestamp,
>> total text,
>> PRIMARY KEY ( bill_id)
>> )
>>
>> And cassandra tells me this error
>>
>> SyntaxException: > message="line 1:44 mismatched input 'full' expecting ')' (... table1 (
>> bill_id text, [full] text...)">
>>
>> Is the word "full" reserved by cassandra?
>>
>> In order to not change all the configuration in production, there is a
>> way to conserve the name of my column as it was with the version 2.0.10?
>>
>>
>> Saludos
>>
>> Jean Carlo
>>
>> "The best way to predict the future is to invent it" Alan Kay
>>
>
>

Re: Multi DC setup for analytics

[Anishek Agarwal]

Hey Guys,

We did the necessary changes and were trying to get this back on track, but
hit another wall,

we have two Clusters in Different DC ( DC1 and DC2) with cluster names (
CLUSTER_1, CLUSTER_2)

we want to have a common analytics cluster in DC3 with cluster name
(CLUSTER_3). -- looks like this can't be done, so we have to setup two
different analytics cluster ? can't we just get data from CLUSTER_1/2 to
same cluster CLUSTER_3 ?

thanks
anishek

On Mon, Mar 21, 2016 at 3:31 PM, Anishek Agarwal  wrote:

> Hey Clint,
>
> we have two separate rings which don't talk to each other but both having
> the same DC name "DCX".
>
> @Raja,
>
> We had already gone towards the path you suggested.
>
> thanks all
> anishek
>
> On Fri, Mar 18, 2016 at 8:01 AM, Reddy Raja  wrote:
>
>> Yes. Here are the steps.
>> You will have to change the DC Names first.
>> DC1 and DC2 would be independent clusters.
>>
>> Create a new DC, DC3 and include these two DC's on DC3.
>>
>> This should work well.
>>
>>
>> On Thu, Mar 17, 2016 at 11:03 PM, Clint Martin <
>> clintlmar...@coolfiretechnologies.com> wrote:
>>
>>> When you say you have two logical DC both with the same name are you
>>> saying that you have two clusters of servers both with the same DC name,
>>> nether of which currently talk to each other? IE they are two separate
>>> rings?
>>>
>>> Or do you mean that you have two keyspaces in one cluster?
>>>
>>> Or?
>>>
>>> Clint
>>> On Mar 14, 2016 2:11 AM, "Anishek Agarwal"  wrote:
>>>
 Hello,

 We are using cassandra 2.0.17 and have two logical DC having different
 Keyspaces but both having same logical name DC1.

 we want to setup another cassandra cluster for analytics which should
 get data from both the above DC.

 if we setup the new DC with name DC2 and follow the steps
 https://docs.datastax.com/en/cassandra/2.0/cassandra/operations/ops_add_dc_to_cluster_t.html
 will it work ?

 I would think we would have to first change the names of existing
 clusters to have to different names and then go with adding another dc
 getting data from these?

 Also as soon as we add the node the data starts moving... this will all
 be only real time changes done to the cluster right ? we still have to do
 the rebuild to get the data for tokens for node in new cluster ?

 Thanks
 Anishek

>>>
>>
>>
>> --
>> "In this world, you either have an excuse or a story. I preferred to have
>> a story"
>>
>
>

Re: Can we lengthy big column names in cassandra 3.0.3

[Bhuvan Rawal]

It has been discussed in past in
https://issues.apache.org/jira/browse/CASSANDRA-4175.

I believe it is fixed in
https://issues.apache.org/jira/browse/CASSANDRA-8099, though we have not
evaluated the performance. Will be glad if someone can reply with
benchmarks.

On Wed, Mar 30, 2016 at 4:49 PM, Atul Saroha 
wrote:

> Hi,
>
>
> Some time back, I had seen a Jira which tells me that the limitation to
> use small column names for performance benefit is no longer valid. Now
> cassandra generate some unique identifier for each column name in the
> table. So larger table name and column names are no longer an issue for
> performance and data storage.
>
> Is this true for cassandra 3.0.3?
> Does anyone knows that Jira number as i missed it?
>
> -
> Atul Saroha
> *Sr. 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
>

Can we lengthy big column names in cassandra 3.0.3

[Atul Saroha]

Hi,


Some time back, I had seen a Jira which tells me that the limitation to use
small column names for performance benefit is no longer valid. Now
cassandra generate some unique identifier for each column name in the
table. So larger table name and column names are no longer an issue for
performance and data storage.

Is this true for cassandra 3.0.3?
Does anyone knows that Jira number as i missed it?
-
Atul Saroha
*Sr. 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: Migration from 2.0.10 to 2.1.12

[Carlos Alonso]

Try surrounding it with quotes.

Didn't know about the reserved keyword full though.

Regards

Carlos Alonso | Software Engineer | @calonso 

On 30 March 2016 at 10:36, Jean Carlo  wrote:

> Hi!
>
> I am creating my new tables on cassandra 2.1.12 and I have this one
>
> CREATE TABLE table1 (
> bill_id text,
> full text,
> name text,
> provider_date timestamp,
> total text,
> PRIMARY KEY ( bill_id)
> )
>
> And cassandra tells me this error
>
> SyntaxException:  message="line 1:44 mismatched input 'full' expecting ')' (... table1 (
> bill_id text, [full] text...)">
>
> Is the word "full" reserved by cassandra?
>
> In order to not change all the configuration in production, there is a way
> to conserve the name of my column as it was with the version 2.0.10?
>
>
> Saludos
>
> Jean Carlo
>
> "The best way to predict the future is to invent it" Alan Kay
>

Migration from 2.0.10 to 2.1.12

[Jean Carlo]

Hi!

I am creating my new tables on cassandra 2.1.12 and I have this one

CREATE TABLE table1 (
bill_id text,
full text,
name text,
provider_date timestamp,
total text,
PRIMARY KEY ( bill_id)
)

And cassandra tells me this error

SyntaxException: 

Is the word "full" reserved by cassandra?

In order to not change all the configuration in production, there is a way
to conserve the name of my column as it was with the version 2.0.10?


Saludos

Jean Carlo

"The best way to predict the future is to invent it" Alan Kay