IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.

« Failover when clusterA is down Tutorial: Disaster recovery based on bi-directional cross-cluster replication »

› › ›

Failback when clusterA comes back

edit

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Failback when `clusterA` comes back

edit

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

Set up remote cluster clusterB on clusterA.

resp = client.cluster.put_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"
                }
            }
        }
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    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'
          }
        }
      }
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  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",
        },
      },
    },
  },
});
console.log(response);

### 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.

resp = client.indices.delete(
    index="kibana_sample_data_ecommerce",
)
print(resp)

response = client.indices.delete(
  index: 'kibana_sample_data_ecommerce'
)
puts response

const response = await client.indices.delete({
  index: "kibana_sample_data_ecommerce",
});
console.log(response);

### On clusterA ###
DELETE kibana_sample_data_ecommerce

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

resp = client.ccr.follow(
    index="kibana_sample_data_ecommerce",
    wait_for_active_shards="1",
    remote_cluster="clusterB",
    leader_index="kibana_sample_data_ecommerce2",
)
print(resp)

const response = await client.ccr.follow({
  index: "kibana_sample_data_ecommerce",
  wait_for_active_shards: 1,
  remote_cluster: "clusterB",
  leader_index: "kibana_sample_data_ecommerce2",
});
console.log(response);

### 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.

resp = client.search(
    index="kibana_sample_data_ecommerce",
    q="kimchy",
)
print(resp)

response = client.search(
  index: 'kibana_sample_data_ecommerce',
  q: 'kimchy'
)
puts response

const response = await client.search({
  index: "kibana_sample_data_ecommerce",
  q: "kimchy",
});
console.log(response);

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

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.

« Failover when clusterA is down Tutorial: Disaster recovery based on bi-directional cross-cluster replication »