Search with OpenSearch High Availability

Search with OpenSearch supports high availability (HA) across OpenSearch node types, with particular focus on leader nodes, also commonly referred to as master nodes, and data nodes. Leader nodes manage cluster state, node membership, index metadata, and cluster-level decisions. Data nodes store and serve indexed data, hold primary and replica shards, and handle indexing and search traffic. Both roles are critical: leader-node HA protects cluster coordination, while data-node HA protects search and indexing continuity.

An HA cluster has the following node settings:

• Leader Nodes: Minimum of 3 spread across 3 separate domains. Three nodes are mathematically required to maintain a strict quorum (2 out of 3 votes) to avoid split-brain scenarios.
• Data Nodes: Minimum 2 or 3 distributed equally across your domains to mirror primary and replica data storage.
• OpenSearch Dashboard Nodes: Minimum of 2 configured behind a load balancer to guarantee continuous access to the Dashboard user interface.

For more information on nodes and their recommended settings, see Cluster Node Sizes.

In a multi-availability-domain region, Search with OpenSearch places OpenSearch nodes across separate availability domains. In a single-availability-domain region, it places nodes across separate fault domains. A fault domain is a distinct grouping of hardware and infrastructure within an availability domain.

The following example of a single-AD region shows how this works.

In this example, the OpenSearch cluster runs in one availability domain, but its critical nodes are spread across three fault domains. Each dedicated leader node is placed in a separate fault domain, helping protect cluster management. Data nodes are also spread across fault domains, creating the foundation for resilient shard placement.

OpenSearch stores data in shards. Each index has primary shards, and customers can configure replica shards to create additional copies of the data. Search with OpenSearch can pass availability-domain or fault-domain metadata into OpenSearch as a node attribute. OpenSearch then uses that attribute when placing and rebalancing shards.

The model is:

OCI node placement → AD or fault-domain metadata → OpenSearch node attribute → shard allocation awareness → resilient primary and replica placement

In multi-AD regions, OpenSearch can use availability-domain awareness. In single-AD regions, it can use fault-domain awareness.

With awareness enabled, OpenSearch attempts to keep a primary shard and its replicas on different availability domains or fault domains whenever capacity allows. This is a best-effort model. The cluster still needs enough healthy nodes, replicas, unique domains, and available capacity to maintain the intended distribution.

Replicas are most useful when you place them away from the primary copy. By combining node placement with shard allocation awareness, Search with OpenSearch helps reduce correlated infrastructure risk and improves the likelihood that at least one copy of the data remains available during node, fault-domain, or availability-domain events.

If a primary becomes unavailable, OpenSearch automatically promotes an in-sync replica shard to primary. This allows the cluster to continue serving traffic without manual intervention.

If an entire fault domain becomes unavailable, shard copies in other fault domains remain available, provided the cluster has enough healthy replicas elsewhere in the cluster.

The cluster status after a failure depends on shard replication and node capacity. If a primary shard fails but an in-sync replica is available, the cluster typically stays yellow while OpenSearch promotes the replica and later restores missing replicas. The cluster can become red if one or more primary shards have no available copy to promote, which is more likely when the cluster has too few nodes, too few replicas, or several simultaneous failures. That is, the same failure might produce different health states depending on replica count, shard placement, and node capacity.

You can validate fault domain awareness using the following commands:

GET _cat/nodeattrs?v
GET _cat/shards?v

Use these checks to confirm that the expected node attribute is present and that primary and replica shards are distributed across separate fault domains or availability domains.

Using HA clusters improves resilience against node and fault-domain failures and reduces the chance that a single infrastructure issue affects several copies of the same shard. It's most effective when your clusters are properly sized and shard replicas are configured appropriately.