|
@@ -318,18 +318,25 @@ and pick the best fit for your environment and Vault configuration.
|
|
|
|
|
|
|
|
#### Read Your Writes
|
|
#### Read Your Writes
|
|
|
|
|
|
|
|
-The simplest method is simply utilizing the `X-Vault-Index` header returned on
|
|
|
|
|
-all write requests (including logins). Passing this header back on subsequent
|
|
|
|
|
-requests instructs the Vault client to retry the request until the server has an
|
|
|
|
|
-index greater than or equal to that returned with the last write.
|
|
|
|
|
-
|
|
|
|
|
-Obviously though, this has a performance hit because the read is blocked until
|
|
|
|
|
-the follower's local state has caught up.
|
|
|
|
|
|
|
+Vault 1.10.0 and later encodes information in the token to detect the case
|
|
|
|
|
+when a server is behind. If a Vault server does not have information about
|
|
|
|
|
+the provided token, [Vault returns a 412 error](https://www.vaultproject.io/docs/faq/ssct#q-is-there-anything-else-i-need-to-consider-to-achieve-consistency-besides-upgrading-to-vault-1-10)
|
|
|
|
|
+so clients know to retry.
|
|
|
|
|
+
|
|
|
|
|
+A method supported in versions Vault 1.7 and later is to utilize the
|
|
|
|
|
+`X-Vault-Index` header returned on all write requests (including logins).
|
|
|
|
|
+Passing this header back on subsequent requests instructs the Vault client
|
|
|
|
|
+to retry the request until the server has an index greater than or equal
|
|
|
|
|
+to that returned with the last write. Obviously though, this has a performance
|
|
|
|
|
+hit because the read is blocked until the follower's local state has caught up.
|
|
|
|
|
|
|
|
#### Forward Inconsistent
|
|
#### Forward Inconsistent
|
|
|
|
|
|
|
|
-In addition to the aforementioned `X-Vault-Index` header, Vault also supports
|
|
|
|
|
-proxying inconsistent requests to the current cluster leader for immediate
|
|
|
|
|
-read-after-write consistency. This is achieved by setting the `X-Vault-Inconsistent`
|
|
|
|
|
|
|
+Vault also supports proxying inconsistent requests to the current cluster leader
|
|
|
|
|
+for immediate read-after-write consistency.
|
|
|
|
|
+
|
|
|
|
|
+Vault 1.10.0 and later [support a replication configuration](https://www.vaultproject.io/docs/faq/ssct#q-is-there-a-new-configuration-that-this-feature-introduces) that detects when forwarding should occur and does it transparently to the client.
|
|
|
|
|
+
|
|
|
|
|
+In Vault 1.7 forwarding can be achieved by setting the `X-Vault-Inconsistent`
|
|
|
header to `forward-active-node`. By default, this behavior is disabled and must
|
|
header to `forward-active-node`. By default, this behavior is disabled and must
|
|
|
-be explicitly enabled in the server's [replication configuration](https://www.vaultproject.io/docs/configuration/replication#allow_forwarding_via_header).
|
|
|
|
|
|
|
+be explicitly enabled in the server's [replication configuration](https://www.vaultproject.io/docs/configuration/replication#allow_forwarding_via_header).
|