这是一个创建于 3529 天前的主题，其中的信息可能已经有所发展或是发生改变。
昨天公司内网的机房空调挂掉，温度过高导致机房电力跳闸。刚好我那台虚拟机所在的主机没接UPS，断电挂掉……处理好后重启主机及虚拟机，发现ElasticSearch数据丢失严重，从21-30的index数据不复存在……555
想请教各位，ElasticSearch是将数据先缓存到内存中再延迟写入的吗？貌似这也不是丢失的原因，寻求各位帮忙解答
PS:
1. 机器在21-30都没有重启过，ElasticSearch也没有stop过，一直是startup状态
2. 有启用marvel，为了使用sense调试DSL
想请教各位，ElasticSearch是将数据先缓存到内存中再延迟写入的吗？貌似这也不是丢失的原因，寻求各位帮忙解答
PS:
1. 机器在21-30都没有重启过，ElasticSearch也没有stop过，一直是startup状态
2. 有启用marvel，为了使用sense调试DSL
 |
1
suriv520 2015-04-01 15:46:28 +08:00
准确地说，应该不是不存在了……默认情况下ES会非常频繁地把新数据写入硬盘并索引。你用head plugin看看ES的各个shard还有没有，是不是shard数据不完整还在recovery？
另，有没有做cluster？数据量多大？这些都会影响ES index的rebuilding。 PS， 稳定度上，一台机器跑ES还是比较靠谱的。两三台机器，最好别跑实时高负载同时indexing与searching的ES，基本上一个node崩，再加上rebalance与auto resharding，其它的node也就雪崩了。如果有个6-10台机器，差不多可以勉强感受到集群高可用特征了。 如果一天没有几百G的数据，ES压力不大，还是比较靠谱的。 |
|
2
suriv520 2015-04-01 15:51:22 +08:00
P.S. 如果是存log数据，且数据规模远远超过jvm的内存大小，ES在复杂查询上的效率比较不乐观。比如，5个node，每个node 20G RAM，16core CPU的cluster，每天产生100G数据，查询7天的数据，做个简单的聚合，查询时间基本上在5s-20s，这个效率是没法拿到生产线上给客户操的。
|
 |
3
Yuansir 2015-04-01 16:02:21 +08:00
看来 snapshot 还是蛮有必要的
|
Select Language