From 09b424f3f4e866de429bd2390d602b9c1ef4eba6 Mon Sep 17 00:00:00 2001 From: Laurent Raufaste Date: Sun, 3 Aug 2014 17:22:19 -0400 Subject: [PATCH 1/3] Missing "it" --- website/source/intro/getting-started/join.html.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/source/intro/getting-started/join.html.markdown b/website/source/intro/getting-started/join.html.markdown index 53bc44fa6..74405cff2 100644 --- a/website/source/intro/getting-started/join.html.markdown +++ b/website/source/intro/getting-started/join.html.markdown @@ -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. From 7fbbb7f3b0b232d492d088e89eecfc7c54d5cfd1 Mon Sep 17 00:00:00 2001 From: Laurent Raufaste Date: Sun, 3 Aug 2014 17:55:22 -0400 Subject: [PATCH 2/3] paramter -> parameter --- website/source/intro/getting-started/kv.html.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/source/intro/getting-started/kv.html.markdown b/website/source/intro/getting-started/kv.html.markdown index 5c8dcf70e..f55b76470 100644 --- a/website/source/intro/getting-started/kv.html.markdown +++ b/website/source/intro/getting-started/kv.html.markdown @@ -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": From fc81726db496db10eec4f7ae7cffab0da09b572a Mon Sep 17 00:00:00 2001 From: Laurent Raufaste Date: Sun, 3 Aug 2014 21:28:17 -0400 Subject: [PATCH 3/3] Updated links to the deployment table --- website/source/docs/guides/bootstrapping.html.markdown | 2 +- website/source/docs/guides/manual-bootstrap.html.markdown | 2 +- website/source/docs/guides/outage.html.markdown | 2 +- website/source/docs/guides/servers.html.markdown | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/website/source/docs/guides/bootstrapping.html.markdown b/website/source/docs/guides/bootstrapping.html.markdown index 472a949f4..c197fdfe1 100644 --- a/website/source/docs/guides/bootstrapping.html.markdown +++ b/website/source/docs/guides/bootstrapping.html.markdown @@ -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. diff --git a/website/source/docs/guides/manual-bootstrap.html.markdown b/website/source/docs/guides/manual-bootstrap.html.markdown index f1375031e..bdb2ea93a 100644 --- a/website/source/docs/guides/manual-bootstrap.html.markdown +++ b/website/source/docs/guides/manual-bootstrap.html.markdown @@ -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 diff --git a/website/source/docs/guides/outage.html.markdown b/website/source/docs/guides/outage.html.markdown index 893cd6694..22ce3b1a6 100644 --- a/website/source/docs/guides/outage.html.markdown +++ b/website/source/docs/guides/outage.html.markdown @@ -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. diff --git a/website/source/docs/guides/servers.html.markdown b/website/source/docs/guides/servers.html.markdown index 9cf535bed..5e62e4922 100644 --- a/website/source/docs/guides/servers.html.markdown +++ b/website/source/docs/guides/servers.html.markdown @@ -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.