From 9f105663141e1035f9dc76b261384235bdd738cf Mon Sep 17 00:00:00 2001 From: James Phillips Date: Wed, 26 Jul 2017 16:42:35 -0700 Subject: [PATCH] Update geo-failover.html.md --- website/source/docs/guides/geo-failover.html.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/website/source/docs/guides/geo-failover.html.md b/website/source/docs/guides/geo-failover.html.md index 6e6c869f11..c1ac39642d 100644 --- a/website/source/docs/guides/geo-failover.html.md +++ b/website/source/docs/guides/geo-failover.html.md @@ -41,6 +41,8 @@ Applications can make use of this query in two ways. Since we gave the prepared ## Failover Policies +Using the techniques in this section we will develop prepared queries with failover policies where simply changing application configurations to look up "api.query.consul" instead of "api.service.consul" via DNS will result in automatic geo failover to the next closest federated Consul datacenters, in order of increasing network round trip time. + Failover is just another policy choice for a prepared query, it works in the same manner as the previous example and is similarly transparent to applications. The failover policy is configured using the `Failover` structure, which contains two fields, both of which are optional, and determine what happens if no healthy nodes are available in the local datacenter when the query is executed. - `NearestN` `(int: 0)` - Specifies that the query will be forwarded to up to `NearestN` other datacenters based on their estimated network round trip time using [network coordinates](/docs/internals/coordinates.html).