[
https://issues.apache.org/jira/browse/CASSANDRA-18430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711502#comment-17711502
]
Brandon Williams commented on CASSANDRA-18430:
----------------------------------------------
I ran this by circle with the new tests repeated, and they seem have problems
sometimes with vnodes under both
[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/970/workflows/5169200c-8c69-4b43-ad4b-fd4c7c49172c/jobs/20538/]
and
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/970/workflows/c89aead7-4f97-48b3-bf76-623f8e50c950/jobs/20524/].
> When decommissioning should set Severity to limit traffic
> ---------------------------------------------------------
>
> Key: CASSANDRA-18430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18430
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Coordination
> Reporter: David Capwell
> Assignee: David Capwell
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> When we are decommissioning we first set LEAVING, then LEFT, then disable
> networking; timeouts start to follow at this last stage. LEFT nodes should
> not be seen as part of the ring, but that may not be seen before the network
> is disabled. To better mitigate timeouts we should set severity as part of
> decom during the LEAVING phase; by setting severity reads should deprioritize
> traffic to this node.
> Remote DC writes do not leverage proximity or severity and instead use random
> for its select, writes may still timeout even though we know the node is
> leaving, and severity is set… to work in this model we should update remote
> DC writes to deprioritize nodes with severity set
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
