cqlsh fails to connect

I upgraded DSE 4.8.9 to 5.0.3, that is, from Cassandra 2.1.11 to 3.0.9 I used DSE 5.0.3 tarball installation. Cassandra cluster is up and running OK and I am able to connect through DBeaver. Tried a lot of things and cannot connect with cqlsh: Connection error: ('Unable to connect to any

Re: cqlsh fails to connect

that the latest python drivers (3.7.1 & 3.6.0) will not let my connect from python? Thanks On Fri, Oct 28, 2016 at 12:50 PM, Ioannis Zafiropoulos <john...@gmail.com> wrote: > Hi Rajesh, > > I just tried python 2.711 & 2.7.12 and I get the same error 'invalid > continuation byte'

Re: cqlsh fails to connect

7.12? > > Kind regards, > Rajesh Radhakrishnan > > ------ > *From:* Ioannis Zafiropoulos [john...@gmail.com] > *Sent:* 27 October 2016 22:16 > *To:* user@cassandra.apache.org > *Subject:* cqlsh fails to connect > > I upgraded DSE 4.8.9 to 5.0.

Removing a disk from JBOD configuration

Hi All, I have a 7 node cluster (Version 3.10) consisting of 5 disks each in JBOD. A few hours ago I had a disk failure on a node. I am wondering if I can: - stop Cassandra on that node - remove the disk, physically and from cassandra.yaml - start Cassandra on that node - run repair I mean, is

Re: Removing a disk from JBOD configuration

I just want to add that we use vnodes=16 if that helps with my questions.. On Mon, Jul 31, 2017 at 9:41 AM, Ioannis Zafiropoulos <john...@gmail.com> wrote: > Thank you Jeff for your answer, > > I use RF=3 and our client connect always with QUORUM. So I guess I will be > alri

Re: Removing a disk from JBOD configuration

a > whole node if any sstables are damaged or lost (if you do deletes, and if > it hurts you if deleted data comes back to life). > > > -- > Jeff Jirsa > > > On Jul 31, 2017, at 6:41 AM, Ioannis Zafiropoulos <john...@gmail.com> > wrote: > > Thank you Jeff for your a

Re: Removing a disk from JBOD configuration

> > Cassandra-6696 dramatically lowers this risk , if you're using a new > enough version of Cassandra > > > > -- > Jeff Jirsa > > > > On Jul 31, 2017, at 1:49 AM, Ioannis Zafiropoulos <john...@gmail.com> > wrote: > > > > Hi All, > >

Migrate from DSE (Datastax) to Apache Cassandra

Hi all, We have setup a new cluster DSE 5.1.2 (with Cassandra 3.11.0.1758) and we want to migrate it to Apache Cassandra 3.11.0 without loosing schema or data. Anybody, has done it before? Obviously we are going to test this, but it would be nice to hear if somebody else has gone through with

Re: Migrate from DSE (Datastax) to Apache Cassandra

ot recognised by COSS, e.g. > EverywhereStrategy for replication only known to DSE. > > You are better off standing up a new COSS 3.11 cluster and restore app > keyspaces to the new cluster. Cheers! > > On Wed, Aug 16, 2017 at 6:33 AM, Ioannis Zafiropoulos <john...@gmail.com>

Re: Migrate from DSE (Datastax) to Apache Cassandra

Ok found a solution for this problem. I deleted the system's keyspace directory and restarted COSS and it was rebuilt. rm -rf /var/lib/cassandra/data/system A bit drastic but I'll test it also on a multi-node cluster. On Thu, Aug 17, 2017 at 3:57 PM, Ioannis Zafiropoulos <john...@gmail.

Re: Cassandra 3.11 is compacting forever

A maybe long shot, have you deleted the cassandra-topology.properties file since you are using GossipingPropertyFileSnitch? I am sure I have seen a ticket about problems caused in some cases if that file stays around. I removed it from all the nodes and non-stop compaction stopped (after a proper

Re: Migrate from DSE (Datastax) to Apache Cassandra

Thanks Felipe and Erick, Yes, your comment helped a lot, I was able to resolve that by: ALTER KEYSPACE dse_system WITH replication = {'class': 'SimpleStrategy', 'replication_factor':'1'}; Another problem I had was with CentOS release 6.7 (Final) I was getting glibc 2.14 not found. Based on this

disk_failure_policy and blacklisted drives

Hello all, We have a small cluster (3.11.1) with JBOD and with disk_failure_policy = best_effort. - How do I check if a drive has become blacklisted by Cassandra due to failure? - Would you recommend to switch back to the default disk_failure_policy = stop which would be easier to check for

Upgrade 3.11.1 to 3.11.4

Hi all, During a decommission on a production cluster (9 nodes) we have some issues on the remaining nodes regarding compaction, and I have some questions about that: One remaining node who has stopped compacting, due to some bug in 3.11.1,

Re: Upgrade 3.11.1 to 3.11.4

commissioning the node? > > Why were you decommissioning the node? > > Were you upgrading from 3.11.1 to 3.11.4? > > > > > > *From:* Ioannis Zafiropoulos [mailto:john...@gmail.com] > *Sent:* Wednesday, February 27, 2019 7:33 AM > *To:* user@cassandra.apache.org > *S