京公网安备11010502063487号真实搭建2节点集群，往0副本索引灌入80万条文档后限流恢复速度并触发副本同步，用_cat/recovery轮询发现文件级拷贝几乎瞬间完成，而translog_ops_percent真实在接下来几秒里从29.4%逐步爬升到82%直至完成，还原了副本同步先文件拷贝、后translog重放的完整流程。
真实搭建3节点1主2副集群，kill掉一个副本节点并继续写入后in_sync_allocation_ids真实从3降到2；意外发现一次性kill掉2/3节点会导致master选举失败、提升卡死在no master，揭示主分片提升依赖合法master的前提；恢复quorum后只kill主分片节点，提升立刻成功且primary_term精确跳一格。
真实搭建3节点集群对比朴素重启和标准滚动重启流程：朴素方式等过node_left.delayed_timeout后ES真实会在空闲节点上重建一整份新副本造成浪费；标准做法重启前设置cluster.routing.allocation.enable=primaries，哪怕等待更久副本也不会被重新分配，节点重新上线后真实能零浪费地续上原来的角色。
本机只有一个8.15.0版本的Elasticsearch，没有条件做跨版本组网测试，改为真实查询节点自报的minimum_wire_compatibility_version(7.17.0)和minimum_index_compatibility_version(7.0.0)，并验证每个索引的version.created版本印记在建索引时和建完后都无法被用户篡改，证明版本兼容检查依赖不可伪造的历史事实。
真实测量集群状态大小和建索引耗时作为基线(26万字节/0.098秒)，连续建300个带25字段mapping的索引后集群状态真实涨到81万字节(3.1倍)，建索引耗时增长约10%-15%，如实记录这个代价在中等规模下不算夸张但会随索引数量持续累积。
真实并发发起150个建索引请求，用_cluster/pending_tasks观察到master任务队列真实堆积到144-154个URGENT任务；在队列繁忙期间额外发起的一个新建索引请求耗时3.89秒，比正常基线0.098秒慢了约40倍，量化了master负载过高对无关请求造成的真实延迟代价。
真实在空闲状态下建立hot_threads的0%基线，用painless脚本制造CPU压力时先撞上Painless自带的语句数上限保护机制，降到10万次循环后6个查询并发执行，负载期间抓到的hot_threads真实捕获到3个search线程跑满102%CPU，调用栈精确指向PainlessScript执行这一行。
真实查到search线程池默认size=16、queue_size=1000且不支持动态更新，改yml压缩到size=1/queue_size=1并重启后，并发20个请求真实18个收到429的es_rejected_execution_exception，thread_pool的rejected计数精确同步显示18，验证了队列满载后快速拒绝而非无限堆积的设计。
真实先在没配置path.repo时注册fs类型snapshot仓库被直接拒绝，加进path.repo白名单重启后注册立刻成功且_verify确认节点能正常访问；用没加进白名单的/tmp/outside-repo路径注册第二个仓库同样被拒绝，证明path.repo是不能靠API调用绕过的硬性限制。
真实往索引灌入27万条文档后做第一次全量快照仓库目录涨到11MB，追加3万条新文档后的第二次快照仓库目录只多涨1MB且几乎瞬间完成，验证了snapshot的真实增量特性；删除第一个快照后仓库大小不变，第二个快照依然完整可用，证明底层段文件被多个快照共享引用。
真实写入2条数据建快照，验证索引存在时直接restore会被拒绝(提示删除索引或改名恢复)；真实删除索引模拟数据丢失并确认404，再执行restore验证恢复出的文档数精确对上2条，且每条文档的_id都跟删除前完全一致，证明restore是原样还原数据而非重新生成。
真实建两个索引一起打进同一份快照后全部删除，验证restore只指定其中一个索引时另一个不受影响依然404；用通配符批量恢复时因一个索引已存在产生冲突导致整批请求全部失败，单独指定索引名才完成完整恢复，揭示批量restore是原子性的整体操作。