luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

Added detail about left/failed nodes and 72h reaping 

Ref: https://groups.google.com/forum/#!searchin/consul-tool/left/consul-tool/KVl0u91uCdw/bfzrUO4r-1QJ
This commit is contained in:
Cameron Stokes 2015-08-06 17:37:48 -07:00
parent c2a865686c
commit 92b86f0631
2 changed files with 10 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
website/source/docs/agent/basics.html.markdown
View File

@ -133,9 +133,9 @@ this.
When a node _leaves_, it specifies its intent to do so, and the cluster When a node _leaves_, it specifies its intent to do so, and the cluster
marks that node as having _left_. Unlike the _failed_ case, all of the marks that node as having _left_. Unlike the _failed_ case, all of the
services provided by a node are immediately deregistered. If the agent was services provided by a node are immediately deregistered. If the agent was
a server, replication to it will stop. To prevent an accumulation a server, replication to it will stop.
of dead nodes, Consul will automatically reap _failed_ nodes out of the
catalog as well. This is currently done on a non-configurable interval of
72 hours. Reaping is similar to leaving, causing all associated services
to be deregistered.
To prevent an accumulation of dead nodes (nodes in either _failed_ or _left_ states),
Consul will automatically remove dead nodes out of the catalog. This process is
called _reaping_. This is currently done on a non-configurable interval of 72 hours.
Reaping is similar to leaving, causing all associated services to be deregistered.

11
website/source/docs/faq.html.markdown
View File

@ -67,12 +67,12 @@ interact with the service catalog and are strongly consistent. Updates to the
catalog may come via the gossip protocol which is eventually consistent, meaning catalog may come via the gossip protocol which is eventually consistent, meaning
the current state of the catalog can lag behind until the state is reconciled. the current state of the catalog can lag behind until the state is reconciled.
## Q: Are failed nodes ever removed? ## Q: Are _failed_ or _left_ nodes ever removed?
To prevent an accumulation of dead nodes, Consul will automatically reap failed To prevent an accumulation of dead nodes (nodes in either _failed_ or _left_ states),
nodes out of the catalog. This is currently done on a non-configurable interval Consul will automatically remove dead nodes out of the catalog. This process is
of 72 hours. Reaping is similar to leaving, causing all associated services to called _reaping_. This is currently done on a non-configurable interval of 72 hours.
be deregistered. Reaping is similar to leaving, causing all associated services to be deregistered.
## Q: Does Consul support delta updates for watchers or blocking queries? ## Q: Does Consul support delta updates for watchers or blocking queries?
@ -84,4 +84,3 @@ read and compute the delta client side.
By design, Consul offloads this to clients instead of attempting to support By design, Consul offloads this to clients instead of attempting to support
the delta calculation. This avoids expensive state maintenance on the servers the delta calculation. This avoids expensive state maintenance on the servers
as well as race conditions between data updates and watch registrations. as well as race conditions between data updates and watch registrations.