I think in the context of what I think initially motivated this hot
reloading capability, a big win it provides is avoiding having to
bounce your cluster as your certificates near expiry. If not watched
closely you can get yourself into a state where every node in the
cluster's cert expired, which
l test the scenario you mentioned.
>
> Regards
> Avinash
>
> On Mon, Apr 15, 2024 at 11:28 AM, Tolbert, Andy
> wrote:
>>
>> Hi Avinash,
>>
>> As far as I understand it, if the underlying keystore/trustore(s)
>> Cassandra is configured for is upda
Hi Avinash,
As far as I understand it, if the underlying keystore/trustore(s)
Cassandra is configured for is updated, this *will not* provoke
Cassandra to interrupt existing connections, it's just that the new
stores will be used for future TLS initialization.
Via:
https://cassandra.apache.org/d
n repair
>
> Will that work? Right now, it's showing all nodes as up.
>
> -Joe
>
> On 1/16/2023 11:55 AM, Tolbert, Andy wrote:
> > Hi Joe,
> >
> > I'd recommend just doing a replacement, bringing up a new node with
> > -Dcassandra.replace_addr
Hi Joe,
I'd recommend just doing a replacement, bringing up a new node with
-Dcassandra.replace_address_first_boot=ip.you.are.replacing as
described here:
https://cassandra.apache.org/doc/4.1/cassandra/operating/topo_changes.html#replacing-a-dead-node
Before you do that, you will want to make sur
I'd bet the JIRA that Paul is pointing to is likely what's happening
here. I'd look for read repair errors in your system logs or in your
metrics (if you have easy access to them).
There are operations that can happen during the course of a query
being executed that may happen at different CLs,
Hi Shaurya,
On Tue, Nov 9, 2021 at 11:57 PM Shaurya Gupta
wrote:
> Hi,
>
> We want to enable node-to-node SSL on a live cluster. Could it be done
> without any down time ?
>
Yup, this is definitely doable for both internode and client connections.
You will have to bounce your cassandra nodes, b
