-
Notifications
You must be signed in to change notification settings - Fork 25.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generalize TCP retxn docs to cover remote clusters #74732
Generalize TCP retxn docs to cover remote clusters #74732
Conversation
Today the docs on setting `tcp_retries2` only talk about intra-cluster connections, but in fact this setting is equally important to the resilience of remote cluster connections too. This commit rewords these docs to cover both cases. Relates elastic#34405
Pinging @elastic/es-distributed (Team:Distributed) |
Pinging @elastic/es-docs (Team:Docs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I left suggestions for a few non-blocking nits.
they can react promptly by reallocating lost shards, rerouting searches and | ||
perhaps electing a new master node. Linux users should therefore reduce the | ||
maximum number of TCP retransmissions. | ||
very long periods of packet loss but this default is excessive and even harmful |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Compound sentences require a comma before the conjuction.
very long periods of packet loss but this default is excessive and even harmful | |
very long periods of packet loss, but this default is excessive and even harmful |
perhaps electing a new master node. Linux users should therefore reduce the | ||
maximum number of TCP retransmissions. | ||
very long periods of packet loss but this default is excessive and even harmful | ||
on the high quality networks used by most {es} installations. Highly-available |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: No hyphen needed.
on the high quality networks used by most {es} installations. Highly-available | |
on the high quality networks used by most {es} installations. Highly available |
maximum number of TCP retransmissions. | ||
very long periods of packet loss but this default is excessive and even harmful | ||
on the high quality networks used by most {es} installations. Highly-available | ||
clusters must be able to detect node failures promptly in order to react by |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: This sentence gets a bit long. I'd break it into two. Regardless, in order to
can be shortened to to
.
clusters must be able to detect node failures promptly in order to react by | |
clusters must be able to detect node failures promptly. This lets the cluster react by |
very long periods of packet loss but this default is excessive and even harmful | ||
on the high quality networks used by most {es} installations. Highly-available | ||
clusters must be able to detect node failures promptly in order to react by | ||
reallocating lost shards, rerouting searches and perhaps electing a new master |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: We tend to use an Oxford comma.
reallocating lost shards, rerouting searches and perhaps electing a new master | |
reallocating lost shards, rerouting searches, or electing a new master |
reliability of communication with systems outside your cluster too. If your | ||
cluster communicates with external systems over an unreliable network then you | ||
reliability of communication with systems other than {es} clusters too. If your | ||
clusters communicate with external systems over a low-quality network then you |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: No hyphen needed.
clusters communicate with external systems over a low-quality network then you | |
clusters communicate with external systems over a low quality network then you |
or communication between the nodes is disrupted by a failure in the underlying | ||
Each pair of {es} nodes communicates via a number of TCP connections which | ||
<<long-lived-connections,remain open>> until one of the nodes shuts down or | ||
communication between the nodes is disrupted by a failure in the underlying | ||
infrastructure. | ||
|
||
TCP provides reliable communication over occasionally-unreliable networks by |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: No hyphen is needed between an adverb and adjective.
TCP provides reliable communication over occasionally-unreliable networks by | |
TCP provides reliable communication over occasionally unreliable networks by |
Today the docs on setting `tcp_retries2` only talk about intra-cluster connections, but in fact this setting is equally important to the resilience of remote cluster connections too. This commit rewords these docs to cover both cases. Relates #34405
Today the docs on setting `tcp_retries2` only talk about intra-cluster connections, but in fact this setting is equally important to the resilience of remote cluster connections too. This commit rewords these docs to cover both cases. Relates #34405
Today the docs on setting `tcp_retries2` only talk about intra-cluster connections, but in fact this setting is equally important to the resilience of remote cluster connections too. This commit rewords these docs to cover both cases. Relates #34405
Today the docs on setting
tcp_retries2
only talk about intra-clusterconnections, but in fact this setting is equally important to the
resilience of remote cluster connections too. This commit rewords these
docs to cover both cases.
Relates #34405