Then that's the cause for the node negotiating down to an older protocol
version by design for dealing with mixed-version clusters as Sam described
in his response. As Bowen stated, you must have had an old node back from
when it was still a C* 2.2 cluster that you probably tried to
We don’t see this node as part of our cluster. Not listed in nodetool status as
well.
Regards,
Srinivas P
From: Erick Ramirez
Date: Friday, 30 July 2021 at 9:55 AM
To: user@cassandra.apache.org
Subject: Re: Issue with native protocol
Is 10.39.36.152 part of the cluster or is it dead?
Is 10.39.36.152 part of the cluster or is it dead?
>
Hi,
I am getting following output on problematic node where as no output on working
node.
cassandra@cqlsh> select peer, host_id, release_version from system.peers where
release_version < '3.0.0' allow filtering;
peer | host_id | release_version
Thank you Scott!
We installed over on top of 3.11 and it's working fine. Easy non-upgrade path
:)
Thanks again,
Adam
On 2021/07/28 22:49:11, Scott Andreas wrote:
> If you're running Cassandra 3.x, the only data file requirement is that all
> SSTables present on your cluster are 3.x-era
Hi Erick,
Limiting mmap to index only seems to have resolved the issue. The max ram
usage remained at 60% this time. Could you please point me to the
limitations for setting this param? - For starters, I can see read
performance getting reduced up to 30% (CASSANDRA-8464
Can you please run the following query on the problematic node?
select peer, host_id, release_version from system.peers where
release_version < '3.0.0' allow filtering;
I suspect you have a "ghost" 2.x node in the system.peers table on this
problematic node.
The "ghost" node will not
Assuming that the one node doesn't have
native_transport_max_negotiable_protocol_version=3 in cassandra.yaml, you could
check its log for
"Detected peers which do not fully support protocol V4. Capping max negotiable
version to V3".
The details are in CASSANDRA-15193, but tl;dr is that a
Thanks, Bowen, don't think that's an issue - but yes I can try upgrading to
3.11.5 and limit the merkle tree size to bring down the memory utilization.
Thanks, Erick, let me try that.
Can someone please share documentation relating to internal functioning of
full repairs - if there exists one?
Thanks, Pekka. But we know from an earlier post from Srinivas that the
driver is trying to negotiate with v4 but the node wouldn't:
[2021-07-09 23:26:52.382 -0700]
com.datastax.driver.core.Connection - DEBUG: Got unsupported protocol
version error from /: for version V4 server supports version
Hi,
On Thu, Jul 29, 2021 at 9:44 AM Erick Ramirez
wrote:
> When you restart C*, you should have an entry in the logs which look like
> this that indicates it defaults to v4:
>
> INFO [main] 2021-07-28 20:45:31,178 StorageService.java:650 - Native
> protocol supported versions: 3/v3, 4/v4,
When you restart C*, you should have an entry in the logs which look like
this that indicates it defaults to v4:
INFO [main] 2021-07-28 20:45:31,178 StorageService.java:650 - Native
protocol supported versions: 3/v3, 4/v4, 5/v5-beta (default: 4/v4)
I'm hoping someone else here on the mailing
12 matches
Mail list logo
