Today, we’re excited to announce cross-region replication in OCI Cache, a new capability that helps customers improve disaster recovery readiness, serve globally distributed applications, and support planned workload migration between Oracle Cloud Infrastructure regions. With cross-region replication, OCI Cache can asynchronously replicate data from a primary cache cluster in one OCI region to a secondary cache cluster in another region.
The challenge: resilient cache architectures across regions
Caches are often on the critical path for modern applications, holding session state, user context, feature flags, application metadata, and other frequently accessed data. When a cache becomes unavailable, applications can experience higher latency, degraded functionality, or downtime, which can affect business outcomes and customer trust.
OCI Cache supports high availability within a region by using replica nodes and placing cluster nodes across availability domains or fault domains where available. But disaster recovery planning also requires a strategy for wider regional events, and a warm environment in another region can be essential to the overall recovery plan. This is particularly relevant in single availability-domain regions where node placement options are more constrained.
Before cross-region replication, teams generally relied on point-in-time backups, export and import workflows, or custom replication patterns to prepare for regional recovery. Those methods remain useful, but they can require manual runbooks and leave a larger gap between the primary cache state and the cache in another region. For applications with frequent cache updates, such delays can translate into recovery risks.
How cross-region replication helps
Cross-region replication in OCI Cache gives customers an OCI-managed way to keep a secondary cache cluster synchronized with a primary cluster in a different OCI region. OCI Cache establishes the replication relationship, performs an initial synchronization, and continuously sends subsequent changes to the secondary region over encrypted, private OCI networking. Customers do not need to build a remote peering connection for the replication path.
The result is a warm secondary environment that is continuously updated from the primary cluster to support a stronger disaster recovery posture. It also gives operations teams a controlled path for planned regional maintenance or workload migration.
OCI Cache is designed to keep the asynchronous replication latency in the range of a few seconds under typical operating conditions. Actual latency depends on factors such as write volume, dataset size, resource utilization, network latency, and the distance between the selected OCI regions.
Key concepts and capabilities
Cross-region replication in OCI Cache introduces new cluster roles to support the active-passive topology.
Primary cluster: Accepts reads and writes and sends data changes to the secondary cluster.
Secondary cluster: Receives changes from the primary cluster and accepts read operations only. To accept writes, the secondary must become primary through a planned switchover or be converted to standalone.
Standalone cluster: Not part of a cross-region replication relationship and accepts both read and write operations.
Create a secondary cluster
Customers can create a secondary cluster through the standard OCI Cache cluster creation workflow by selecting Secondary cluster and choosing a source region, compartment, and eligible standalone primary cluster. OCI Cache assigns the appropriate roles and begins the initial synchronization.
Customers that already have capacity in a target region can instead convert an eligible standalone cluster to a secondary. Because that action replaces the target cluster’s existing data with data from the selected primary, it should be planned accordingly.
Before creating or converting a secondary cluster, set the following Configuration parameters on the participating clusters.
reserved-memory-percentage= 35% or highermaxmemory-policy= a value other than noeviction
These settings are mandatory for cross-region replication; a cluster that does not meet them cannot be used in a replication relationship.
Perform planned switchovers
For planned regional maintenance or workload migration, customers can initiate a switchover from the current secondary cluster. The operation reverses the roles: the former secondary becomes primary and the former primary becomes secondary. Both clusters and regions must be available to perform this action. Customers should stop application writes before beginning the switchover to minimize the risk of data loss.
Recover when the primary region is unavailable
If the primary region is unavailable, a switchover is not appropriate because both clusters must communicate. Instead, customers can convert the secondary cluster to standalone. This action makes the secondary writable while retaining the data that was replicated before the conversion. Customers should use their disaster recovery monitoring and runbooks to determine when recovery is required, convert the secondary to standalone, and redirect their applications to the secondary cluster endpoint.
Monitor replication health
OCI Cache surfaces cross-region replication information on the cluster details page, including the cluster role, associated cluster, region, lifecycle state, and relationship links. Customers can also monitor health with new metrics such as CrossRegionReplicationLag and CrossRegionMasterLinkStatus.
Operational considerations
Cross-region replication is asynchronous. Writes must complete on the primary before they are applied to the secondary, so applications that read from the secondary must tolerate eventual consistency. Customers should also plan for the following three areas of considerations.
Guardrails for reliable replication
Cross-region replication coordinates two OCI Cache clusters across two OCI regions, so the feature has more operational complexity than a single-region cache deployment. OCI Cache must keep the secondary cluster synchronized while preserving the performance and stability of the primary cluster that continues to serve the application’s write traffic. To support smooth replication and reduce the risk of replication activity competing with application workloads, OCI Cache applies specific guardrails for clusters that use cross-region replication.
To use cross-region replication, clusters must be configured with at least 8 GB per node. Customers should also plan for the additional memory overhead required by replication. Memory set aside using the reserved-memory-percentage configuration parameter helps ensure that application workloads have sufficient headroom while replication buffers, synchronization activity, and cross-region data transfer are running. For cross-region replication, customers must configure reserved_memory_percentage to 35% or higher.
Customers should include these requirements in their capacity planning, disaster recovery runbooks, and pre-production validation before enabling cross-region replication for production workloads.
Configuration
Beyond the guardrails, customers should ensure that the participating clusters meet the required compatibility rules. The primary and secondary clusters must be in different OCI regions and must use matching engine versions, cluster modes, and memory sizes. At present, cross-region replication is supported for non-sharded clusters. Cluster configuration and ACL users are not copied automatically to the secondary region, so customers should keep them consistent across both regions if the regions are part of their disaster recovery operating model.
Administrators must grant IAM policies that include the REDIS_CLUSTER_REPLICATE permission on participating clusters to establish and manage the replication relationship.
A regional failure typically requires a coordinated, full-stack recovery across application, networking, database, cache, and operational layers, so teams should use their disaster recovery runbooks to decide when to promote or convert the secondary environment. For this reason, automatic failover to the secondary region is not supported.
Sizing and cost
From a sizing and cost perspective, cross-region replication uses a secondary OCI Cache cluster in another region, so customers incur the cost of that additional cluster. Inter-region replication can also incur network egress charges depending on the volume of data replicated between regions.
Customers can add one or more replica nodes to the secondary cluster based on their resilience, read scaling, and cost requirements. For disaster recovery-only deployments, they might choose fewer replica nodes in the secondary cluster to begin with and add more during a recovery event. For globally distributed applications that serve reads from the secondary region, they should add replica nodes to the secondary cluster for the expected read workload. The secondary cluster’s node count can be scaled independently, giving customers flexibility to add or remove capacity in the remote region as requirements change.
Memory scaling is supported only in the primary region. The service automatically orchestrates the corresponding resize in the secondary cluster.
Get started
Cross-region replication helps OCI Cache customers simplify regional recovery preparation, reduce operational steps, and make planned regional transitions more predictable, especially where a second region is essential to the availability strategy.
To get started, navigate to OCI Cache in the OCI Console, create a new cluster using the Secondary cluster creation type, and select the source region, compartment, and eligible primary cluster.