Speeding up "nodetool rebuild"

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 composite partition key to cql migration

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() {

Re: Speeding up "nodetool rebuild"

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

NTP Synchronization Setup Changes

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.

Re: How is the coordinator node in LOCAL_QUORUM chosen?

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

Re: NTP Synchronization Setup Changes

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 -

Can we lengthy big column names in cassandra 3.0.3

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

Re: Migration from 2.0.10 to 2.1.12

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

Re: Can we lengthy big column names in cassandra 3.0.3

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,

Re: Multi DC setup for analytics

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

Re: Acceptable repair time

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

Migration from 2.0.10 to 2.1.12

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"

Re: Migration from 2.0.10 to 2.1.12

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

Re: Migration from 2.0.10 to 2.1.12

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"*,

auto_boorstrap when a node is down

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

Re: Migration from 2.0.10 to 2.1.12

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

Re: Migration from 2.0.10 to 2.1.12

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 |

Re: cqlsh problem

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

Re: Migration from 2.0.10 to 2.1.12

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

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

RE: Migration from 2.0.10 to 2.1.12

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 :

Re: Inconsistent query results and node state

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

Adding Options to Create Statements...

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

Re: Inconsistent query results and node state

> > 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

Re: auto_boorstrap when a node is down

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

Thrift row cache in Cassandra 2.1

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