Elasticsearch双节点集群数据同步异常排查求助

问题原因分析 #

1. 集群脑裂：双节点均为master eligible节点，升级过程中若出现网络中断、节点重启不同步，会导致集群分裂为两个独立集群，各自选举自身为master，同一分片在两个节点上都被标记为primary，后续写入的数据各自存储，无法同步。
2. 版本升级元数据兼容性问题：从7.9跨版本升级到7.17.4，元数据（分片状态、集群配置）可能存在迁移不完整的情况，导致集群无法正确识别分片的归属关系，出现双primary分片。
3. 节点通信故障：升级后可能误改了network.host、discovery.seed_hosts等配置，或防火墙/安全组未开放9300节点通信端口，导致两个节点无法互相发现，形成孤立集群，各自维护独立的分片数据。

强制数据同步步骤 #

注意：操作前务必备份两个节点的索引数据，避免数据丢失！

1. 确认基准数据节点：对比业务数据，确定node1或node2的vehicle_inventory索引数据为正确版本（比如以最新业务数据为准），假设基准节点为node1。
2. 停止非基准节点：停止node2的Elasticsearch服务，示例命令：sudo systemctl stop elasticsearch（根据实际启动方式调整）。
3. 清理非基准节点的异常分片数据：找到node2的ES数据目录（默认路径为/var/lib/elasticsearch/nodes/0/indices/），删除vehicle_inventory索引对应的分片目录（可通过curl http://node2:9200/_cat/indices?v获取索引ID）。
4. 临时调整非基准节点配置：修改node2的elasticsearch.yml，将node.master设为false，避免重启后再次触发脑裂，保存配置后重启node2。
5. 等待数据同步：node2启动后会自动加入node1所在的集群，集群会将node1的primary分片同步副本到node2，可通过curl http://node1:9200/_cat/shards/vehicle_inventory?v查看同步进度。
6. 恢复节点master资格：同步完成后，将node2的node.master改回true，重启node2，确保集群能正常进行master选举。
7. 验证数据一致性：分别执行以下命令验证数据：

   curl http://node1:9200/vehicle_inventory/_doc/109802
   curl http://node2:9200/vehicle_inventory/_doc/109802
   

   确认两个节点返回的retailPrice、promotionList等字段一致。

重点排查内容 #

• 集群脑裂日志：查看两个节点的elasticsearch.log，搜索split brain、master not discovered、cluster state update failed等关键词，确认是否出现集群分裂场景。
• 节点通信状态：执行curl http://node1:9200/_cat/nodes?v和curl http://node2:9200/_cat/nodes?v，检查节点是否能互相识别；验证9300端口的连通性（比如用telnet node1 9300在node2上测试）。
• 升级过程日志：查看升级时的操作日志和ES启动日志，排查是否有元数据迁移失败、分片分配错误的报错信息。
• 集群配置一致性：对比两个节点的elasticsearch.yml，重点检查discovery.seed_hosts、cluster.initial_master_nodes、network.host等配置是否完全一致。
• 分片未分配原因：执行curl http://node1:9200/_cluster/allocation/explain和curl http://node2:9200/_cluster/allocation/explain，获取副本分片UNASSIGNED的具体原因（如磁盘不足、节点属性不匹配等）。
• 数据差异范围：用_count API统计两个节点的索引文档数，用_search API批量对比字段值，确认差异是个别文档还是全索引范围的问题。

内容的提问来源于stack exchange，提问作者Ravi Mitra Reddy