Historical data movement to other cluster

[Harika Vangapelli -T (hvangape - AKRAYA INC at Cisco)]

Is there a way to move past 3 months data from one cassandra cluster to other 
cluster?

Thanks,
Harika
[http://wwwin.cisco.com/c/dam/cec/organizations/gmcc/services-tools/signaturetool/images/logo/logo_gradient.png]



Harika Vangapelli
Engineer - IT
hvang...@cisco.com
Tel:

Cisco Systems, Inc.



United States
cisco.com


[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here for 
Company Registration Information.

Rebalance a cassandra cluster

[Akshit Jain]

Hi,
Can a cassandra cluster be unbalanced in terms of data?
If yes then how to rebalance a cassandra cluster.

RE: Cassandra downgrade of 2.1.15 to 2.1.12

[Mark Furlong]

Great information. 

Thank you
Mark
801-705-7115 office

-Original Message-
From: Michael Shuler [mailto:mshu...@pbandjelly.org] On Behalf Of Michael Shuler
Sent: Monday, September 11, 2017 5:54 PM
To: user@cassandra.apache.org
Subject: Re: Cassandra downgrade of 2.1.15 to 2.1.12

On 09/11/2017 06:29 PM, Mark Furlong wrote:
> I have a requirement to test a downgrade of 2.1.15 to 2.1.12. Can 
> someone please identify how to achieve this?

Downgrades have never been officially supported, but this is a relatively small 
step. Testing it out is definitely a good thing. Since protocols and on-disk 
sstable versions should be the same, I'd say work backwards through NEWS.txt 
and see what you think about how it affects your specific usage. I'd also be 
wary of the fixed bugs you will re-introduce on downgrade (CHANGES.txt).

https://github.com/apache/cassandra/blob/cassandra-2.1.15/NEWS.txt#L16-L44
https://github.com/apache/cassandra/blob/cassandra-2.1.15/CHANGES.txt#L1-L100

As for the actual software downgrade, it depends on install method.
`wget` the 2.1.12 tar or deb files and `tar -xzvf` or `dpkg -i` them.
Here's where you can find the old versions of artifacts:

tar:
http://archive.apache.org/dist/cassandra/2.1.12/
deb:
http://archive.apache.org/dist/cassandra/debian/pool/main/c/cassandra/

This definitely would not work on a major release downgrade like 2.2.x to 
2.1.x, since the sstable versions would be different, but in your
2.1.15 to 2.1.12 example, this might "just work".

--
Kind regards,
Michael

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

Re: Cassandra compatibility matrix

[Andy Tolbert]

Hi Dmitry,

We are currently working on updating our matrices for the drivers, but any
version of driver 3.0+ will work with cassandra 3.X.

Thanks,
Andy

On Tue, Sep 12, 2017 at 12:30 PM Dmitry Buzolin 
wrote:

> Thank you Jon.
>
> Is there way to find what Datastax driver is compatible with Cassandra
> 3.11?
>
> http://docs.datastax.com/en/developer/driver-matrix/doc/javaDrivers.html#java-drivers
> For some reason they don’t print latest version of Cassandra.
>
>
> On Sep 7, 2017, at 1:15 PM, Jon Haddad  wrote:
>
> There aren’t any drivers maintained by the Cassandra project.
> Compatibility is up to each driver.  Usually a section is included in the
> README.  For instance, in the DataStax Java Driver:
> https://github.com/datastax/java-driver#compatibility
>
> Jon
>
> On Sep 7, 2017, at 9:39 AM, Dmitry Buzolin  wrote:
>
> Hello list!
>
> Where can I find C* compatibility matrix for example server server version
> is compatible with what client drivers? Thank you!
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: user-h...@cassandra.apache.org
>
>
>
>

Re: Cassandra compatibility matrix

[Dmitry Buzolin]

Thank you Jon.

Is there way to find what Datastax driver is compatible with Cassandra 3.11?
http://docs.datastax.com/en/developer/driver-matrix/doc/javaDrivers.html#java-drivers
 

For some reason they don’t print latest version of Cassandra.


> On Sep 7, 2017, at 1:15 PM, Jon Haddad  wrote:
> 
> There aren’t any drivers maintained by the Cassandra project.  Compatibility 
> is up to each driver.  Usually a section is included in the README.  For 
> instance, in the DataStax Java Driver: 
> https://github.com/datastax/java-driver#compatibility 
> 
> 
> Jon
> 
>> On Sep 7, 2017, at 9:39 AM, Dmitry Buzolin > > wrote:
>> 
>> Hello list!
>> 
>> Where can I find C* compatibility matrix for example server server version 
>> is compatible with what client drivers? Thank you!
>> -
>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org 
>> 
>> For additional commands, e-mail: user-h...@cassandra.apache.org 
>> 
>> 
> 

Can't access Cassandra on remote node

[Andrea Giordano]

Hi,
I’m using cassandra on a remote node I can access just with console.
Since the node has a private ip, the cluster manager set a proxy to access 
private_ip:9042 in order to allow me to execute query against the db, so I have 
a public ip:port.

Unfortunately I’m not able to execute query and I’m investigate about why.

com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried 
for query failed (tried: /PUBLIC_IP:55092 
(com.datastax.driver.core.exceptions.TransportException: [/PUBLIC_IP] Cannot 
connect))

I’m sure the procedure to execute the query is fine because I tried with an 
identical cassandra db developed on the localhost. I suppose the problem is in 
the listener set on the remote node.
Using Kafka I had a similar problem but I solved it setting a variable 
advertised_listener in the configurations file, specifying the public_ip:port I 
using to access to the node. Anyway I didn’t find anything of similar in 
cassandra.yaml file.

Do you know how can I solve the issue?

Thank you,
Andrea

Re: Do not use Cassandra 3.11.0+ or Cassandra 3.0.12+

[Jeff Jirsa]

On the user side: 3.11.0 or 3.0.14 is probably what you want to use for new
clusters as long as you can avoid calling the getTombstoneRatio() mbean
with your metrics gathering tools.




On Tue, Sep 12, 2017 at 8:35 AM, Sandeep S  wrote:

> Hi,
>
> What is the current stable version?
>
> Sandeep.
>
> On 11 September 2017 at 23:06, CPC  wrote:
>
> > Hi,
> >
> > Is this bug fixed in dse 5.1.3? As I understand calling jmx
> > getTombStoneRatio
> > trigers that bug. We are using opscenter as well and do you have any idea
> > whether opscenter using/calling this method?
> >
> > Thanks
> >
> > On Aug 29, 2017 6:35 AM, "Jeff Jirsa"  wrote:
> >
> > > I shouldn't actually say I don't think it can happen on 3.0 - I haven't
> > > seen this happen on 3.0 without some other code change to enable it,
> but
> > > like I said, we're still investigating.
> > >
> > > --
> > > Jeff Jirsa
> > >
> > >
> > > > On Aug 28, 2017, at 8:30 PM, Jeff Jirsa  wrote:
> > > >
> > > > For what it's worth, I don't think this impacts 3.0 without adding
> some
> > > other code change (the reporter of the bug on 3.0 had added custom
> > metrics
> > > that exposed a concurrency issue).
> > > >
> > > > We're looking at it on 3.11. I think 13038 made it far more likely to
> > > occur, but I think it could have happened pre-13038 as well (would take
> > > some serious luck with your deletion time distribution though - the
> > > rounding in 13038 does make it more likely, but the race was already
> > there).
> > > >
> > > > --
> > > > Jeff Jirsa
> > > >
> > > >
> > > >> On Aug 28, 2017, at 8:24 PM, Jay Zhuang
>  > >
> > > wrote:
> > > >>
> > > >> We're using 3.0.12+ for a few months and haven't seen the issue like
> > > >> that. Do we know what could trigger the problem? Or is 3.0.x really
> > > >> impacted?
> > > >>
> > > >> Thanks,
> > > >> Jay
> > > >>
> > > >>> On 8/28/17 6:02 AM, Hannu Kröger wrote:
> > > >>> Hello,
> > > >>>
> > > >>> Current latest Cassandra version (3.11.0, possibly also 3.0.12+)
> has
> > a
> > > race
> > > >>> condition that causes Cassandra to create broken sstables (stats
> file
> > > in
> > > >>> sstables to be precise).
> > > >>>
> > > >>> Bug described here:
> > > >>> https://issues.apache.org/jira/browse/CASSANDRA-13752
> > > >>>
> > > >>> This change might be causing it (but not sure):
> > > >>> https://issues.apache.org/jira/browse/CASSANDRA-13038
> > > >>>
> > > >>> Other related issues:
> > > >>> https://issues.apache.org/jira/browse/CASSANDRA-13718
> > > >>> https://issues.apache.org/jira/browse/CASSANDRA-13756
> > > >>>
> > > >>> I would not recommend using 3.11.0 nor upgrading to 3.0.12 or
> higher
> > > before
> > > >>> this is fixed.
> > > >>>
> > > >>> Cheers,
> > > >>> Hannu
> > > >>>
> > > >>
> > > >> 
> -
> > > >> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> > > >> For additional commands, e-mail: user-h...@cassandra.apache.org
> > > >>
> > >
> > > -
> > > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: user-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: load distribution that I can't explain

[kaveh minooie]

Hi kurt, thanks for responding.

I understand that that query is very resource consuming. My question was 
why I only see its effect on the same node? considering that I have a 
replication factor of 2, I was hoping to see this load evenly 
distributed among those 2 nodes. That query runs hundreds of time on 
each run, but the loads seems to be always on the node2. That is what I 
am trying to figure out.



On 09/11/2017 06:25 PM, kurt greaves wrote:
Your first query will effectively have to perform table scans to satisfy 
what you are asking. If a query requires ALLOW FILTERING to be 
specified, it means that Cassandra can't really optimise that query in 
any way and it's going to have to query a lot of data (all of it...) to 
satisfy the result.
Because you've only specified one attribute of the partitioning key, 
Cassandra doesn't know where to look for that data, and will need to 
query all of it to find partitions matching that restriction.


If you want to select distinct you should probably do it in a 
distributed manner using token range scans, however this is generally 
not a good use case for Cassandra. If you really need to know your 
partitioning keys you should probably store them in a separate cache.


​


--
Kaveh Minooie

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

Re: Do not use Cassandra 3.11.0+ or Cassandra 3.0.12+

[Chris Lohfink]

Last Ive seen of it OpsCenter does not collect this metric. I don't think any 
monitoring tools do.

Chris

> On Sep 11, 2017, at 4:06 PM, CPC  wrote:
> 
> Hi,
> 
> Is this bug fixed in dse 5.1.3? As I understand calling jmx getTombStoneRatio
> trigers that bug. We are using opscenter as well and do you have any idea
> whether opscenter using/calling this method?
> 
> Thanks
> 
> On Aug 29, 2017 6:35 AM, "Jeff Jirsa"  wrote:
> 
>> I shouldn't actually say I don't think it can happen on 3.0 - I haven't
>> seen this happen on 3.0 without some other code change to enable it, but
>> like I said, we're still investigating.
>> 
>> --
>> Jeff Jirsa
>> 
>> 
>>> On Aug 28, 2017, at 8:30 PM, Jeff Jirsa  wrote:
>>> 
>>> For what it's worth, I don't think this impacts 3.0 without adding some
>> other code change (the reporter of the bug on 3.0 had added custom metrics
>> that exposed a concurrency issue).
>>> 
>>> We're looking at it on 3.11. I think 13038 made it far more likely to
>> occur, but I think it could have happened pre-13038 as well (would take
>> some serious luck with your deletion time distribution though - the
>> rounding in 13038 does make it more likely, but the race was already there).
>>> 
>>> --
>>> Jeff Jirsa
>>> 
>>> 
 On Aug 28, 2017, at 8:24 PM, Jay Zhuang 
>> wrote:
 
 We're using 3.0.12+ for a few months and haven't seen the issue like
 that. Do we know what could trigger the problem? Or is 3.0.x really
 impacted?
 
 Thanks,
 Jay
 
> On 8/28/17 6:02 AM, Hannu Kröger wrote:
> Hello,
> 
> Current latest Cassandra version (3.11.0, possibly also 3.0.12+) has a
>> race
> condition that causes Cassandra to create broken sstables (stats file
>> in
> sstables to be precise).
> 
> Bug described here:
> https://issues.apache.org/jira/browse/CASSANDRA-13752
> 
> This change might be causing it (but not sure):
> https://issues.apache.org/jira/browse/CASSANDRA-13038
> 
> Other related issues:
> https://issues.apache.org/jira/browse/CASSANDRA-13718
> https://issues.apache.org/jira/browse/CASSANDRA-13756
> 
> I would not recommend using 3.11.0 nor upgrading to 3.0.12 or higher
>> before
> this is fixed.
> 
> Cheers,
> Hannu
> 
 
 -
 To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: user-h...@cassandra.apache.org
 
>> 
>> -
>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: user-h...@cassandra.apache.org
>> 
>> 


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

RE: Can I have multiple datacenter with different versions of Cassandra

[Durity, Sean R]

No – the general answer is that you cannot stream between major versions of 
Cassandra. I would upgrade the existing ring, then add the new DC.


Sean Durity

From: Chuck Reynolds [mailto:creyno...@ancestry.com]
Sent: Thursday, May 18, 2017 11:20 AM
To: user@cassandra.apache.org
Subject: Can I have multiple datacenter with different versions of Cassandra

I have a need to create another datacenter and upgrade my existing Cassandra 
from 2.1.13 to Cassandra 3.0.9.

Can I do this as one step?  Create a new Cassandra ring that is version 3.0.9 
and replicate the data from an existing ring that is Cassandra 2.1.13?

After replicating to the new ring if possible them I would upgrade the old ring 
to Cassandra 3.0.9



The information in this Internet Email is confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this Email by 
anyone else is unauthorized. If you are not the intended recipient, any 
disclosure, copying, distribution or any action taken or omitted to be taken in 
reliance on it, is prohibited and may be unlawful. When addressed to our 
clients any opinions or advice contained in this Email are subject to the terms 
and conditions expressed in any applicable governing The Home Depot terms of 
business or client engagement letter. The Home Depot disclaims all 
responsibility and liability for the accuracy and content of this attachment 
and for any damages or losses arising from any inaccuracies, errors, viruses, 
e.g., worms, trojan horses, etc., or other items of a destructive nature, which 
may be contained in this attachment and shall not be liable for direct, 
indirect, consequential or special damages in connection with this e-mail 
message or its attachment.

RE: Reg:- DSE 5.1.0 Issue

[Durity, Sean R]

In an attempt to help close the loop for future readers… I don’t think an 
upgrade from DSE 4.8 straight to 5.1 is supported. I think you have to go 
through 5.0.x first.

And, yes, you should contact DataStax support for help, but I’m ok with 
DSE-related questions. They may be more Cassandra-related and helpful to the 
community.


Sean Durity

From: DuyHai Doan [mailto:doanduy...@gmail.com]
Sent: Tuesday, May 16, 2017 8:36 AM
To: Hannu Kröger 
Cc: @Nandan@ ; user@cassandra.apache.org
Subject: Re: Reg:- DSE 5.1.0 Issue

Nandan

Since you have asked many times questions about DSE on this OSS mailing list, I 
suggest you to contact directly Datastax if you're using their enterprise 
edition. Every Datastax customer has access to their support. If you're a 
sub-contractor for a final customer that is using DSE, ask your customer to get 
this support access. On this OSS mailing list we cannot answer questions 
related to a commercial product.



On Tue, May 16, 2017 at 1:07 PM, Hannu Kröger 
> wrote:
Hello,

DataStax is probably more than happy answer your particaly DataStax Enterprise 
related questions here (I don’t know if that is 100% right place but…):
https://support.datastax.com/hc/en-us

This mailing list is for open source Cassandra and DSE issues are mostly out of 
the scope here. HADOOP is one of DSE-only features.

Cheers,
Hannu

On 16 May 2017, at 14:01, @Nandan@ 
> wrote:

Hi ,
Sorry in Advance if I am posting here .

I stuck in some particular steps.

I was using DSE 4.8 on Single DC with 3 nodes. Today I upgraded my all 3 nodes 
to DSE 5.1
Issue is when I am trying to start SERVICE DSE RESTART i am getting error 
message as

Hadoop functionality has been removed from DSE.
Please try again without the HADOOP_ENABLED set in /etc/default/dse.

Even in /etc/default//dse file , HADOOP_ENABLED is set as 0 .

For testing ,Once I changed my HADOOP_ENABLED = 1 ,

I  am getting error as

Found multiple DSE core jar files in /usr/share/dse/lib 
/usr/share/dse/resources/dse/lib /usr/share/dse /usr/share/dse/common . Please 
make sure there is only one.

I searched so many article , but till now not able to find the solution.
Please help me to get out of this mess.

Thanks and Best Regards,
Nandan Priyadarshi.





The information in this Internet Email is confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this Email by 
anyone else is unauthorized. If you are not the intended recipient, any 
disclosure, copying, distribution or any action taken or omitted to be taken in 
reliance on it, is prohibited and may be unlawful. When addressed to our 
clients any opinions or advice contained in this Email are subject to the terms 
and conditions expressed in any applicable governing The Home Depot terms of 
business or client engagement letter. The Home Depot disclaims all 
responsibility and liability for the accuracy and content of this attachment 
and for any damages or losses arising from any inaccuracies, errors, viruses, 
e.g., worms, trojan horses, etc., or other items of a destructive nature, which 
may be contained in this attachment and shall not be liable for direct, 
indirect, consequential or special damages in connection with this e-mail 
message or its attachment.

RE: AWS Cassandra backup/Restore tools

[Durity, Sean R]

Datos IO has a backup/restore product for Cassandra that another team here has 
used successfully. It solves many of the problems inherent with sstable 
captures. Without something like it, restores are a nightmare with any volume 
of data. The downtime required and the loss of data since the snapshot are 
usually not worth it.


Sean Durity

From: Alexander Dejanovski [mailto:a...@thelastpickle.com]
Sent: Friday, May 12, 2017 12:14 PM
To: Manikandan Srinivasan ; Nitan Kainth 

Cc: Blake Eggleston ; cass savy ; 
user@cassandra.apache.org
Subject: Re: AWS Cassandra backup/Restore tools

Hi,

here are the main techniques that I know of to perform backups for Cassandra :

  *   Tablesnap 
(https://github.com/JeremyGrosser/tablesnap)
 : performs continuous backups on S3. Comes with tableslurp to restore backups 
(one table at a time only) and tablechop to delete outdated sstables from S3.
  *   incremental backup : activate it in the cassandra.yaml file and it will 
create snapshots for all newly flushed SSTables. It's up to you to move the 
snapshots off-node and delete them. I don't really like that technique since it 
creates a lot of small sstables that eventually contain a lot of outdated data. 
Upon restore you'll have to wait until compaction catches up on compacting all 
the history (which could take a while and use a lot of power). Your backups 
could also grow indefinitely with this technique since there's no compaction, 
so no purge. You'll have to build the restore script/procedure.
  *   scheduled snapshots : you perform full snapshots by yourself and move 
them off node. You'll have to build the restore script/procedure.
  *   EBS snapshots : probably the easiest way to perform backups if you are 
using M4/R4 instances on AWS.

Cheers,

On Thu, May 11, 2017 at 11:01 PM Manikandan Srinivasan 
> wrote:
Blake is correct. OpsCenter 6.0 and up doesn't work with OSS C*. @Nitan: We 
have made some substantial changes to the Opscenter 6.1 backup service, 
specifically when it comes to S3 backups. Having said this, I am not going to 
be sale-sy here. If folks need some help or need more clarity to know more 
about these improvements, please send me an email directly: 
msriniva...@datastax.com

Regards
Mani

On Thu, May 11, 2017 at 1:54 PM, Nitan Kainth 
> wrote:
Also , Opscenter backup/restore does not work for large databases

Sent from my iPhone

On May 11, 2017, at 3:41 PM, Blake Eggleston 
> wrote:
OpsCenter 6.0 and up don't work with Cassandra.


On May 11, 2017 at 12:31:08 PM, cass savy 
(casss...@gmail.com) wrote:
AWS Backup/Restore process/tools for C*/DSE C*:

Has anyone used Opscenter 6.1 backup tool to backup/restore data for larger 
datasets online ?

If yes, did you run into issues using that tool to backup/restore data in PROD 
that caused any performance or any other impact to the cluster?

If no, what are other tools that people have used or recommended for backup and 
restore of Cassandra keyspaces?

Please advice.





--
Regards,

Manikandan Srinivasan

Director, Product Management| +1.408.887.3686 | 
manikandan.sriniva...@datastax.com


[Image removed by sender. 
linkedin.png][Image
 removed by sender. 
facebook.png][Image
 removed by sender. 
twitter.png][Image
 removed by sender. 
g+.png][Image
 removed by 

Re: Cassandra 3.11 is compacting forever

[Ioannis Zafiropoulos]

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 restart - not rolling).


On Fri, Sep 8, 2017 at 4:24 PM, Romain Hardouin  wrote:

> Hi,
>
> It might be useful to enable compaction logging with log_all subproperties.
>
> Best,
>
> Romain
>
> Le vendredi 8 septembre 2017 à 00:15:19 UTC+2, kurt greaves <
> k...@instaclustr.com> a écrit :
>
>
> Might be worth turning on debug logging for that node and when the
> compaction kicks off and CPU skyrockets send through the logs.​
>