案例中的配置有问题，es那块儿设置6和7都不对

根据您提及的问题，似乎是关于Elasticsearch集群配置中某些设置不正确的情况，特别是与shard相关的配置。为了提供针对性的帮助，请允许我基于参考资料分析并给出建议。

问题理解

您指出案例中的Elasticsearch配置存在问题，特别指出了设置6和7的不妥之处，但未具体说明是哪两个设置。不过，从上下文推测，这可能与shard分配或数量设定有关。

可能的误解或错误

• 设置6和7的假设解读：如果我们将“设置6和7”理解为文档中提到的配置调整部分，那么可能的误解在于如何合理设置shard的数量以及处理分片不均的方法。

正确做法参考

1. Shard数量规划：

   • 确保主shard数与副shard数之和是集群数据节点的整数倍，这是为了避免负载不均。例如，如果有9个数据节点，可以考虑将索引的总shard数（主+副）设计为9的倍数，以实现均衡分布。

2. 解决分片不均：

   • 如果发现分片分配不均导致某些节点负载过高，应该重新评估并调整shard分配。使用如GET _cat/shards?v命令来检查当前shard分布，并通过重新索引或使用_cluster/reroute API手动调整shard位置，以达到更均衡的状态。

3. 避免常见误区：

   • 不要盲目增加shard数量以追求高并发，过多的shard会增加管理开销，降低查询效率。
   • 在进行任何大规模的shard调整前，确保有完整的备份策略，以防操作失误导致数据丢失。

实施步骤

1. 评估现状：首先，使用Elasticsearch提供的API检查当前集群的shard分布情况。
2. 规划调整：基于现有节点数，计算合理的shard总数，确保能够均匀分配。
3. 执行调整：通过重新索引或API调用来重新分配shard，必要时可创建新索引来迁移数据。
4. 监控效果：调整后密切监控集群性能，确保负载均衡且服务稳定。

注意事项

• 性能影响：在调整shard过程中，可能会暂时影响集群性能，选择业务低峰期操作。
• 资源评估：调整前应评估硬件资源是否足以支持新的shard布局，必要时升级实例规格。

请根据您的具体情况参照上述建议进行调整，如有更具体的配置细节或遇到特定问题，欢迎进一步咨询。