> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Introduction to Vault Replication
> Vault replication provides high availability and disaster recovery for secret management by synchronizing policies, secrets, and leases across multiple clusters.
Vault replication enables high availability and disaster recovery for your secret management platform. By leveraging Vault’s DR (Disaster Recovery) and Performance replication modes, you can synchronize policies, secrets, and leases across multiple clusters—ensuring seamless failover and consistent access in multi-region deployments.
## Understanding Vault Replication
Enterprises often distribute infrastructure across regions or data centers to maintain uptime. Vault, as the central secrets store, must follow the same architecture. Replication in HashiCorp Vault Enterprise (including HCP Vault) follows a leader-follower model:
* The **primary cluster** is the system of record.
* One or more **secondary clusters** receive asynchronous updates over mutual TLS.
Replication ensures:
* Global policy management: write policies once on primary, propagate automatically to all replicas.
* Consistent secrets: applications in any region read the same credentials and settings.
* Failover readiness: secondary clusters stand ready to assume primary duties if needed.
Vault replication is an Enterprise-only feature. Evaluate your licensing and capacity requirements before enabling replication.
Vault Enterprise supports two replication modes:
1. **Performance Replication**
2. **Disaster Recovery (DR) Replication**
We’ll start with Performance replication before diving into DR replication details.
***
## Performance Replication
Performance replication extends Vault to multiple data centers for low-latency reads. It replicates all configurations, policies, and secrets from the primary to one or more **performance secondary** clusters. Key characteristics:
* **Primary cluster**: serves all reads and writes.
* **Performance secondary**: serves local reads; forwards writes to primary.
* **Tokens & leases**: *not* replicated—clients must re-authenticate after failover.
***
## Disaster Recovery (DR) Replication
DR replication creates a warm-standby cluster that includes tokens and leases. It mirrors policies, auth methods, secret engines, and all dynamic data. This mode is ideal for planned or unplanned primary outages:
* **DR secondary**: passive; does not serve client reads/writes until promotion.
* **Tokens & leases**: fully replicated—clients continue using existing credentials after failover.
***
## Performance vs. DR Replication: Feature Comparison
| Feature | Performance Replication | DR Replication |
| ------------------------ | ------------------------ | ------------------ |
| Configuration & policies | ✓ | ✓ |
| Secret engines & data | ✓ | ✓ |
| Tokens & leases | ✗ | ✓ |
| Client reads | Secondary only | Primary only |
| Client writes | Primary only | Primary only |
| Licensing impact | Additional secondary fee | Typically included |
***
## Deep Dive: DR Cluster Behavior and Promotion
A DR secondary remains in standby until you invoke the promotion API. Until then:
* Most API endpoints are disabled (including root token generation).
* Any client request returns a “path is disabled” error.
Upon promotion:
1. The DR cluster becomes the new primary.
2. All replicated data, tokens, and leases become active.
3. Client applications resume without re-authentication.
Only one DR cluster can be promoted at a time. Promoting a DR secondary will break replication links—you must reconfigure replication after failover.
***
## Links and References
* [Vault Replication Overview](https://www.vaultproject.io/docs/enterprise/replication)
* [Vault Enterprise Licensing](https://www.vaultproject.io/docs/enterprise#licensing)
* [HCP Vault](https://cloud.hashicorp.com/products/vault)
* [HashiCorp Vault Documentation](https://www.vaultproject.io/docs)