2、跨集群搜索基础配置：配置远程集群、设置cluster.remote、验证连接状态

好，咱们正式开始动手配置。

跨集群搜索，说白了就是让一个Elasticsearch集群，能去查询另一个集群里的数据。你想想看，业务大了以后，数据不可能全塞在一个集群里。可能是不同部门、不同机房，甚至不同云厂商。这时候，跨集群搜索就派上用场了。

我个人习惯，在搭建任何分布式系统之前，先把网络和基础配置理清楚。这一步要是乱了，后面排查起来会非常痛苦。

2.1 配置远程集群：先让两个集群“认识”

跨集群搜索的第一步，是让本地集群知道远程集群的存在。这个“认识”的过程，就是通过配置 cluster.remote 来实现的。

假设我有两个集群：

  • 集群A（本地集群）：我要在这里发起查询。
  • 集群B（远程集群）：数据存在这里，集群名叫 cluster_b。

我需要告诉集群A：“嘿，有个兄弟叫 cluster_b，它的地址是 192.168.1.100:9300 和 192.168.1.101:9300”。

配置方式有两种：

方式一：在 elasticsearch.yml 中静态配置

这是最稳妥的方式。我建议你在生产环境用这个。修改集群A的 elasticsearch.yml 文件，添加以下内容：

# 配置远程集群
cluster.remote:
    cluster_b:
        seeds: 192.168.1.100:9300, 192.168.1.101:9300
        # 可选：设置连接模式，默认是 sniff
        mode: sniff
        # 可选：设置节点数，默认是 3
        node_connections: 3

这里要注意几个点：

  • seeds：种子节点地址。格式是 ip:transport_port。默认transport端口是9300，不是9200。我见过有人配成9200，结果连了半天连不上。
  • mode：连接模式。默认是 sniff，意思是集群A会先连上种子节点，然后自动发现集群B的所有节点。另一种是 proxy，适合通过负载均衡器连接。
  • node_connections：每个远程集群最多保持连接的节点数。默认3个，够用。
⚠️ 注意： 修改 elasticsearch.yml 后，需要重启节点才能生效。如果你不想重启，可以用下面的动态配置方式。

方式二：通过 API 动态配置

这种方式不需要重启，适合快速验证。我个人在测试环境经常用。

PUT _cluster/settings
{
    "persistent": {
        "cluster.remote.cluster_b.seeds": ["192.168.1.100:9300", "192.168.1.101:9300"]
    }
}

这里我用了 persistent，意思是集群重启后配置还在。如果你只想临时测试，可以用 transient。

2.2 设置 cluster.remote：核心参数详解

配置远程集群，不只是配个地址就完事了。有几个核心参数，我建议你花点时间理解一下。

参数 默认值 说明
cluster.remote.*.seeds 无 远程集群的种子节点列表，必填
cluster.remote.*.mode sniff 连接模式：sniff 或 proxy
cluster.remote.*.node_connections 3 最多连接的远程节点数
cluster.remote.*.transport.ping_schedule 30s 心跳检测间隔，用于检查远程节点是否存活
cluster.remote.*.transport.compress false 是否压缩传输数据。跨机房建议开启

嗯，这里要特别说一下 mode 参数。我曾经在项目里踩过坑：两个集群在不同机房，网络延迟比较高。我用了默认的 sniff 模式，结果集群A每次查询都要去发现集群B的所有节点，导致查询变慢。

后来我改成 proxy 模式，通过一个统一的网关地址连接，性能就稳定多了。所以，如果你的远程集群节点很多，或者网络环境复杂，可以考虑用 proxy 模式。

2.3 验证连接状态：确认“握手”成功

配置完了，怎么知道连没连上？别急，Elasticsearch 提供了几个API来验证。

方法一：查看远程集群信息

GET _remote/info

这个API会返回所有已配置的远程集群信息。返回结果大概长这样：

{
    "cluster_b": {
        "seeds": ["192.168.1.100:9300", "192.168.1.101:9300"],
        "connected": true,
        "num_nodes_connected": 3,
        "max_connections_per_cluster": 3,
        "initial_connect_timeout": "30s",
        "skip_unavailable": false,
        "mode": "sniff"
    }
}

关键看两个字段：

  • connected：是否已连接。如果是 true，说明握手成功。
  • num_nodes_connected：实际连接了多少个远程节点。如果这个数字是0，说明虽然配置了种子节点，但没连上任何节点。
💡 小技巧： 如果 connected 是 false，别慌。先检查网络通不通，telnet一下远程节点的9300端口。我遇到过好几次，配置没问题，但防火墙把9300端口给拦了。

方法二：尝试跨集群查询

最直接的方式，就是真的去查一下远程集群的数据。

GET cluster_b:my_index/_search
{
    "query": {
        "match_all": {}
    }
}

注意这里的语法：远程集群名:索引名。如果返回了数据，说明配置成功。如果返回 no such remote cluster 之类的错误，那就得回去检查配置了。

2.4 避坑指南：我踩过的几个坑

配置跨集群搜索，看起来简单，但实际部署时容易出问题。我把自己踩过的坑分享给你：

  • 端口搞错：我曾经把 seeds 配成了9200（HTTP端口），结果怎么都连不上。记住，跨集群通信走的是Transport协议，端口是9300。
  • 集群名冲突：两个集群的 cluster.name 不能一样。如果一样，Elasticsearch会认为它们是同一个集群，导致配置失败。
  • 版本不兼容：跨集群搜索要求两个集群的主版本号一致。比如都是7.x，或者都是8.x。我见过有人用7.x连8.x，结果查询报错。
  • 网络延迟：跨机房查询时，网络延迟会直接影响查询速度。建议开启 transport.compress 来减少数据传输量。
📌 我的建议： 在正式上线前，先在一个测试环境里把跨集群搜索跑通。用 _remote/info 确认连接状态，再用简单的查询验证数据是否可达。这一步花不了多少时间，但能避免很多线上问题。

好了，跨集群搜索的基础配置就这些。说白了，就是配个地址、设个模式、验证一下连接。但别小看这几步，它们是后面所有高级功能的基础。下一章，我们会聊聊如何优化跨集群查询的性能，包括缓存、路由和负载均衡。到时候见！

← 上一章 📖 返回目录 下一章 →