[
https://issues.apache.org/jira/browse/CASSANDRA-20051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17896405#comment-17896405
]
Stefan Miklosovic edited comment on CASSANDRA-20051 at 11/7/24 5:01 PM:
------------------------------------------------------------------------
??At which point the running behavior is exactly the same for the cluster with
and without this fix, and nobody would be able to tell???
So after we apply that script, all nodes will have a seed set properly but that
one which will not set it to itself will contain some other node. Then we go to
remove this node from a cluster, because we were thinking there is no node
which still contains this seed. So we remove that node and we end up with a
node point to non-existing seed.
??There's no valid reason why you'd WANT a seed to point to a non-existent
node.??
Yes, nobody is doing this _on purpose_. In practice, there would have to be
some mistake made. I described the situation incorrectly. If people made
mistake, they will very likely want to fix it. We would just tell them
automatically that an IP address they used does not make sense because there is
no node behind it.
was (Author: smiklosovic):
??At which point the running behavior is exactly the same for the cluster with
and without this fix, and nobody would be able to tell???
So after we apply that script, all nodes will have a seed set properly but that
one which will not set it to itself will contain some other node. Then we go to
remove this node from a cluster, because we were thinking there is no node
which still contains this seed. So we remove that node and we end up with a
node point to non-existing seed.
??There's no valid reason why you'd WANT a seed to point to a non-existent
node.??
Yes, nobody is doing this _on purpose_. In practice, there should be some
mistake made. If people made mistake, they will very likely want to fix it. We
would just tell them automatically that an IP address they used does not make
sense because there is no node behind it.
> nodetool reloadseeds does not reliably reload the seeds
> -------------------------------------------------------
>
> Key: CASSANDRA-20051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20051
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
> Reporter: Tibor Repasi
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> During re-deploying lots of Cassandra nodes I've observed that some nodes
> does not reliably reload the seeds when {{nodetool reloadseeds}} command was
> issued.
> After the seeds list was changed in the config:
> {code}
> $ grep seeds /etc/cassandra/cassandra.yaml
> - seeds: 10.90.44.82
> $ nodetool getseeds
> Current list of seed node IPs, excluding the current node's IP:
> /10.90.40.86:7000 /10.90.44.86:7000
> $ nodetool reloadseeds
> Updated seed node IP list, excluding the current node's IP: /10.90.40.86:7000
> /10.90.44.86:7000
> {code}
> At this instance the following line was logged to debug.log:
> {code}
> DEBUG [RMI TCP Connection(103568)-127.0.0.1] 2024-11-04 14:04:27,638
> YamlConfigurationLoader.java:124 - Loading settings from
> file:/etc/cassandra/cassandra.yaml
> {code}
> However, getting the old list:
> {code}
> $ nodetool getseeds
> Current list of seed node IPs, excluding the current node's IP:
> /10.90.40.86:7000 /10.90.44.86:7000
> {code}
> These nodes read the seed list only after Cassandra was restarted:
> {code}
> $ sudo systemctl restart cassandra.service
> $ nodetool getseeds
> Seed node list does not contain any remote node IPs
> {code}
> Note: this was observed on a seed node.
> Observed on Cassandra 4.1.7.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
