一次重启引发的恐慌
写入调优完，老王开始折腾运维：把三节点集群的一台机器滚动重启。重启过程中他盯着监控手心冒汗——搜索正常、写入正常，但集群状态灯从 green 变 yellow，过了一会儿才绿回来。搜了半天「集群挂了怎么办」，他先得搞懂集群里每个节点都在干什么。这篇补上集群运维的地基。
节点角色：管家、工人与前台
ES 节点按角色分三种人格，默认情况下一个节点三人格合一：
| 角色 | 干什么 | 类比 |
|---|---|---|
| master | 集群管理：建删索引、分配分片、维护集群状态 | 管家，不搬数据只做决策 |
| data | 存数据、执行写入检索聚合 | 真正干活的工人 |
| coordinating | 接收请求、分发、归并结果 | 前台，每个节点都兼任 |
小集群三种人格合一没毛病；集群大了（几十节点、上百索引）就要拆：专用 master 节点不存数据，专职稳定；data 节点专心吞吐。老王的三节点暂时不用拆，但记一条进阶规矩：master 节点压力一大，整个集群的操作（建索引、分片迁移）都会卡——这就是大规模集群拆角色的原因。还有 ingest 角色负责写入前的管道预处理，用得少，知道即可。
主选举：多数派说了算
master 不是指定的，是选出来的。所有 master-eligible 节点互相投票，获得多数派（quorum）同意的当选。三个 master-eligible 节点，选举要两张票。为什么必须多数派？设想两台机房网络断了：少数派这边凑不齐票，选不出 master，安静待机；多数派那边照常选出 master 继续服务。全集群永远只有一个 master，数据不会因为脑裂写成两套。
这就是 ES 的脑裂防线。老版本要手动配 minimum_master_nodes，配错就可能真裂成两个集群各写各的，合并时数据打架；新版本投票机制内建，少数派自动退出服务，宁可不服务，不可乱服务。运维要做的只有一件事：master-eligible 节点数保持奇数（三或五），永远不要偶数——两张票的集群挂一台，剩两台凑不出多数派，集群直接不可用。
回到老王的重启事件：他重启的那台恰好不是 master，于是只是分片重新分布，副本暂时少放了一个（yellow），master 把分片挪稳后恢复 green。整个过程中写入走主分片照常、查询走剩余副本照常——滚动重启不宕机的底气，就是第 3 篇的副本机制。
三色灯的自检逻辑
第 3 篇见过三色灯，现在能讲透它的判断规则了。GET _cluster/health 返回的 status：
| 颜色 | 含义 | 第一动作 |
|---|---|---|
| green | 主副分片全部就位 | 正常，该干嘛干嘛 |
| yellow | 主分片齐，部分副本没地方放 | 查节点数是否小于副本数、磁盘水位 |
| red | 有主分片丢失，数据不可写不可查 | 真故障，立刻查节点与磁盘 |
yellow 最常见的原因就两个：单节点集群配了副本数大于零（副本没处放），或磁盘使用超过水位线（ES 默认 85% 起就不让副本上座）。red 则往往伴随节点离线，GET _cat/shards 能直接看到哪些分片 UNASSIGNED。老王把 _cat 系列接口存成了书签：_cat/nodes 看节点、_cat/shards 看分片分布、_cat/indices 看索引大小，集群体检三件套。
小结
集群一句话：master 是选出来的管家，多数派投票防脑裂，eligible 节点保持奇数，data 干活协调接待，三色灯是集群的自检日报。副本不只是读扩展，更是滚动运维的门票。
集群稳了，但老王建索引时随手写的 number_of_shards: 5 开始露出獠牙：小分片一堆，内存吃紧查询还慢。下一篇讲分片规划：建索引时定死的那道数学题怎么算。
评论 (0)