|
[parent] Data too large, data for [indices:data/write/bulk[s]] would be [27989754 …
es集群突然抛出这个异常，起初以为是谁的任务有做了超出集群jvm内存限制的操作于是
第一次尝试解决：大家跑着的用到es的任务都停止，查看资料发现大家遇到这个问题都说是fielddata 断路器的问题，于是也做了如下的设置，集群还是会每隔几分钟就有数据节点丢失，发生熔断现象，尝试失败；
PUT /_cluster/settings
{
"persistent": {
"indices.breaker.fielddata.limit": "60%"
}
}
PUT /_cluster/settings
{
"persistent": {
"indices.breaker.request.limit": "40%"
}
}
PUT /_cluster/settings
{
"persistent": {
"indices.breaker.total.limit": "70%"
}
}
第二次尝试解决：给集群加密码（./elasticsearch-setup-passwords interactive），6个用户每次设置到一半的时候就又发生熔断抛出这个异常，这里应该就不是加密码能解决的了；
第三次尝试解决：接下来把三台master节点的虚拟机ip改变，集群各节点elasticsearch.yml中配置也改变连接ip，重启集群各节点后，几分钟后还是会发生节点丢失，熔断的现象，解决失败；
第四次尝试解决：怀疑是es数据量太大了，集群的内存不够用了，于是给每个数据节点的虚拟机扩内存到64g，数据节点的jvm内存调高到32g（这里按照官方文档的说法32g已经是达到建议使用最大堆内存了
）master节点也都调高到16g内存了，此时集群内存扩充了一倍，达到了304gb，配置完成后集群重启，好像没事了，运行了一些任务尝试，短暂使用后还是会报这个错误，但是也能成功的插入一些数据和查询使用了，会有失败现象；
第五次尝试解决：通过查询资料在集群节点中elasticsearch.yml 增加如下配置
indices.fielddata.cache.size: 40% #（有了这个设置，最久未使用（LRU）的 fielddata 会被回收为新数据腾出空间 ），这就是集群发生熔断的主要原因
indices.breaker.total.use_real_memory: false #（默认为true默认值为JVM堆内存的95%，置为false默认值为JVM堆内存的70%），到此集群全部重启，大家陆续启动任务集群也没在报错。
https://blog.csdn.net/weixin_42166515/article/details/89093832?spm=1001.2101.3001.6650.7&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-7-89093832-blog-48035723.pc_relevant_blogantidownloadv1&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-7-89093832-blog-48035723.pc_relevant_blogantidownloadv1&utm_relevant_index=10
https://elasticsearch.cn/question/9933
https://www.jianshu.com/p/f99d8d1904be
|