Failback when clusterA comes back

ECE ECK Elastic Cloud Hosted Self Managed

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

Set up remote cluster clusterB on clusterA.

		 ### 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"
        }
      }
    }
  }
}

	

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.
```
 ### On clusterA ### DELETE kibana_sample_data_ecommerce
```

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

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

	

The index on the follower cluster now contains the updated documents.
```
 ### 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.