Type to search.

Uni-directional recovery: failback when clusterA comes back

ECH

Elastic Cloud Hosted lets you manage and configure one or more deployments of the versioned Elastic Stack, hosted on Elastic Cloud.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

ECK

Elastic Cloud on Kubernetes extends Kubernetes orchestration capabilities to allow you to deploy and manage components of the Elastic Stack.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.

ECE

Elastic Cloud Enterprise is a self-managed orchestration platform for deploying and managing the Elastic Stack at scale.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.

Self-managed

Self-managed deployments are Elastic Stack deployments managed without the assistance of an orchestrator.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.

When clusterA comes back, clusterB becomes the new leader and clusterA becomes the follower.

  1. Set up remote cluster clusterB on clusterA.

    JSON 
    
### On clusterA ###
PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "clusterB": {
          "mode": "proxy",
          "skip_unavailable": "true",
          "server_name": "clusterb.es.region-b.gcp.elastic-cloud.com",
          "proxy_socket_connections": "18",
          "proxy_address": "clusterb.es.region-b.gcp.elastic-cloud.com:9400"
        }
      }
    }
  }
}

  2. Existing data needs to be discarded before you can turn any index into a follower. Ensure the most up-to-date data is available on clusterB prior to deleting any indices on clusterA.

    JSON 
    
### On clusterA ###
DELETE kibana_sample_data_ecommerce

  3. Create a follower index on clusterA, now following the leader index in clusterB.

    JSON 
    
### On clusterA ###
PUT /kibana_sample_data_ecommerce/_ccr/follow?wait_for_active_shards=1
{
  "remote_cluster": "clusterB",
  "leader_index": "kibana_sample_data_ecommerce2"
}

  4. The index on the follower cluster now contains the updated documents.

    JSON 
    
### On clusterA ###
GET kibana_sample_data_ecommerce/_search?q=kimchy
    Tip

    If a soft delete is merged away before it can be replicated to a follower the following process will fail due to incomplete history on the leader, see index.soft_deletes.retention_lease.period for more details.