mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-22 15:11:07 +02:00
0660ea6fac
* Update README Let contributors know that docs will now be located in UDR * Add comments to each mdx doc Comment has been added to all mdx docs that are not partials * chore: added changelog changelog check failure * wip: removed changelog * Fix content errors * Doc spacing * Update website/content/docs/deploy/kubernetes/vso/helm.mdx Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com> --------- Co-authored-by: jonathanfrappier <92055993+jonathanfrappier@users.noreply.github.com> Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
57 lines
3.7 KiB
Plaintext
57 lines
3.7 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Replication - Configuration
|
|
description: |-
|
|
Configure the replication stanza to tune replication behavior in Vault.
|
|
---
|
|
|
|
> [!IMPORTANT]
|
|
> **Documentation Update:** Product documentation, which were located in this repository under `/website`, are now located in [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs), colocated with all other product documentation. Contributions to this content should be done in the `web-unified-docs` repo, and not this one. Changes made to `/website` content in this repo will not be reflected on the developer.hashicorp.com website.
|
|
|
|
# `replication` stanza
|
|
|
|
@include 'alerts/enterprise-only.mdx'
|
|
|
|
The `replication` stanza specifies various parameters for tuning replication related values.
|
|
|
|
```hcl
|
|
replication {
|
|
resolver_discover_servers = true
|
|
logshipper_buffer_length = 1000
|
|
logshipper_buffer_size = "5gb"
|
|
allow_forwarding_via_header = false
|
|
best_effort_wal_wait_duration = "2s"
|
|
}
|
|
```
|
|
|
|
## `replication` parameters
|
|
|
|
- `resolver_discover_servers` `(boolean: true)` - This feature should probably always be turned on. It enables secondary
|
|
cluster nodes to reach out to nodes in the primary cluster to request information on who the active node is. This
|
|
fixes an issue where a secondary cluster may only know about a single node in the primary cluster, and if that node
|
|
isn't the active node, the replication connection will not succeed. With resolving disabled, the only way around this
|
|
is to go through an onerous UpdatePrimary workflow, or do step-downs on the primary cluster until the one node known
|
|
by the secondary cluster is active.
|
|
- `logshipper_buffer_length` `(integer: 16384)` - The maximum number of entries that the log shipper buffer can hold.
|
|
If this is not specified, a default of 16K will be used.
|
|
- `logshipper_buffer_size` `(string: "")` - The maximum size that the log shipper buffer can be. This size can be
|
|
expressed as an integer, indicating the number of bytes, or as a capacity string. Capacity strings are a number,
|
|
followed by an optional space, followed by a suffix indicating the capacity. Valid suffixes are:
|
|
`kb, kib, mb, mib, gb, gib, tb, tib`, which correspond to kilobytes, kibibytes, megabytes, mebibytes, etc. Full
|
|
details on multiple-byte units in both powers of 2 and 10 can be found [on Wikipedia](https://en.wikipedia.org/wiki/Byte#Multiple-byte_units). The suffixes are not case-sensitive. If this
|
|
is not specified, Vault will attempt to read the total amount of memory available on the host it's running on. If
|
|
that succeeds, Vault will use 10% of the value found. If Vault is unable to read the amount of host memory, this
|
|
defaults to 1GB.
|
|
- `allow_forwarding_via_header` `(boolean: false)` - Enable forwarding options for client controlled consistency,
|
|
i.e. `X-Vault-Inconsistent: forward-active-node` and `X-Vault-Forward: active-node`.
|
|
- `best_effort_wal_wait_duration` `(duration: "2s")` - Legacy mitigation to try to prevent stale reads: when a
|
|
write is made via RPC, i.e. the node handling the request didn't do the write itself, wait up to this much
|
|
time to see the resulting WAL present locally before returning a response to the client.
|
|
- `allow_forwarding_via_token` `(string: "")` - When set to `new_token`, requests sent to non-active nodes
|
|
are forwarded if the node does not yet have the token information in storage.
|
|
- `replication_canary_write_interval_seconds` `(integer: 1)` - Interval in
|
|
seconds between writes of the replication canary to the storage on the primary
|
|
cluster. Set to 0 to disable the canary. Refer to the [Clock skew and
|
|
replication
|
|
lag](/vault/docs/enterprise/consistency#clock-skew-and-replication-lag) page
|
|
for details on the canary. |