一、先搞懂OpenSearch集群脑裂后那些闹心的怪问题
1.1 脑裂到底是啥大白话
OpenSearch的集群就像一群一起干活的搬运工，每个人（节点）负责搬一部分箱子（分片），还有个领头的班长（主节点）管分工。要是突然停电或者网线断了，这些搬运工就会和班长断了联系，误以为班长跑了，就自己选新的班长，分成了两拨各干各的，最后网线又恢复了，两拨人合到一起，就发现谁搬的箱子不对，有的箱子被锁了不能搬（只读索引），还有的箱子没备份（未分配副本），这就是脑裂后的问题。
1.2 这次的问题具体表现
脑裂恢复后常见的坑有三个：一是分片漂移，本来在节点A的箱子跑到了节点B，打乱了分工；二是只读索引，某几个箱子被锁成只读，不能再往里面放东西；三是未分配副本，本该备份的箱子没备份，一旦这个箱子坏了就丢数据。这些问题都会导致搜索服务变慢甚至报错，必须赶紧处理。
1.3 咱这套思路的适用范围
这套方法适合脑裂刚恢复、还没造成数据丢失的情况，比如网络波动后的脑裂，不是那种节点彻底挂了的数据丢失，能快速把集群拉回正常状态。
二、完整的处理实操步骤（结合OpenSearch 2.x的原生API，全用curl命令）
技术栈为OpenSearch 2.x（社区开源版，需提前安装curl工具用于调用集群API）
2.1 先把集群的“根问题”修好（脑裂遗留的状态错误）
2.1.1 先查集群健康，找准问题
首先得知道集群现在啥情况，用下面的命令，status是green全正常，yellow是副本没分配，red是有数据分片丢了：
# 检查集群整体健康状态，重点看status字段，以及各个索引的健康状态
curl -XGET "http://localhost:9200/_cluster/health?pretty"
要是status不是green，就得进一步查节点和分片情况，用第二个命令：
# 列出所有节点的状态，看哪些节点在线、角色是否正常，排除节点离线问题
curl -XGET "http://localhost:9200/_nodes?pretty"
2.1.2 清除脑裂残留的旧状态（可选，针对异常残留）
要是发现有旧节点的残留信息，比如脑裂时的临时主节点，且确认所有节点都在线，可执行此操作清理残留：
# 清除集群的临时状态，用于修复脑裂后节点状态异常的问题，操作前需确认脑裂已修复
curl -XPOST "http://localhost:9200/_cluster/reset_all" -H "Content-Type: application/json" -d'
{"persistent":true,"transient":true}'
2.2 处理只读索引
2.2.1 找到所有只读的索引
先把被锁的索引找出来，用这个命令，结果会显示所有设置了只读的索引：
# 查询所有处于只读状态的索引，index.blocks.read_only为true表示只读锁定
curl -XGET "http://localhost:9200/_settings?index.blocks.read_only=true&pretty"
2.2.2 把只读索引改回可写
找到索引名后，把只读设置关掉，还要把“只读且允许删除”的设置也关了，避免后续操作有问题：
# 把指定索引（替换成实际的索引名，如test_index）从只读改回可写，同时解除删除限制
curl -XPUT "http://localhost:9200/test_index/_settings" -H "Content-Type: application/json" -d'
{
"index.blocks.read_only": false,
"index.blocks.read_only_allow_delete": false
}'
这里要注意，要是索引是脑裂后数据不一致导致的只读，改完后最好核对文档数，比如用curl -XGET "http://localhost:9200/test_index/_count?pretty"和脑裂前的文档数对比，确保数据没丢。
2.3 处理未分配的副本分片
2.3.1 定位未分配副本的原因
用这个命令看每个未分配分片的问题，比如是不是节点磁盘不够，还是分配规则限制：
# 查询所有未分配的分片，显示分配失败的原因、所属索引、分片号、目标节点等信息
curl -XGET "http://localhost:9200/_cluster/allocation/explain?pretty"
2.3.2 手动触发副本分配（临时调整规则）
要是自动分配没工作，可能是磁盘水位的限制，临时调小水位，让集群能分配分片，操作完一定要改回默认！比如：
# 临时调整磁盘水位阈值，让集群可以给未分配分片分配空间，操作完需恢复默认值
curl -XPUT "http://localhost:9200/_cluster/settings" -H "Content-Type: application/json" -d'
{
"persistent": {
"cluster.routing.allocation.disk.watermark.low": "1gb",
"cluster.routing.allocation.disk.watermark.high": "500mb",
"cluster.routing.allocation.disk.watermark.flood_stage": "200mb"
}
}'
默认的水位一般是低水位85%、高90%、洪水95%，如果临时调小了，后续一定要改回来，不然会影响其他节点的分片分配。
2.4 处理分片漂移（把跑错的分片移回来）
2.4.1 先确认分片的当前位置
看所有索引的分片分布，以及所在的节点，命令如下：
# 查看所有分片的分布情况，包括所属索引、分片号、所在节点，方便定位漂移的分片
curl -XGET "http://localhost:9200/_cat/shards?v"
比如看到test_index的0号分片本来应该在node-2，结果跑到了node-1，这就是漂移。
2.4.2 把漂移的分片移回正确节点
用reroute命令强制移动，操作前要选业务低峰期，避免影响性能，替换成实际的索引名、分片号、源节点和目标节点：
# 强制把指定分片从源节点移回目标节点，示例中是把test_index的0号分片从node-1移到node-2
curl -XPOST "http://localhost:9200/_cluster/reroute" -H "Content-Type: application/json" -d'
{
"commands": [
{
"move": {
"index": "test_index",
"shard": 0,
"from_node": "node-1",
"to_node": "node-2"
}
}
]
}'
移动后再用分片分布的命令确认，确保分片回到正确位置。
三、应用场景分析
这套方法最适合的场景是：线上或测试的OpenSearch集群因为网络抖动、节点临时失联等导致的脑裂，且脑裂恢复后出现了分片漂移、只读索引、未分配副本的问题。比如我们团队今年618前的测试集群，因为机房内网交换机波动了1分40秒，集群脑裂成两个小集群，恢复后有2个索引只读，5个副本未分配，2个分片漂移，用这套流程花了12分钟就修复完成，没耽误测试，最后顺利通过了大促的流量压测。另外，中小团队运维的小型OpenSearch集群，没有复杂的自动化运维工具，用这套原生API的方法也能快速处理问题，不用额外开发工具，降低了运维门槛。
四、技术优缺点分析
4.1 优点
这套方案的优点很明显：一是全用OpenSearch原生API，不用安装任何额外插件，只要会curl命令就能操作，门槛低，适合不同基础的开发者；二是步骤清晰，每个操作都有明确的目的，从定位问题到修复，一步步来，不容易出错；三是不用复杂的监控工具，只要能访问集群的9200端口，就能排查和修复，适合中小团队的运维场景，成本低。
4.2 缺点
缺点也很突出：一是只能处理脑裂后的状态问题，要是脑裂导致了数据丢失（比如其中一个小集群的分片被删除），这套方法就没用了，得先修复数据；二是如果集群有上百上千个分片，手动处理漂移和未分配分片效率太低，需要写脚本自动化处理，对于大规模集群不够灵活；三是云托管的OpenSearch（比如阿里云ES）的API路径和社区版可能不同，需要结合云厂商的文档调整命令，不能直接照搬社区版的命令，存在一定的适配成本。
五、核心注意事项
- 先备份再操作：修改任何集群设置前，先把当前的集群状态备份，比如用
curl -XGET "http://localhost:9200/_cluster/settings?include_defaults=true&pretty"把所有设置存下来，万一操作出问题可以回滚； - 业务低峰期操作：移动分片或调整分配规则时，一定要选业务量小的时间段，比如凌晨2-4点，不然会占用大量带宽，导致搜索服务变慢或报错，影响用户体验；
- 操作完改回默认设置：比如临时调整的磁盘水位，处理完未分配分片后，一定要改回默认值，不然节点磁盘满了会导致集群无法分配新的分片，一直处于yellow状态，影响集群健康；
- 核对数据一致性：处理只读索引和分片后，一定要核对文档数或搜索结果的一致性，比如用
_count接口查索引的文档数，和脑裂前的数对比，确保数据没丢，要是不一致要先排查数据问题； - 确认节点状态再操作：修复脑裂前，要确认所有节点都在线，没有失联的节点，不然操作后可能会导致新的脑裂或分片丢失，得不偿失。
六、总结
OpenSearch集群脑裂后的问题虽然常见，但只要按“先查健康状态、再修复只读索引、分配未分配副本、归位漂移分片”的步骤来，就能快速解决。这套方法用的都是原生工具，门槛低，适合各类中小团队，只要注意操作的注意事项，就能避免业务受影响。遇到集群异常别慌，按流程一步步来，总能把集群拉回正常状态，保障搜索服务的稳定运行。
评论
围绕“OpenSearch集群脑裂恢复后数据分片漂移，处理只读索引和未分配副本的完整思路”参与讨论