Async raft sender - document in 5.26#3175
Conversation
878c673 to
94f137e
Compare
Co-authored-by: Natalia Ivakina <82437520+NataliaIvakina@users.noreply.github.com>
|
This PR includes documentation updates New pages: Updated pages: |
renetapopova
left a comment
renetapopova
left a comment
There was a problem hiding this comment.
Left some comments and questions
| [[clustering-troubleshooting-raft-sender-channel-acquisition]] | ||
| == Slow or unavailable writes when a cluster member is shut down | ||
|
|
||
| In Neo4j 5.26 LTS, a cluster can experience delayed or unavailable writes if the leader waits for a Raft sender connection to a cluster member that has stopped but whose network endpoint still accepts connection attempts. |
There was a problem hiding this comment.
Given that we are on Neo4j 5.26, I don't think we need to say it explicitly.
| In Neo4j 5.26 LTS, a cluster can experience delayed or unavailable writes if the leader waits for a Raft sender connection to a cluster member that has stopped but whose network endpoint still accepts connection attempts. | |
| A cluster can experience delayed or unavailable writes if the leader waits for a Raft sender connection to a cluster member that has stopped but whose network endpoint still accepts connection attempts. |
| That case is less likely to cause the write latency described here because the leader can move on to another member without waiting for the connection timeout. | ||
|
|
||
| [[clustering-troubleshooting-raft-sender-channel-acquisition-mitigation]] | ||
| === Mitigation in Neo4j 5.26 LTS |
There was a problem hiding this comment.
Same here.
| === Mitigation in Neo4j 5.26 LTS | |
| === Mitigation |
| [[clustering-troubleshooting-raft-sender-channel-acquisition-mitigation]] | ||
| === Mitigation in Neo4j 5.26 LTS | ||
|
|
||
| In Neo4j 5.26 LTS, enable asynchronous acquisition of Raft sender channels by setting the following internal setting to `true` in _neo4j.conf_ on all cluster members: |
|
|
||
| [NOTE] | ||
| ==== | ||
| *Behavior from Neo4j 2025.02* + |
There was a problem hiding this comment.
I think this note doesn't belong on this page. If I am on 5.26, why would I care about 2026.02? But if I'm on 2026.01, then I need to know how to fix it.
Maybe, instead of having this note here, explain a bit in the current version if we haven't already done that, and add a note that in previous version, "a cluster can experience delayed or unavailable writes if the leader waits for a Raft sender connection to a cluster member that has stopped but whose network endpoint still accepts connection attempts." and link to that page.
| [[clustering-troubleshooting]] | ||
| = Troubleshooting | ||
|
|
||
| This page describes known cluster issues and their mitigations. |
There was a problem hiding this comment.
I see only one issue. Do you know if we expect to add more?
| This page describes known cluster issues and their mitigations. | ||
|
|
||
| [[clustering-troubleshooting-raft-sender-channel-acquisition]] | ||
| == Slow or unavailable writes when a cluster member is shut down |
There was a problem hiding this comment.
If we have just one issue, maybe this could be the title instead of "Troubleshooting." Something like: "Troubleshooting slow or unavailable writes"
5 participants
Part of CLUSTER-1827
In this PR, we add troubleshooting for raft sender problems. This cause of this can be found in this internal document. However, customers in 5.26LTS are now asking for a more detailed write up of cause and mitigation, which is presented here.
I will also ask someone in clustering to review this.