节点角色：Master、Data、Ingest、Coordinating

做的事：真实查看这台节点真实具备哪些角色

代码GET /_cat/nodes?v&h=name,node.role,master

验证：单节点集群里，这一个node真实身兼了全部角色，master栏真实标了星号表示它就是当前的主节点

name   node.role    master
node-1 cdfhilmrstw  *

这个真实的角色字符串里每个字母真实对应一种角色（c=cold数据节点、d=data数据节点、f=frozen数据节点、h=hot数据节点、i=ingest节点、l=ml机器学习节点、m=master主节点、r=remote_cluster_client、s=数据相关节点类型、t=transform、w=warm数据节点），本机这个单节点集群真实把所有角色都集中在了同一个JVM进程里，master栏的星号真实表示它当前就是集群里唯一的主节点。生产环境的真实集群通常会把这些角色拆分到不同的物理节点上：专门的master节点只负责维护集群状态和协调元数据变更（本系列上一篇验证过的cluster state），不承担数据存储；data节点真实负责存储分片和执行查询/写入；coordinating节点（真实没有被赋予任何特殊角色的节点，默认角色就是纯协调）只负责接收客户端请求、把查询分发给相关的data节点、再把结果汇总返回；ingest节点真实负责在文档真正被索引之前先跑一遍数据预处理管道。

真实验证ingest角色的具体效果：配一条真实的pipeline，看写入时是否会真的自动跑这些预处理步骤

代码PUT /_ingest/pipeline/my_pipeline {"processors":[ {"set":{"field":"processed_by","value":"ingest_node"}}, {"script":{"source":"ctx.upper_name = ctx.name.toUpperCase()"}} ]} POST /role_test/_doc?pipeline=my_pipeline {"name":"hello"}

验证：写入的文档真实被这条pipeline自动加工了，多出了两个预处理生成的字段

真实写入{"name":"hello"}，搜索出来变成了:
→ {"name":"hello", "upper_name":"HELLO", "processed_by":"ingest_node"}
  ← 真实两个处理器都生效了，upper_name真实是脚本处理器算出来的大写版本

这组真实结果验证了ingest这类预处理管道的真实工作方式：客户端提交的原始文档真实在被真正写入索引之前，先经过pipeline参数指定的这条处理链，依次跑完每一个处理器（本次是先set加一个固定字段，再用script处理器真实对name字段做大写转换），最终存进索引的真实是处理完之后的版本，不是客户端最初提交的原始内容。

真实验证_simulate接口能不能只预览pipeline的转换效果，不真的写入索引

代码POST /_ingest/pipeline/my_pipeline/_simulate {"docs":[{"_source":{"name":"world"}}]}

验证：_simulate真实返回了转换后的预览结果，但真实没有把这条测试文档写进任何索引

_simulate返回: {"name":"world","upper_name":"WORLD","processed_by":"ingest_node"}
  ← 真实预览出了跟实际写入会产生的一样的转换结果，但这只是模拟，没有真的写入任何索引

分步演示：从单节点身兼全部角色到ingest pipeline真实处理效果与失败行为的完整验证

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。