estimated number of keys vs ttl

[Grzegorz Pietrusza]

Hi

I'm using tablestats to get estimated number of partitioning keys. In my
case all writes are done with TTL of a few days. Is the key count decreased
when TTL hits?

Regards
Grzegorz

Re: Using K8s to Manage Cassandra in Production

[Tom Petracca]

Using a statefulset should get you pretty far, though will likely be less 
effective than a coreos-style “operator”. Some random points:
For scale-up: a node shouldn’t report “ready” until it’s in the NORMAL state; 
this will prevent multiple nodes from bootstrapping at once.
For scale-down: as of now there isn’t a mechanism to know if a pod is getting 
decommissioned because you’ve permanently lowered replica count, or because 
it’s just getting bounced/re-scheduled, thus knowing whether or not to 
decommission is basically impossible. Relevant issue: kubernetes/kubernetes#1462
 

From: Pradeep Chhetri 
Reply-To: "user@cassandra.apache.org" 
Date: Friday, May 18, 2018 at 10:20 AM
To: "user@cassandra.apache.org" 
Subject: Re: Using K8s to Manage Cassandra in Production

 

Hello Hassaan, 

 

We use cassandra helm chart[0] for deploying cassandra over kubernetes in 
production. We have around 200GB cas data. It works really well. You can scale 
up nodes easily (I haven't tested scaling down).

 

I would say that if you are worried about running cassandra over k8s in 
production, maybe you should first try setting it for your 
staging/preproduction and gain confidence over time. 

 

I have tested situations where i have killed the host running cassandra 
container and have seen that container moves to a different node and joins 
cluster properly. So from my experience its pretty good. No issues till yet.

 

[0]: https://github.com/kubernetes/charts/tree/master/incubator/cassandra 
[github.com]

 

 

Regards,

Pradeep

 

On Fri, May 18, 2018 at 1:01 PM, Павел Сапежко  wrote:

Hi, Hassaan! For example we are using C* in k8s in production for our video 
surveillance system. Moreover, we are using Ceph RBD as our storage for 
cassandra. Today we have 8 C* nodes each manages 2Tb of data. 

 

On Fri, May 18, 2018 at 9:27 AM Hassaan Pasha  wrote:

Hi, 

 

I am trying to craft a deployment strategy for deploying and maintaining a C* 
cluster. I was wondering if there are actual production deployments of C* using 
K8s as the orchestration layer.

 

I have been given the impression that K8s managing a C* cluster can be a recipe 
for disaster, especially if you aren't well versed with the intricacies of a 
scale-up/down event. I know use cases where people are using Mesos or a custom 
tool built with terraform/chef etc to run their production clusters but have 
yet to find a real K8s use case.

 

Questions?

Is K8s a reasonable choice for managing a production C* cluster?

Are there documented use cases for this?

 

Any help would be greatly appreciated.

 

-- 

Regards, 

 

Hassaan Pasha

-- 

Regrads,
Pavel Sapezhko
 



smime.p7s
Description: S/MIME cryptographic signature

Re: estimated number of keys vs ttl

[Rahul Singh]

If the TTL actually reduces the key count , should. It’s possible to TTL a row 
from a partition but not the whole partition. 1 key = 1 partition != 1 row != 1 
cell

--
Rahul Singh
rahul.si...@anant.us

Anant Corporation

On May 23, 2018, 6:07 AM -0500, Grzegorz Pietrusza , 
wrote:
> Hi
>
> I'm using tablestats to get estimated number of partitioning keys. In my case 
> all writes are done with TTL of a few days. Is the key count decreased when 
> TTL hits?
>
> Regards
> Grzegorz

Re: Using K8s to Manage Cassandra in Production

[Ben Bromhead]

You can get a good way with StatefulSets, but as Tom mentioned there are
still some issues with this, particularly around scaling up and down.

We are working on an Operator for Apache Cassandra, you can find it here
https://github.com/instaclustr/cassandra-operator. This is a joint project
between Instaclustr, Pivotal and a few other folk.

Currently it's a work in progress, but we would love any or all early
feedback/PRs/issues etc. Our first GA release will target the following
capabilities:

   - Safe scaling up and down (including decommissioning)
   - Backup/restore workflow (snapshots only initially)
   - Built in prometheus integration and discovery

Other features like repair, better PV support, maybe even a nice dashboard
will be on the way.


On Wed, May 23, 2018 at 7:35 AM Tom Petracca  wrote:

> Using a statefulset should get you pretty far, though will likely be less
> effective than a coreos-style “operator”. Some random points:
>
>- For scale-up: a node shouldn’t report “ready” until it’s in the
>NORMAL state; this will prevent multiple nodes from bootstrapping at once.
>- For scale-down: as of now there isn’t a mechanism to know if a pod
>is getting decommissioned because you’ve permanently lowered replica count,
>or because it’s just getting bounced/re-scheduled, thus knowing whether or
>not to decommission is basically impossible. Relevant issue:
>kubernetes/kubernetes#1462
>
>
>
>
> *From: *Pradeep Chhetri 
> *Reply-To: *"user@cassandra.apache.org" 
> *Date: *Friday, May 18, 2018 at 10:20 AM
> *To: *"user@cassandra.apache.org" 
> *Subject: *Re: Using K8s to Manage Cassandra in Production
>
>
>
> Hello Hassaan,
>
>
>
> We use cassandra helm chart[0] for deploying cassandra over kubernetes in
> production. We have around 200GB cas data. It works really well. You can
> scale up nodes easily (I haven't tested scaling down).
>
>
>
> I would say that if you are worried about running cassandra over k8s in
> production, maybe you should first try setting it for your
> staging/preproduction and gain confidence over time.
>
>
>
> I have tested situations where i have killed the host running cassandra
> container and have seen that container moves to a different node and joins
> cluster properly. So from my experience its pretty good. No issues till yet.
>
>
>
> [0]: https://github.com/kubernetes/charts/tree/master/incubator/cassandra
> [github.com]
> 
>
>
>
>
>
> Regards,
>
> Pradeep
>
>
>
> On Fri, May 18, 2018 at 1:01 PM, Павел Сапежко 
> wrote:
>
> Hi, Hassaan! For example we are using C* in k8s in production for our
> video surveillance system. Moreover, we are using Ceph RBD as our storage
> for cassandra. Today we have 8 C* nodes each manages 2Tb of data.
>
>
>
> On Fri, May 18, 2018 at 9:27 AM Hassaan Pasha  wrote:
>
> Hi,
>
>
>
> I am trying to craft a deployment strategy for deploying and maintaining a
> C* cluster. I was wondering if there are actual production deployments of
> C* using K8s as the orchestration layer.
>
>
>
> I have been given the impression that K8s managing a C* cluster can be a
> recipe for disaster, especially if you aren't well versed with the
> intricacies of a scale-up/down event. I know use cases where people are
> using Mesos or a custom tool built with terraform/chef etc to run their
> production clusters but have yet to find a real K8s use case.
>
>
>
> *Questions?*
>
> Is K8s a reasonable choice for managing a production C* cluster?
>
> Are there documented use cases for this?
>
>
>
> Any help would be greatly appreciated.
>
>
>
> --
>
> Regards,
>
>
>
> *Hassaan Pasha*
>
> --
>
> Regrads,
>
> Pavel Sapezhko
>
>
>
-- 
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer

Re: Using K8s to Manage Cassandra in Production

[vincent gromakowski]

Why did you choose java for the operator implementation when everybody
seems to use the go client (probably for greater functionalities) ?

2018-05-23 15:39 GMT+02:00 Ben Bromhead :

> You can get a good way with StatefulSets, but as Tom mentioned there are
> still some issues with this, particularly around scaling up and down.
>
> We are working on an Operator for Apache Cassandra, you can find it here
> https://github.com/instaclustr/cassandra-operator. This is a joint
> project between Instaclustr, Pivotal and a few other folk.
>
> Currently it's a work in progress, but we would love any or all early
> feedback/PRs/issues etc. Our first GA release will target the following
> capabilities:
>
>- Safe scaling up and down (including decommissioning)
>- Backup/restore workflow (snapshots only initially)
>- Built in prometheus integration and discovery
>
> Other features like repair, better PV support, maybe even a nice dashboard
> will be on the way.
>
>
> On Wed, May 23, 2018 at 7:35 AM Tom Petracca 
> wrote:
>
>> Using a statefulset should get you pretty far, though will likely be less
>> effective than a coreos-style “operator”. Some random points:
>>
>>- For scale-up: a node shouldn’t report “ready” until it’s in the
>>NORMAL state; this will prevent multiple nodes from bootstrapping at once.
>>- For scale-down: as of now there isn’t a mechanism to know if a pod
>>is getting decommissioned because you’ve permanently lowered replica 
>> count,
>>or because it’s just getting bounced/re-scheduled, thus knowing whether or
>>not to decommission is basically impossible. Relevant issue:
>>kubernetes/kubernetes#1462
>>
>>
>>
>>
>> *From: *Pradeep Chhetri 
>> *Reply-To: *"user@cassandra.apache.org" 
>> *Date: *Friday, May 18, 2018 at 10:20 AM
>> *To: *"user@cassandra.apache.org" 
>> *Subject: *Re: Using K8s to Manage Cassandra in Production
>>
>>
>>
>> Hello Hassaan,
>>
>>
>>
>> We use cassandra helm chart[0] for deploying cassandra over kubernetes in
>> production. We have around 200GB cas data. It works really well. You can
>> scale up nodes easily (I haven't tested scaling down).
>>
>>
>>
>> I would say that if you are worried about running cassandra over k8s in
>> production, maybe you should first try setting it for your
>> staging/preproduction and gain confidence over time.
>>
>>
>>
>> I have tested situations where i have killed the host running cassandra
>> container and have seen that container moves to a different node and joins
>> cluster properly. So from my experience its pretty good. No issues till yet.
>>
>>
>>
>> [0]: https://github.com/kubernetes/charts/tree/master/incubator/cassandra
>> [github.com]
>> 
>>
>>
>>
>>
>>
>> Regards,
>>
>> Pradeep
>>
>>
>>
>> On Fri, May 18, 2018 at 1:01 PM, Павел Сапежко 
>> wrote:
>>
>> Hi, Hassaan! For example we are using C* in k8s in production for our
>> video surveillance system. Moreover, we are using Ceph RBD as our storage
>> for cassandra. Today we have 8 C* nodes each manages 2Tb of data.
>>
>>
>>
>> On Fri, May 18, 2018 at 9:27 AM Hassaan Pasha  wrote:
>>
>> Hi,
>>
>>
>>
>> I am trying to craft a deployment strategy for deploying and maintaining
>> a C* cluster. I was wondering if there are actual production deployments of
>> C* using K8s as the orchestration layer.
>>
>>
>>
>> I have been given the impression that K8s managing a C* cluster can be a
>> recipe for disaster, especially if you aren't well versed with the
>> intricacies of a scale-up/down event. I know use cases where people are
>> using Mesos or a custom tool built with terraform/chef etc to run their
>> production clusters but have yet to find a real K8s use case.
>>
>>
>>
>> *Questions?*
>>
>> Is K8s a reasonable choice for managing a production C* cluster?
>>
>> Are there documented use cases for this?
>>
>>
>>
>> Any help would be greatly appreciated.
>>
>>
>>
>> --
>>
>> Regards,
>>
>>
>>
>> *Hassaan Pasha*
>>
>> --
>>
>> Regrads,
>>
>> Pavel Sapezhko
>>
>>
>>
> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
>

repair in C* 3.11.2 and anticompactions

[Jean Carlo]

Hello

I just want to understand why, if I run a repair non incremental like this

nodetool -h 127.0.0.1 -p 7100 repair -full -pr keyspace1 standard1

Cassandra does anticompaction as the logs show

INFO  [CompactionExecutor:20] 2018-05-23 16:36:27,598
CompactionManager.java:1545 - Anticompacting
[BigTableReader(path='/home/jriveraura/.ccm/test/node1/data0/keyspace1/standard1-36a6ec405e9411e8b1d1b38a73559799/mc-2-big-Data.db')]

As far as I understood the anticompactions are used to make the repair
incremantals possible, so I was expecting no having anticompactions making
repairs with the options  -pr -full

Anyone knows why does cassandra make those anticompactions ?

Thanks

Jean Carlo

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

Re: Using K8s to Manage Cassandra in Production

[Ben Bromhead]

The official Kubernetes Java driver is actually pretty feature complete, if
not exactly idiomatic Java...  it's only missing full examples to get it to
GOLD compatibility levels iirc.

A few reasons we went down the Java path:

   - Cassandra community engagement was the primary concern. If you are a
   developer in the Cassandra community you have a base level of Java
   knowledge, so it means if you want to work on the Kubernetes operator you
   only have to learn 1 thing, Kubernetes. If the operator was in Go, you
   would then have two things to learn, Go and Kubernetes :)
   - We actually wrote an initial PoC in Go (based off the etcd operator,
   you can find it here
   https://github.com/benbromhead/cassandra-operator-old ), but because it
   was in Go we ended up making architectural decisions simply because
   Go doesn't do JMX, so it felt like we were just fighting different
   ecosystems just to be part of the cool group.

Some other less important points weighed the decision in Java's favour:

   - The folk at Instaclustr all know Java, and are productive in it from
   day 1. Go is fun and relatively simple, but not our forte.
   -  Mature package management, Generics/inability to write DRY
   code, a million if err statements  (:
   - Some other awesome operators/controllers are written in JVM based
   languages. The sparkKubernetes resource manager (which is a k8s controller)
   is written in Scala.


On Wed, May 23, 2018 at 10:04 AM vincent gromakowski <
vincent.gromakow...@gmail.com> wrote:

> Why did you choose java for the operator implementation when everybody
> seems to use the go client (probably for greater functionalities) ?
>
> 2018-05-23 15:39 GMT+02:00 Ben Bromhead :
>
>> You can get a good way with StatefulSets, but as Tom mentioned there are
>> still some issues with this, particularly around scaling up and down.
>>
>> We are working on an Operator for Apache Cassandra, you can find it here
>> https://github.com/instaclustr/cassandra-operator. This is a joint
>> project between Instaclustr, Pivotal and a few other folk.
>>
>> Currently it's a work in progress, but we would love any or all early
>> feedback/PRs/issues etc. Our first GA release will target the following
>> capabilities:
>>
>>- Safe scaling up and down (including decommissioning)
>>- Backup/restore workflow (snapshots only initially)
>>- Built in prometheus integration and discovery
>>
>> Other features like repair, better PV support, maybe even a nice
>> dashboard will be on the way.
>>
>>
>> On Wed, May 23, 2018 at 7:35 AM Tom Petracca 
>> wrote:
>>
>>> Using a statefulset should get you pretty far, though will likely be
>>> less effective than a coreos-style “operator”. Some random points:
>>>
>>>- For scale-up: a node shouldn’t report “ready” until it’s in the
>>>NORMAL state; this will prevent multiple nodes from bootstrapping at 
>>> once.
>>>- For scale-down: as of now there isn’t a mechanism to know if a pod
>>>is getting decommissioned because you’ve permanently lowered replica 
>>> count,
>>>or because it’s just getting bounced/re-scheduled, thus knowing whether 
>>> or
>>>not to decommission is basically impossible. Relevant issue:
>>>kubernetes/kubernetes#1462
>>>
>>>
>>>
>>>
>>> *From: *Pradeep Chhetri 
>>> *Reply-To: *"user@cassandra.apache.org" 
>>> *Date: *Friday, May 18, 2018 at 10:20 AM
>>> *To: *"user@cassandra.apache.org" 
>>> *Subject: *Re: Using K8s to Manage Cassandra in Production
>>>
>>>
>>>
>>> Hello Hassaan,
>>>
>>>
>>>
>>> We use cassandra helm chart[0] for deploying cassandra over kubernetes
>>> in production. We have around 200GB cas data. It works really well. You can
>>> scale up nodes easily (I haven't tested scaling down).
>>>
>>>
>>>
>>> I would say that if you are worried about running cassandra over k8s in
>>> production, maybe you should first try setting it for your
>>> staging/preproduction and gain confidence over time.
>>>
>>>
>>>
>>> I have tested situations where i have killed the host running cassandra
>>> container and have seen that container moves to a different node and joins
>>> cluster properly. So from my experience its pretty good. No issues till yet.
>>>
>>>
>>>
>>> [0]: https://github.com/kubernetes/charts/tree/master/incubator/cassandra
>>> [github.com]
>>> 
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>> Pradeep
>>>
>>>
>>>
>>> On Fri, May 18, 2018 at 1:01 PM, Павел Сапежко 
>>> wrote:
>>>
>>> Hi, Hassaan! For example we are using C* in k8s in production for our
>>> video surveillance system. Moreover, we are using Ceph RBD as our storage
>>> for cassandra. Today w

Re: Using K8s to Manage Cassandra in Production

[vincent gromakowski]

Thanks ! Do you have some pointers on the available features ? I am more
afraid of the lack of custom controller integration, for instance the code
generator...

2018-05-23 17:17 GMT+02:00 Ben Bromhead :

> The official Kubernetes Java driver is actually pretty feature complete,
> if not exactly idiomatic Java...  it's only missing full examples to get it
> to GOLD compatibility levels iirc.
>
> A few reasons we went down the Java path:
>
>- Cassandra community engagement was the primary concern. If you are a
>developer in the Cassandra community you have a base level of Java
>knowledge, so it means if you want to work on the Kubernetes operator you
>only have to learn 1 thing, Kubernetes. If the operator was in Go, you
>would then have two things to learn, Go and Kubernetes :)
>- We actually wrote an initial PoC in Go (based off the etcd operator,
>you can find it here https://github.com/benbromhead/cassandra-
>operator-old ), but because it was in Go we ended up making
>architectural decisions simply because Go doesn't do JMX, so it felt like
>we were just fighting different ecosystems just to be part of the cool
>group.
>
> Some other less important points weighed the decision in Java's favour:
>
>- The folk at Instaclustr all know Java, and are productive in it from
>day 1. Go is fun and relatively simple, but not our forte.
>-  Mature package management, Generics/inability to write DRY
>code, a million if err statements  (:
>- Some other awesome operators/controllers are written in JVM based
>languages. The sparkKubernetes resource manager (which is a k8s controller)
>is written in Scala.
>
>
> On Wed, May 23, 2018 at 10:04 AM vincent gromakowski <
> vincent.gromakow...@gmail.com> wrote:
>
>> Why did you choose java for the operator implementation when everybody
>> seems to use the go client (probably for greater functionalities) ?
>>
>> 2018-05-23 15:39 GMT+02:00 Ben Bromhead :
>>
>>> You can get a good way with StatefulSets, but as Tom mentioned there are
>>> still some issues with this, particularly around scaling up and down.
>>>
>>> We are working on an Operator for Apache Cassandra, you can find it here
>>> https://github.com/instaclustr/cassandra-operator. This is a joint
>>> project between Instaclustr, Pivotal and a few other folk.
>>>
>>> Currently it's a work in progress, but we would love any or all early
>>> feedback/PRs/issues etc. Our first GA release will target the following
>>> capabilities:
>>>
>>>- Safe scaling up and down (including decommissioning)
>>>- Backup/restore workflow (snapshots only initially)
>>>- Built in prometheus integration and discovery
>>>
>>> Other features like repair, better PV support, maybe even a nice
>>> dashboard will be on the way.
>>>
>>>
>>> On Wed, May 23, 2018 at 7:35 AM Tom Petracca 
>>> wrote:
>>>
 Using a statefulset should get you pretty far, though will likely be
 less effective than a coreos-style “operator”. Some random points:

- For scale-up: a node shouldn’t report “ready” until it’s in the
NORMAL state; this will prevent multiple nodes from bootstrapping at 
 once.
- For scale-down: as of now there isn’t a mechanism to know if a
pod is getting decommissioned because you’ve permanently lowered replica
count, or because it’s just getting bounced/re-scheduled, thus knowing
whether or not to decommission is basically impossible. Relevant issue:
kubernetes/kubernetes#1462




 *From: *Pradeep Chhetri 
 *Reply-To: *"user@cassandra.apache.org" 
 *Date: *Friday, May 18, 2018 at 10:20 AM
 *To: *"user@cassandra.apache.org" 
 *Subject: *Re: Using K8s to Manage Cassandra in Production



 Hello Hassaan,



 We use cassandra helm chart[0] for deploying cassandra over kubernetes
 in production. We have around 200GB cas data. It works really well. You can
 scale up nodes easily (I haven't tested scaling down).



 I would say that if you are worried about running cassandra over k8s in
 production, maybe you should first try setting it for your
 staging/preproduction and gain confidence over time.



 I have tested situations where i have killed the host running cassandra
 container and have seen that container moves to a different node and joins
 cluster properly. So from my experience its pretty good. No issues till 
 yet.



 [0]: https://github.com/kubernetes/charts/tree/master/incubator/cassandra
 [github.com]
 

Re: Using K8s to Manage Cassandra in Production

[Ben Bromhead]

Here is the expectations around compatibility levels
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/csi-new-client-library-procedure.md#client-capabilities
Though
references to gold, silver, bronze etc seem to have largely gone away...
not sure what's going on there?

For a full reference just browser through the repo,
https://github.com/kubernetes-client/java/blob/master/kubernetes/README.md is
a good place to start as is
https://github.com/kubernetes-client/java/tree/master/examples

The Java driver doesn't have as much of the nice things in
https://github.com/kubernetes/client-go/tree/master/tools but it does have
some good helper classes in the util package so I guess we spent a little
more time wiring things together?

Code Generation is done via the jsonschema2pojo maven plugin and we also
just have the raw CRD definition in a resource directory.

On Wed, May 23, 2018 at 11:23 AM vincent gromakowski <
vincent.gromakow...@gmail.com> wrote:

> Thanks ! Do you have some pointers on the available features ? I am more
> afraid of the lack of custom controller integration, for instance the code
> generator...
>
> 2018-05-23 17:17 GMT+02:00 Ben Bromhead :
>
>> The official Kubernetes Java driver is actually pretty feature complete,
>> if not exactly idiomatic Java...  it's only missing full examples to get it
>> to GOLD compatibility levels iirc.
>>
>> A few reasons we went down the Java path:
>>
>>- Cassandra community engagement was the primary concern. If you are
>>a developer in the Cassandra community you have a base level of Java
>>knowledge, so it means if you want to work on the Kubernetes operator you
>>only have to learn 1 thing, Kubernetes. If the operator was in Go,
>>you would then have two things to learn, Go and Kubernetes :)
>>- We actually wrote an initial PoC in Go (based off the etcd
>>operator, you can find it here
>>https://github.com/benbromhead/cassandra-operator-old ), but because
>>it was in Go we ended up making architectural decisions simply because
>>Go doesn't do JMX, so it felt like we were just fighting different
>>ecosystems just to be part of the cool group.
>>
>> Some other less important points weighed the decision in Java's favour:
>>
>>- The folk at Instaclustr all know Java, and are productive in it
>>from day 1. Go is fun and relatively simple, but not our forte.
>>-  Mature package management, Generics/inability to write DRY
>>code, a million if err statements  (:
>>- Some other awesome operators/controllers are written in JVM based
>>languages. The sparkKubernetes resource manager (which is a k8s 
>> controller)
>>is written in Scala.
>>
>>
>> On Wed, May 23, 2018 at 10:04 AM vincent gromakowski <
>> vincent.gromakow...@gmail.com> wrote:
>>
>>> Why did you choose java for the operator implementation when everybody
>>> seems to use the go client (probably for greater functionalities) ?
>>>
>>> 2018-05-23 15:39 GMT+02:00 Ben Bromhead :
>>>
 You can get a good way with StatefulSets, but as Tom mentioned there
 are still some issues with this, particularly around scaling up and down.

 We are working on an Operator for Apache Cassandra, you can find it
 here https://github.com/instaclustr/cassandra-operator. This is a
 joint project between Instaclustr, Pivotal and a few other folk.

 Currently it's a work in progress, but we would love any or all early
 feedback/PRs/issues etc. Our first GA release will target the following
 capabilities:

- Safe scaling up and down (including decommissioning)
- Backup/restore workflow (snapshots only initially)
- Built in prometheus integration and discovery

 Other features like repair, better PV support, maybe even a nice
 dashboard will be on the way.


 On Wed, May 23, 2018 at 7:35 AM Tom Petracca 
 wrote:

> Using a statefulset should get you pretty far, though will likely be
> less effective than a coreos-style “operator”. Some random points:
>
>- For scale-up: a node shouldn’t report “ready” until it’s in the
>NORMAL state; this will prevent multiple nodes from bootstrapping at 
> once.
>- For scale-down: as of now there isn’t a mechanism to know if a
>pod is getting decommissioned because you’ve permanently lowered 
> replica
>count, or because it’s just getting bounced/re-scheduled, thus knowing
>whether or not to decommission is basically impossible. Relevant issue:
>kubernetes/kubernetes#1462
>
>
>
>
> *From: *Pradeep Chhetri 
> *Reply-To: *"user@cassandra.apache.org" 
> *Date: *Friday, May 18, 2018 at 10:20 AM
> *To: *"user@cassandra.apache.org" 
> *Subject: *Re: Using K8s to Manage Cassandra in Production
>
>
>
> Hello Hass

Anyone try out C* with latest Oracle JDK update?

[Sam Sriramadhesikan]

Hi,

Any experiences any one have running C* 3.x with the Oracle JDK update 1.8 u172 
/ u171 that came out mid-April?

Thanks,

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

Re: estimated number of keys vs ttl

[Eric Stevens]

I believe that key estimates won't immediately respond to expired TTL, Not
until after compaction has completely dropped the records (which will
include subtle logic related to gc_grace and partitions with data in
multiple SSTables).

On Wed, May 23, 2018 at 6:18 AM Rahul Singh 
wrote:

> If the TTL actually reduces the key count , should. It’s possible to TTL a
> row from a partition but not the whole partition. 1 key = 1 partition != 1
> row != 1 cell
>
> --
> Rahul Singh
> rahul.si...@anant.us
>
> Anant Corporation
>
> On May 23, 2018, 6:07 AM -0500, Grzegorz Pietrusza ,
> wrote:
>
> Hi
>
> I'm using tablestats to get estimated number of partitioning keys. In my
> case all writes are done with TTL of a few days. Is the key count decreased
> when TTL hits?
>
> Regards
> Grzegorz
>
>

Re: repair in C* 3.11.2 and anticompactions

[Lerh Chuan Low]

Hey Jean,

I think it still does anticompaction by default regardless, it will not do
so only if you do subrange repair. TLP wrote a pretty good article on that:
http://thelastpickle.com/blog/2017/12/14/should-you-use-incremental-repair.html

On 24 May 2018 at 00:42, Jean Carlo  wrote:

> Hello
>
> I just want to understand why, if I run a repair non incremental like this
>
> nodetool -h 127.0.0.1 -p 7100 repair -full -pr keyspace1 standard1
>
> Cassandra does anticompaction as the logs show
>
> INFO  [CompactionExecutor:20] 2018-05-23 16:36:27,598
> CompactionManager.java:1545 - Anticompacting [BigTableReader(path='/home/
> jriveraura/.ccm/test/node1/data0/keyspace1/standard1-
> 36a6ec405e9411e8b1d1b38a73559799/mc-2-big-Data.db')]
>
> As far as I understood the anticompactions are used to make the repair
> incremantals possible, so I was expecting no having anticompactions making
> repairs with the options  -pr -full
>
> Anyone knows why does cassandra make those anticompactions ?
>
> Thanks
>
> Jean Carlo
>
> "The best way to predict the future is to invent it" Alan Kay
>

Snapshot SSTable modified??

[Max C.]

Hi Everyone,

We’ve noticed a few times in the last few weeks that when we’re doing backups, 
tar has complained with messages like this:

tar: 
/var/lib/cassandra/data/mars/test_instances_by_test_id-6a9440a04cc111e8878675f1041d7e1c/snapshots/backup_20180523_024502/mb-63-big-Data.db:
 file changed as we read it

Any idea what might be causing this?

We’re running Cassandra 3.0.8 on RHEL 7.  Here’s rough pseudocode of our backup 
process:


SNAPSHOT_NAME=backup_YYYMMDD_HHMMSS
nodetool snapshot -t $SNAPSHOT_NAME

for each keyspace
- dump schema to “schema.cql"
- tar -czf /file_server/backup_$HOSTNAME_$KEYSPACE_MMDD_HHMMSS.tgz 
schema.cql /var/lib/cassandra/data/$KEYSPACE/*/snapshots/$SNAPSHOT_NAME

nodetool clearsnapshot -t $SNAPSHOT_NAME

Thanks.

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

Re: Snapshot SSTable modified??

[Jeff Jirsa]

In versions before 3.0, sstables were written with a -tmp filename and
copied/moved to the final filename when complete. This changes in 3.0 - we
write into the file with the final name, and have a journal/log to let uss
know when it's done/final/live.

Therefore, you can no longer just watch for a -Data.db file to be created
and uploaded - you have to watch the log to make sure it's not being
written.


On Wed, May 23, 2018 at 2:18 PM, Max C.  wrote:

> Hi Everyone,
>
> We’ve noticed a few times in the last few weeks that when we’re doing
> backups, tar has complained with messages like this:
>
> tar: /var/lib/cassandra/data/mars/test_instances_by_test_id-
> 6a9440a04cc111e8878675f1041d7e1c/snapshots/backup_20180523_024502/mb-63-big-Data.db:
> file changed as we read it
>
> Any idea what might be causing this?
>
> We’re running Cassandra 3.0.8 on RHEL 7.  Here’s rough pseudocode of our
> backup process:
>
> 
> SNAPSHOT_NAME=backup_YYYMMDD_HHMMSS
> nodetool snapshot -t $SNAPSHOT_NAME
>
> for each keyspace
> - dump schema to “schema.cql"
> - tar -czf /file_server/backup_$HOSTNAME_$KEYSPACE_MMDD_HHMMSS.tgz
> schema.cql /var/lib/cassandra/data/$KEYSPACE/*/snapshots/$SNAPSHOT_NAME
>
> nodetool clearsnapshot -t $SNAPSHOT_NAME
>
> Thanks.
>
> - Max
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: user-h...@cassandra.apache.org
>
>

RE: Anyone try out C* with latest Oracle JDK update?

[Steinmaurer, Thomas]

Hi Sam,

in our pre-production stages, we are running Cassandra 3.0 and 3.11 with 8u172 
(previously u102 then u162) without any visible troubles/regressions.

In case of Cassandra 3.11, you need 3.11.2 due to: 
https://issues.apache.org/jira/browse/CASSANDRA-14173. Cassandra 3.0 is not 
affected by this issue.

Hope this helps.

Thomas

-Original Message-
From: Sam Sriramadhesikan [mailto:sam.sriramadhesi...@oracle.com]
Sent: Mittwoch, 23. Mai 2018 19:33
To: user@cassandra.apache.org
Subject: Anyone try out C* with latest Oracle JDK update?

Hi,

Any experiences any one have running C* 3.x with the Oracle JDK update 1.8 u172 
/ u171 that came out mid-April?

Thanks,

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

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313