The remote clusters module enables you to establish uni-directional connections to a remote cluster. This functionality is used in cross-cluster replication and cross-cluster search.

Remote cluster connections work by configuring a remote cluster and connecting only to a limited number of nodes in that remote cluster. Each remote cluster is referenced by a name and a list of seed nodes. When a remote cluster is registered, its cluster state is retrieved from one of the seed nodes and up to three gateway nodes are selected to be connected to as part of remote cluster requests. All the communication required between different clusters goes through the transport layer. Remote cluster connections consist of uni-directional connections from the coordinating node to the selected remote gateway nodes only.

Gateway nodes selection

The gateway nodes selection depends on the following criteria:

Configuring remote clusters

You can configure remote clusters globally by using cluster settings, which you can update dynamically. Alternatively, you can configure them locally on individual nodes by using the elasticsearch.yml file.

If you specify the settings in elasticsearch.yml files, only the nodes with those settings can connect to the remote cluster. In other words, functionality that relies on remote cluster requests must be driven specifically from those nodes. For example:

cluster:
    remote:
        cluster_one: 
            seeds: 127.0.0.1:9300
            transport.ping_schedule: 30s 
        cluster_two:
            seeds: 127.0.0.1:9301
            transport.compress: true 
            skip_unavailable: true 

For more information about the optional transport settings, see Transport.

If you use cluster settings, the remote clusters are available on every node in the cluster. For example:

PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "cluster_one": {
          "seeds": [
            "127.0.0.1:9300"
          ],
          "transport.ping_schedule": "30s"
        },
        "cluster_two": {
          "seeds": [
            "127.0.0.1:9301"
          ],
          "transport.compress": true,
          "skip_unavailable": true
        },
        "cluster_three": {
          "seeds": [
            "127.0.0.1:9302"
          ]
        }
      }
    }
  }
}

You can dynamically update the compression and ping schedule settings. However, you must re-include seeds in the settings update request. For example:

PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "cluster_one": {
          "seeds": [
            "127.0.0.1:9300"
          ],
          "transport.ping_schedule": "60s"
        },
        "cluster_two": {
          "seeds": [
            "127.0.0.1:9301"
          ],
          "transport.compress": false
        }
      }
    }
  }
}

When the compression or ping schedule settings change, all the existing node connections must close and re-open, which can cause in-flight requests to fail.

A remote cluster can be deleted from the cluster settings by setting its seeds and optional settings to null :

PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "cluster_two": { 
          "seeds": null,
          "skip_unavailable": null,
          "transport": {
            "compress": null
          }
        }
      }
    }
  }
}

Remote cluster settings

Retrieving remote clusters info

You can use the remote cluster info API to retrieve information about the configured remote clusters, as well as the remote nodes that the node is connected to.