Thank you John for mentioning the liveness probe. This is something I
didn't think about.
Regards,
Pushpendra
On Fri, Aug 7, 2020 at 8:50 AM John Sanda wrote:
> It is worth mentioning that depending on how you configure your client
> application deployment, you should not have to worry about bo
It is worth mentioning that depending on how you configure your client
application deployment, you should not have to worry about bouncing the
driver. If you add a liveness probe for your client deployment that relies
on the driver being able to connect to the cluster, then kubernetes will
restart
Thanks Erick, that confirms my suspicion.
Cheers!
On Thu, Aug 6, 2020 at 8:55 PM Erick Ramirez
wrote:
> C* 3.0 added a new algorithm that optimised the token allocation
> (CASSANDRA-7032) [1] with allocate_tokens_for_keyspace in cassandra.yaml
> (originally allocate_tokens_keyspace but renamed)
Hi Pushpendra
You should use the headless service, e.g.,
// Note that this code snippet is using v3.x of the driver.
// Assume the service is deployed in namespace dev and is
// named cassandra-service. The FQDN of the service would then
// be cassandra-service.dev.svc.cluster.local. If your clie
C* 3.0 added a new algorithm that optimised the token allocation
(CASSANDRA-7032) [1] with allocate_tokens_for_keyspace in cassandra.yaml
(originally allocate_tokens_keyspace but renamed) [2].
Apart from that, there's no real change to how num_tokens work. What really
changed is the philosophy on
Hi,
I'm currently investigating an upgrade for our Cassandra cluster from 2.2
to 3.11, and as part of that would like to understand if there is any
change in how the cluster behaves w.r.t number of tokens. For historical
reasons, we have num_tokens set very high but want to make sure that this
is
We have created a statefulset & headless service to deploy Cassandra in
Kubernetes. Our client is also in the same Kubernetes cluster. We have
identified two ways by which we can find contact point for driver in client
application:
1. Use 'cassandra-headless-service-name' as contactPoints
2.
We have created a statefulset & headless service to deploy Cassandra in
Kubernetes. Our client is also in the same Kubernetes cluster. We have
identified two ways by which we can find contact point for driver in client
application:
1. Use 'cassandra-headless-service-name' as contactPoints
2.
