date:20170718

Re: write time for nulls is not consistent

2017-07-18 Thread Subroto Barua

Works fine either case on 3.0.12 

Subroto 

> On Jul 18, 2017, at 2:41 PM, kurt greaves  wrote:
> 
> can you try select a, writetime(b) from test.t
> I heard of an issue recently where cqlsh reports null incorrectly if you 
> query a column twice, wondering if it extends to this case with writetime.


-
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org

Debugging requests blocking because of max_queued_native_transport_requests

2017-07-18 Thread Sotirios Delimanolis

A deployment of mine is hitting the 
cassandra.max_queued_native_transport_requests limit quite often. I'd like to 
trace which batch of requests caused Cassandra to go over the limit, by adding 
some logs to Cassandra 2.2.
I was considering setting some thread local flag when we block and verifying it 
when we execute the request's corresponding Message, but the maze of work 
stealing in SharedExecutorPool is confusing me. Where could I plug in to log, 
for example, the keyspace and table name of any request that increased the 
queued tasks over the limit?

Re: write time for nulls is not consistent

2017-07-18 Thread kurt greaves

can you try select a, writetime(b) from test.t
I heard of an issue recently where cqlsh reports null incorrectly if you
query a column twice, wondering if it extends to this case with writetime.

Re: Moving from DSE to Cassandra.

2017-07-18 Thread Harikrishnan Pillai

yes.

From: Harikrishnan Pillai 
Sent: Tuesday, July 18, 2017 12:30 PM
To: user@cassandra.apache.org
Subject: EXT: Re: Moving from DSE to Cassandra.

Moving away from DSE to apache cassandra is easy.

If there are any keyspace with "EverywhereStrategy" strategies, change them to 
"NetworkTopologyStrategy" first.

particularly DSE system. Start in opensource  mode and run sstable upgrade if 
needed.

Regards

Hari

From: Pranay akula 
Sent: Tuesday, July 18, 2017 12:24 PM
To: user@cassandra.apache.org
Subject: EXT: Moving from DSE to Cassandra.

Planning to move from DSE to open source cassandra.

What will be better way to do it.

1) I am thinking of introducing new datacenter  with apache cassandra and 
replicating to that DC and after data replication remove DSE cassandra DC
2) Upgrading from current DSE version to later version of cassandra possibly 
2.2 or 3.x

Has anyone did it before any issues faced ??

Thanks
Pranay.

Re: Moving from DSE to Cassandra.

2017-07-18 Thread Pranay akula

So once i migrate to open source cassandra do i really need DSE keyspace ??
can't  i just remove it ??



Thanks
Pranay.

On Tue, Jul 18, 2017 at 3:30 PM, Harikrishnan Pillai <
hpil...@walmartlabs.com> wrote:

> Moving away from DSE to apache cassandra is easy.
>
> If there are any keyspace with "EverywhereStrategy" strategies, change
> them to "NetworkTopologyStrategy" first.
>
> particularly DSE system. Start in opensource  mode and run sstable
> upgrade if needed.
>
> Regards
>
> Hari
>
>
> --
> *From:* Pranay akula 
> *Sent:* Tuesday, July 18, 2017 12:24 PM
> *To:* user@cassandra.apache.org
> *Subject:* EXT: Moving from DSE to Cassandra.
>
> Planning to move from DSE to open source cassandra.
>
> What will be better way to do it.
>
> 1) I am thinking of introducing new datacenter  with apache cassandra and
> replicating to that DC and after data replication remove DSE cassandra DC
> 2) Upgrading from current DSE version to later version of cassandra
> possibly 2.2 or 3.x
>
> Has anyone did it before any issues faced ??
>
>
>
>
>
>
>
> Thanks
> Pranay.
>

Re: Moving from DSE to Cassandra.

2017-07-18 Thread Harikrishnan Pillai

Moving away from DSE to apache cassandra is easy.

If there are any keyspace with "EverywhereStrategy" strategies, change them to 
"NetworkTopologyStrategy" first.

particularly DSE system. Start in opensource  mode and run sstable upgrade if 
needed.

Regards

Hari



From: Pranay akula 
Sent: Tuesday, July 18, 2017 12:24 PM
To: user@cassandra.apache.org
Subject: EXT: Moving from DSE to Cassandra.

Planning to move from DSE to open source cassandra.

What will be better way to do it.

1) I am thinking of introducing new datacenter  with apache cassandra and 
replicating to that DC and after data replication remove DSE cassandra DC
2) Upgrading from current DSE version to later version of cassandra possibly 
2.2 or 3.x

Has anyone did it before any issues faced ??







Thanks
Pranay.

Re: write time for nulls is not consistent

2017-07-18 Thread Nitan Kainth

insert into test.t (a ) values ('v’);

> On Jul 18, 2017, at 2:28 PM, Jonathan Haddad  wrote:
> 
> Since you didn't show all the queries you used, I made an assumption that 
> you've inserted other data.  Where is the query that inserted a="v"?  I don't 
> know how to answer the question if you're not actually showing how to 
> reproduce the problem.
> 
> 
> On Tue, Jul 18, 2017 at 12:24 PM Nitan Kainth  > wrote:
> Jonathan,
> 
> Please notice last rows with partition key values (w,v and t). they were 
> inserted same way and has write time values
> 
>> On Jul 18, 2017, at 2:22 PM, Jonathan Haddad > > wrote:
>> 
>> This looks like expected behavior to me.  You aren't inserting a value for 
>> b.  Since there's no value, there's also no writetime.
>> 
>> On Tue, Jul 18, 2017 at 12:15 PM Nitan Kainth > > wrote:
>> Hi,
>> 
>> We see that null columns have writetime(column) populated for few columns 
>> and shows null for few other. Is it any bug or something else?
>> 
>> 
>> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 
>> 'us-east': '2'}  AND durable_writes = true;
>> 
>> CREATE TABLE test.t (
>> a text PRIMARY KEY,
>> b text
>> ) WITH bloom_filter_fp_chance = 0.01
>> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
>> AND comment = ''
>> AND compaction = {'class': 
>> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
>> 'max_threshold': '32', 'min_threshold': '4'}
>> AND compression = {'chunk_length_in_kb': '64', 'class': 
>> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>> AND crc_check_chance = 1.0
>> AND dclocal_read_repair_chance = 0.1
>> AND default_time_to_live = 0
>> AND gc_grace_seconds = 864000
>> AND max_index_interval = 2048
>> AND memtable_flush_period_in_ms = 0
>> AND min_index_interval = 128
>> AND read_repair_chance = 0.0
>> AND speculative_retry = '99PERCENTILE’;
>> 
>> insert into test.t (a ) values ('z’);
>> insert into test.t (a ) values ('w’);
>> insert into test.t (a ) values ('e’);
>> insert into test.t (a ) values ('r’);
>> insert into test.t (a ) values ('t’);
>> 
>>  select a,b, writetime (b) from test.t ;
>> 
>>  a | b| writetime(b)
>> ---+--+--
>>  z | null | null
>>  a | null | null
>>  c | null | null
>>  e | null | null
>>  r | null | null
>>  d | null | 1500400745074499
>>  w | null | 1500400745074499
>>  v | null | 1500400745074499
>>  t | null | 1500400745074499
>>  x |y | 1500400626266371
>

Re: write time for nulls is not consistent

2017-07-18 Thread Jonathan Haddad

Since you didn't show all the queries you used, I made an assumption that
you've inserted other data.  Where is the query that inserted a="v"?  I
don't know how to answer the question if you're not actually showing how to
reproduce the problem.


On Tue, Jul 18, 2017 at 12:24 PM Nitan Kainth  wrote:

> Jonathan,
>
> Please notice last rows with partition key values (w,v and t). they were
> inserted same way and has write time values
>
> On Jul 18, 2017, at 2:22 PM, Jonathan Haddad  wrote:
>
> This looks like expected behavior to me.  You aren't inserting a value for
> b.  Since there's no value, there's also no writetime.
>
> On Tue, Jul 18, 2017 at 12:15 PM Nitan Kainth  wrote:
>
>> Hi,
>>
>> We see that null columns have writetime(column) populated for few columns
>> and shows null for few other. Is it any bug or something else?
>>
>>
>> CREATE KEYSPACE test WITH replication = {'class':
>> 'NetworkTopologyStrategy', 'us-east': '2'}  AND durable_writes = true;
>>
>> CREATE TABLE test.t (
>> a text PRIMARY KEY,
>> b text
>> ) WITH bloom_filter_fp_chance = 0.01
>> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
>> AND comment = ''
>> AND compaction = {'class':
>> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
>> 'max_threshold': '32', 'min_threshold': '4'}
>> AND compression = {'chunk_length_in_kb': '64', 'class':
>> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>> AND crc_check_chance = 1.0
>> AND dclocal_read_repair_chance = 0.1
>> AND default_time_to_live = 0
>> AND gc_grace_seconds = 864000
>> AND max_index_interval = 2048
>> AND memtable_flush_period_in_ms = 0
>> AND min_index_interval = 128
>> AND read_repair_chance = 0.0
>> AND speculative_retry = '99PERCENTILE’;
>>
>> insert into test.t (a ) values ('z’);
>> insert into test.t (a ) values ('w’);
>> insert into test.t (a ) values ('e’);
>> insert into test.t (a ) values ('r’);
>> insert into test.t (a ) values ('t’);
>>
>>  select a,b, writetime (b) from test.t ;
>>
>>  *a* | *b*| *writetime(b)*
>> ---+--+--
>>  *z* | *null* | *null*
>>  *a* | *null* | *null*
>>  *c* | *null* | *null*
>>  *e* | *null* | *null*
>>  *r* | *null* | *null*
>>  *d* | *null* | *1500400745074499*
>>  *w* | *null* | *1500400745074499*
>>  *v* | *null* | *1500400745074499*
>>  *t* | *null* | *1500400745074499*
>>  *x* |*y* | *1500400626266371*
>>
>
>

Moving from DSE to Cassandra.

2017-07-18 Thread Pranay akula

Planning to move from DSE to open source cassandra.

What will be better way to do it.

1) I am thinking of introducing new datacenter  with apache cassandra and
replicating to that DC and after data replication remove DSE cassandra DC
2) Upgrading from current DSE version to later version of cassandra
possibly 2.2 or 3.x

Has anyone did it before any issues faced ??







Thanks
Pranay.

Re: write time for nulls is not consistent

2017-07-18 Thread Nitan Kainth

Jonathan,

Please notice last rows with partition key values (w,v and t). they were 
inserted same way and has write time values

> On Jul 18, 2017, at 2:22 PM, Jonathan Haddad  wrote:
> 
> This looks like expected behavior to me.  You aren't inserting a value for b. 
>  Since there's no value, there's also no writetime.
> 
> On Tue, Jul 18, 2017 at 12:15 PM Nitan Kainth  > wrote:
> Hi,
> 
> We see that null columns have writetime(column) populated for few columns and 
> shows null for few other. Is it any bug or something else?
> 
> 
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 
> 'us-east': '2'}  AND durable_writes = true;
> 
> CREATE TABLE test.t (
> a text PRIMARY KEY,
> b text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE’;
> 
> insert into test.t (a ) values ('z’);
> insert into test.t (a ) values ('w’);
> insert into test.t (a ) values ('e’);
> insert into test.t (a ) values ('r’);
> insert into test.t (a ) values ('t’);
> 
>  select a,b, writetime (b) from test.t ;
> 
>  a | b| writetime(b)
> ---+--+--
>  z | null | null
>  a | null | null
>  c | null | null
>  e | null | null
>  r | null | null
>  d | null | 1500400745074499
>  w | null | 1500400745074499
>  v | null | 1500400745074499
>  t | null | 1500400745074499
>  x |y | 1500400626266371

Re: write time for nulls is not consistent

2017-07-18 Thread Jonathan Haddad

This looks like expected behavior to me.  You aren't inserting a value for
b.  Since there's no value, there's also no writetime.

On Tue, Jul 18, 2017 at 12:15 PM Nitan Kainth  wrote:

> Hi,
>
> We see that null columns have writetime(column) populated for few columns
> and shows null for few other. Is it any bug or something else?
>
>
> CREATE KEYSPACE test WITH replication = {'class':
> 'NetworkTopologyStrategy', 'us-east': '2'}  AND durable_writes = true;
>
> CREATE TABLE test.t (
> a text PRIMARY KEY,
> b text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE’;
>
> insert into test.t (a ) values ('z’);
> insert into test.t (a ) values ('w’);
> insert into test.t (a ) values ('e’);
> insert into test.t (a ) values ('r’);
> insert into test.t (a ) values ('t’);
>
>  select a,b, writetime (b) from test.t ;
>
>  *a* | *b*| *writetime(b)*
> ---+--+--
>  *z* | *null* | *null*
>  *a* | *null* | *null*
>  *c* | *null* | *null*
>  *e* | *null* | *null*
>  *r* | *null* | *null*
>  *d* | *null* | *1500400745074499*
>  *w* | *null* | *1500400745074499*
>  *v* | *null* | *1500400745074499*
>  *t* | *null* | *1500400745074499*
>  *x* |*y* | *1500400626266371*
>

write time for nulls is not consistent

2017-07-18 Thread Nitan Kainth

Hi,

We see that null columns have writetime(column) populated for few columns and 
shows null for few other. Is it any bug or something else?


CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 
'us-east': '2'}  AND durable_writes = true;

CREATE TABLE test.t (
a text PRIMARY KEY,
b text
) WITH bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE’;

insert into test.t (a ) values ('z’);
insert into test.t (a ) values ('w’);
insert into test.t (a ) values ('e’);
insert into test.t (a ) values ('r’);
insert into test.t (a ) values ('t’);

 select a,b, writetime (b) from test.t ;

 a | b| writetime(b)
---+--+--
 z | null | null
 a | null | null
 c | null | null
 e | null | null
 r | null | null
 d | null | 1500400745074499
 w | null | 1500400745074499
 v | null | 1500400745074499
 t | null | 1500400745074499
 x |y | 1500400626266371

Re: Cassandra UNREACHABLE node

2017-07-18 Thread Ben Slater

I’m not sure it’s going to help you a lot as the issue is still open and
there is not a lot of info in the ticket but your issue looks a lot like
this JIRA to me:
https://issues.apache.org/jira/browse/CASSANDRA-13363

Cheers
Ben

On Tue, 18 Jul 2017 at 17:46 Shashikant Kulkarni (शशिकांत कुलकर्णी) <
shashikant.kulka...@gmail.com> wrote:

> Hello All,
>
> I have Cassandra v3.9, with 3 nodes in cluster. Replication factor 2
>
> 10.0.0.11,10.0.0.12,10.0.0.13
>
> 10.0.0.11,10.0.0.12 are seed nodes
>
> What could be the possible reasons for following error in
> /etc/cassandra/conf/debug.log
>
> The error is
>
> DEBUG [RMI TCP Connection(174)-127.0.0.1] 2017-07-12 04:47:49,002
> StorageProxy.java:2254 - Hosts not in agreement. Didn’t get a response from
> everybody: 10.0.0.13
>
> At the time of the error here are some statistics from all the servers
>
> [user1@ip-10-0-0-11 ~]$ nodetool status
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  Address Load   Tokens   Owns (effective)  Host ID
>   Rack
> UN  10.0.0.12  2.55 MiB   256  67.2%
> 83a68750-2238-4a6e-87be-03a3d7246824  rack1
> UN  10.0.0.11  1.78 GiB   256  70.6%
> 052fda9d-0474-4dfb-b2f8-0c5cbec15266  rack1
> UN  10.0.0.13  1.78 GiB   256  62.2%
> 86438dc9-77e0-43b2-a672-5b2e7cf216bf  rack1
>
> [user1@ip-10-0-0-11 ~]$ nodetool describecluster
> Cluster Information:
> Name: PiedmontCluster
> Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> 3c8d9e82-c688-3d16-a3e9-b84894168283: [10.0.0.12, 10.0.0.11]
>
> UNREACHABLE: [10.0.0.13]
>
>
> [user1@ip-10-0-0-13 ~]$ nodetool status
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  Address Load   Tokens   Owns (effective)  Host ID
>   Rack
> UN  10.0.0.12  2.55 MiB   256  67.2%
> 83a68750-2238-4a6e-87be-03a3d7246824  rack1
> UN  10.0.0.11  1.78 GiB   256  70.6%
> 052fda9d-0474-4dfb-b2f8-0c5cbec15266  rack1
> UN  10.0.0.13  1.78 GiB   256  62.2%
> 86438dc9-77e0-43b2-a672-5b2e7cf216bf  rack1
>
> [user1@ip-10-0-0-13 ~]$ nodetool describecluster
> Cluster Information:
> Name: PiedmontCluster
> Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> 3c8d9e82-c688-3d16-a3e9-b84894168283: [10.0.0.12, 10.0.0.13]
>
> UNREACHABLE: [10.0.0.11]
>
>
> [user1@ip-10-0-0-12 ~]$ nodetool status
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  Address Load   Tokens   Owns (effective)  Host ID
>   Rack
> UN  10.0.0.12  2.55 MiB   256  67.2%
> 83a68750-2238-4a6e-87be-03a3d7246824  rack1
> UN  10.0.0.11  1.78 GiB   256  70.6%
> 052fda9d-0474-4dfb-b2f8-0c5cbec15266  rack1
> UN  10.0.0.13  1.78 GiB   256  62.2%
> 86438dc9-77e0-43b2-a672-5b2e7cf216bf  rack1
>
> [user1@ip-10-0-0-12 ~]$ nodetool describecluster
> Cluster Information:
> Name: PiedmontCluster
> Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> 3c8d9e82-c688-3d16-a3e9-b84894168283: [10.0.0.12,
> 10.0.0.11, 10.0.0.13]
> The above mentioned error is in the /var/log/cassandra/debug.log on
> 10.0.0.11
>
> Error in /var/log/cassandra/debug.php on 10.0.0.13 is
>
> DEBUG [RMI TCP Connection(4)-127.0.0.1] 2017-07-13 02:31:23,846
> StorageProxy.java:2254 - Hosts not in agreement. Didn’t get a response from
> everybody: 10.0.0.11
> ERROR [MessagingService-Incoming-/10.0.0.11] 2017-07-13 02:35:04,982
> CassandraDaemon.java:226 - Exception in thread
> Thread[MessagingService-Incoming-/10.0.0.11,5,main]
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
>  
> org.apache.cassandra.db.filter.AbstractClusteringIndexFilter$FilterSerializer.deserialize(AbstractClusteringIndexFilter.java:74)
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Deserializer.deserialize(SinglePartitionReadCommand.java:1041)
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:696)
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:626)
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at
> org.apache.cassandra.io.ForwardingVersionedSerializer.deserialize(ForwardingVersionedSerializer.java:50)
> ~[apache-cassandra-3.9.0.jar:3.9.0]
> at

Cassandra UNREACHABLE node

2017-07-18 Thread शशिकांत कुलकर्णी

Hello All,

I have Cassandra v3.9, with 3 nodes in cluster. Replication factor 2

10.0.0.11,10.0.0.12,10.0.0.13

10.0.0.11,10.0.0.12 are seed nodes

What could be the possible reasons for following error in
/etc/cassandra/conf/debug.log

The error is

DEBUG [RMI TCP Connection(174)-127.0.0.1] 2017-07-12 04:47:49,002
StorageProxy.java:2254 - Hosts not in agreement. Didn’t get a response from
everybody: 10.0.0.13

At the time of the error here are some statistics from all the servers

[user1@ip-10-0-0-11 ~]$ nodetool status
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address Load   Tokens   Owns (effective)  Host ID
Rack
UN  10.0.0.12  2.55 MiB   256  67.2%
83a68750-2238-4a6e-87be-03a3d7246824  rack1
UN  10.0.0.11  1.78 GiB   256  70.6%
052fda9d-0474-4dfb-b2f8-0c5cbec15266  rack1
UN  10.0.0.13  1.78 GiB   256  62.2%
86438dc9-77e0-43b2-a672-5b2e7cf216bf  rack1

[user1@ip-10-0-0-11 ~]$ nodetool describecluster
Cluster Information:
Name: PiedmontCluster
Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema versions:
3c8d9e82-c688-3d16-a3e9-b84894168283: [10.0.0.12, 10.0.0.11]

UNREACHABLE: [10.0.0.13]


[user1@ip-10-0-0-13 ~]$ nodetool status
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address Load   Tokens   Owns (effective)  Host ID
Rack
UN  10.0.0.12  2.55 MiB   256  67.2%
83a68750-2238-4a6e-87be-03a3d7246824  rack1
UN  10.0.0.11  1.78 GiB   256  70.6%
052fda9d-0474-4dfb-b2f8-0c5cbec15266  rack1
UN  10.0.0.13  1.78 GiB   256  62.2%
86438dc9-77e0-43b2-a672-5b2e7cf216bf  rack1

[user1@ip-10-0-0-13 ~]$ nodetool describecluster
Cluster Information:
Name: PiedmontCluster
Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema versions:
3c8d9e82-c688-3d16-a3e9-b84894168283: [10.0.0.12, 10.0.0.13]

UNREACHABLE: [10.0.0.11]


[user1@ip-10-0-0-12 ~]$ nodetool status
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address Load   Tokens   Owns (effective)  Host ID
Rack
UN  10.0.0.12  2.55 MiB   256  67.2%
83a68750-2238-4a6e-87be-03a3d7246824  rack1
UN  10.0.0.11  1.78 GiB   256  70.6%
052fda9d-0474-4dfb-b2f8-0c5cbec15266  rack1
UN  10.0.0.13  1.78 GiB   256  62.2%
86438dc9-77e0-43b2-a672-5b2e7cf216bf  rack1

[user1@ip-10-0-0-12 ~]$ nodetool describecluster
Cluster Information:
Name: PiedmontCluster
Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema versions:
3c8d9e82-c688-3d16-a3e9-b84894168283: [10.0.0.12,
10.0.0.11, 10.0.0.13]
The above mentioned error is in the /var/log/cassandra/debug.log on
10.0.0.11

Error in /var/log/cassandra/debug.php on 10.0.0.13 is

DEBUG [RMI TCP Connection(4)-127.0.0.1] 2017-07-13 02:31:23,846
StorageProxy.java:2254 - Hosts not in agreement. Didn’t get a response from
everybody: 10.0.0.11
ERROR [MessagingService-Incoming-/10.0.0.11] 2017-07-13 02:35:04,982
CassandraDaemon.java:226 - Exception in thread
Thread[MessagingService-Incoming-/10.0.0.11,5,main]
java.lang.ArrayIndexOutOfBoundsException: 4
at
 
org.apache.cassandra.db.filter.AbstractClusteringIndexFilter$FilterSerializer.deserialize(AbstractClusteringIndexFilter.java:74)
~[apache-cassandra-3.9.0.jar:3.9.0]
at
org.apache.cassandra.db.SinglePartitionReadCommand$Deserializer.deserialize(SinglePartitionReadCommand.java:1041)
~[apache-cassandra-3.9.0.jar:3.9.0]
at
org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:696)
~[apache-cassandra-3.9.0.jar:3.9.0]
at
org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:626)
~[apache-cassandra-3.9.0.jar:3.9.0]
at
org.apache.cassandra.io.ForwardingVersionedSerializer.deserialize(ForwardingVersionedSerializer.java:50)
~[apache-cassandra-3.9.0.jar:3.9.0]
at org.apache.cassandra.net.MessageIn.read(MessageIn.java:114)
~[apache-cassandra-3.9.0.jar:3.9.0]
at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:190)
~[apache-cassandra-3.9.0.jar:3.9.0]
at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:178)
~[apache-cassandra-3.9.0.jar:3.9.0]
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:92)
~[apache-cassandra-3.9.0.jar:3.9.0]
No error in /var/log/cassandra/debug.php on 10.0.0.12

FW: unsubscribe

2017-07-18 Thread Bhupendra Baraiya



Thanks and regards,

Bhupendra Baraiya
Continuum Managed Services, LLC.
p: 902-933-0019
e: bhupendra.bara...@continuum.net
w: continuum.net
[http://cdn2.hubspot.net/hub/281750/file-393087232-png/img/logos/email-continuum-logo-151x26.png]

Re: write time for nulls is not consistent

Debugging requests blocking because of max_queued_native_transport_requests

Re: write time for nulls is not consistent

Re: Moving from DSE to Cassandra.

Re: Moving from DSE to Cassandra.

Re: Moving from DSE to Cassandra.

Re: write time for nulls is not consistent

Re: write time for nulls is not consistent

Moving from DSE to Cassandra.

Re: write time for nulls is not consistent

Re: write time for nulls is not consistent

write time for nulls is not consistent

Re: Cassandra UNREACHABLE node

Cassandra UNREACHABLE node

FW: unsubscribe

15 matches

Site Navigation

Mail list logo

Footer information