diff --git a/website/source/docs/faq.html.md b/website/source/docs/faq.html.md index 1a4fc69b6..5411f098f 100644 --- a/website/source/docs/faq.html.md +++ b/website/source/docs/faq.html.md @@ -115,3 +115,14 @@ HTTP 413 status will be returned to any client that attempts to store more than that limit in a value. It should be noted that the Consul key/value store is not designed to be used as a general purpose database. See [Server Performance](/docs/guides/performance.html) for more details. + +## Q: What data is replicated between Consul datacenters? + +In general, data is not replicated between different Consul datacenters. When a +request is made for a resource in another datacenter, the local Consul servers forward +an RPC request to the remote Consul servers for that resource and return the results. +If the remote datacenter is not available, then those resources will also not be +available, but that won't otherwise affect the local datacenter. There are some special +situations where a limited subset of data can be replicated, such as with Consul's built-in +[ACL replication](/docs/guides/acl.html#outages-and-acl-replication) capability, or +external tools like [consul-replicate](https://github.com/hashicorp/consul-replicate). diff --git a/website/source/docs/guides/areas.html.markdown.erb b/website/source/docs/guides/areas.html.markdown.erb index a10574495..7a30b3737 100644 --- a/website/source/docs/guides/areas.html.markdown.erb +++ b/website/source/docs/guides/areas.html.markdown.erb @@ -21,6 +21,15 @@ failure of any datacenter does not impact the availability of Consul in other datacenters. This means each datacenter runs independently, each having a dedicated group of servers and a private LAN [gossip pool](/docs/internals/gossip.html). +In general, data is not replicated between different Consul datacenters. When a +request is made for a resource in another datacenter, the local Consul servers forward +an RPC request to the remote Consul servers for that resource and return the results. +If the remote datacenter is not available, then those resources will also not be +available, but that won't otherwise affect the local datacenter. There are some special +situations where a limited subset of data can be replicated, such as with Consul's built-in +[ACL replication](/docs/guides/acl.html#outages-and-acl-replication) capability, or +external tools like [consul-replicate](https://github.com/hashicorp/consul-replicate). + This guide covers the advanced form of federating Consul clusters using the new network areas capability added in [Consul Enterprise](https://www.hashicorp.com/products/consul/) version 0.8.0. For the basic form of federation available in the open source version diff --git a/website/source/docs/guides/datacenters.html.md b/website/source/docs/guides/datacenters.html.md index daf442e3e..66aaf0e7a 100644 --- a/website/source/docs/guides/datacenters.html.md +++ b/website/source/docs/guides/datacenters.html.md @@ -16,6 +16,15 @@ failure of any datacenter does not impact the availability of Consul in other datacenters. This means each datacenter runs independently, each having a dedicated group of servers and a private LAN [gossip pool](/docs/internals/gossip.html). +In general, data is not replicated between different Consul datacenters. When a +request is made for a resource in another datacenter, the local Consul servers forward +an RPC request to the remote Consul servers for that resource and return the results. +If the remote datacenter is not available, then those resources will also not be +available, but that won't otherwise affect the local datacenter. There are some special +situations where a limited subset of data can be replicated, such as with Consul's built-in +[ACL replication](/docs/guides/acl.html#outages-and-acl-replication) capability, or +external tools like [consul-replicate](https://github.com/hashicorp/consul-replicate). + This guide covers the basic form of federating Consul clusters using a single WAN gossip pool, interconnecting all Consul servers. [Consul Enterprise](https://www.hashicorp.com/products/consul/) version 0.8.0 added support diff --git a/website/source/docs/internals/architecture.html.md b/website/source/docs/internals/architecture.html.md index 35240872e..21fcbfbc2 100644 --- a/website/source/docs/internals/architecture.html.md +++ b/website/source/docs/internals/architecture.html.md @@ -114,6 +114,15 @@ server in the correct datacenter. That server may then forward to the local lead This results in a very low coupling between datacenters, but because of failure detection, connection caching and multiplexing, cross-datacenter requests are relatively fast and reliable. +In general, data is not replicated between different Consul datacenters. When a +request is made for a resource in another datacenter, the local Consul servers forward +an RPC request to the remote Consul servers for that resource and return the results. +If the remote datacenter is not available, then those resources will also not be +available, but that won't otherwise affect the local datacenter. There are some special +situations where a limited subset of data can be replicated, such as with Consul's built-in +[ACL replication](/docs/guides/acl.html#outages-and-acl-replication) capability, or +external tools like [consul-replicate](https://github.com/hashicorp/consul-replicate). + ## Getting in depth At this point we've covered the high level architecture of Consul, but there are many