Uni-directional recovery: failback when clusterA comes back

ECH ECK ECE 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.