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

Merge pull request #270 from lra/another_typo 

website: Missing "it" and other small fixes
This commit is contained in:
Armon Dadgar 2014-08-03 20:46:54 -07:00
parent 7a75266e08 fc81726db4
commit 20e909886e
6 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/source/docs/guides/bootstrapping.html.markdown
View File

@ -19,7 +19,7 @@ inconsistencies and split-brain situations, all servers should specify the same
or specify no value at all. Any server that does not specify a value will not attempt to
bootstrap the cluster.
There is a [deployment table](/docs/internals/consensus.html#toc_3) that covers various options,
There is a [deployment table](/docs/internals/consensus.html#toc_4) that covers various options,
but it is recommended to have 3 or 5 total servers per data center. A single server deployment is _**highly**_
discouraged as data loss is inevitable in a failure scenario.

2
website/source/docs/guides/manual-bootstrap.html.markdown
View File

@ -24,7 +24,7 @@ When starting `Node A` something like the following will be logged:
2014/02/22 19:23:32 [INFO] consul: cluster leadership acquired
Once `Node A` is running, we can start the next set of servers. There is a [deployment table](/docs/internals/consensus.html#toc_3)
Once `Node A` is running, we can start the next set of servers. There is a [deployment table](/docs/internals/consensus.html#toc_4)
that covers various options, but it is recommended to have 3 or 5 total servers per data center.
A single server deployment is _**highly**_ discouraged as data loss is inevitable in a failure scenario.
We start the next servers **without** specifying `-bootstrap`. This is critical, since only one server

2
website/source/docs/guides/outage.html.markdown
View File

@ -7,7 +7,7 @@ sidebar_current: "docs-guides-outage"
# Outage Recovery
Do not panic! This is a critical first step. Depending on your
[deployment configuration](/docs/internals/consensus.html#toc_3), it may
[deployment configuration](/docs/internals/consensus.html#toc_4), it may
take only a single server failure for cluster unavailability. Recovery
requires an operator to intervene, but is straightforward.

2
website/source/docs/guides/servers.html.markdown
View File

@ -71,7 +71,7 @@ the new servers up-to-date.
Removing servers must be done carefully to avoid causing an availability outage.
For a cluster of N servers, at least (N/2)+1 must be available for the cluster
to function. See this [deployment table](/docs/internals/consensus.html#toc_3).
to function. See this [deployment table](/docs/internals/consensus.html#toc_4).
If you have 3 servers, and 1 of them is currently failed, removing any servers
will cause the cluster to become unavailable.

2
website/source/intro/getting-started/join.html.markdown
View File

@ -14,7 +14,7 @@ real cluster with multiple members.
When starting a Consul agent, it begins without knowledge of any other node, and is
an isolated cluster of one. To learn about other cluster members, the agent must
_join_ an existing cluster. To join an existing cluster, only needs to know
_join_ an existing cluster. To join an existing cluster, it only needs to know
about a _single_ existing member. After it joins, the agent will gossip with this
member and quickly discover the other members in the cluster. A Consul
agent can join any other agent, it doesn't have to be an agent in server mode.

2
website/source/intro/getting-started/kv.html.markdown
View File

@ -85,7 +85,7 @@ $ curl http://localhost:8500/v1/kv/web?recurse
A key can be updated by setting a new value by issuing the same PUT request.
Additionally, Consul provides a Check-And-Set operation, enabling atomic
key updates. This is done by providing the `?cas=` paramter with the last
key updates. This is done by providing the `?cas=` parameter with the last
`ModifyIndex` value from the GET request. For example, suppose we wanted
to update "web/key1":