Failback when clusterA comes back

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.