自托管Elasticsearch数据丢失原因排查请求（AWS免费服务器）

根据你描述的情况——在AWS免费层服务器同时部署自托管Elasticsearch和RabbitMQ，代码集成后运行一段时间出现旧索引数据丢失但新数据能正常存入的问题，结合你提到的内存不足线索，我整理了几个最可能的原因和排查方向：

1. 内存不足触发ES的自我保护机制 #

AWS免费层的服务器（比如t2.micro）通常只有1GB左右的物理内存，而Elasticsearch官方推荐至少分配2GB堆内存给JVM。当内存严重不足时：

• ES会触发内存压力保护机制，可能自动清理旧分片、甚至删除旧索引来释放内存——如果你的索引设置了TTL（自动过期）或者开启了索引生命周期管理（ILM）的滚动/删除策略，内存不足会加速这个清理过程。
• 频繁的JVM GC（垃圾回收）甚至OOM（内存溢出）会导致ES进程崩溃重启，重启后如果分片分配失败，旧数据所在的分片会被标记为未分配，无法被查询到，看起来就像数据被删除了。
• 重点查看ES日志中是否有low disk watermark exceeded、JVM memory pressure或者OutOfMemoryError这类关键词，这是资源不足的典型信号。

2. 与RabbitMQ的资源竞争导致进程异常 #

同一台服务器上同时运行ES和RabbitMQ，两者都是内存大户：

• RabbitMQ的Erlang虚拟机同样需要大量内存，当两者内存占用叠加后，服务器的系统内存会被耗尽，Linux的OOM Killer会自动杀死占用内存最多的进程（大概率是ES）。ES进程被强制终止后，重启时如果分片没有完全恢复，就会出现旧数据丢失的情况。
• 可以检查系统日志（比如/var/log/syslog或/var/log/messages），看是否有Out of memory: Killed process的记录，确认ES进程是否被终止过。

3. 索引配置或代码逻辑的隐性问题 #

即使代码集成完成，也不能排除配置或逻辑上的疏漏：

• 检查索引是否设置了错误的索引生命周期策略，比如自动删除旧索引、滚动索引时未保留历史数据。可以通过ES的API查询：GET _ilm/policy。
• 排查代码中是否存在误删除操作，比如异常分支中误调用了DELETE /<index>或者_delete_by_query接口，这类操作会直接清除旧数据。
• 确认分片配置是否合理，比如开启了auto_expand_replicas但服务器资源不足，导致分片无法正常分配，旧数据所在分片无法被访问，看起来像是丢失了。

4. AWS免费层的存储限额触发数据清理 #

AWS免费层的EBS存储通常有额度限制（比如30GB），当ES的索引数据占用超过限额后，EBS会进入只读模式：

• ES无法写入旧数据的更新，甚至会自动清理旧数据来释放存储空间；而新数据可能暂时存在内存中，看起来能正常存入，但服务器重启后这部分数据也会丢失。

快速排查步骤 #

1. 先查看ES的核心日志，定位内存、磁盘、分片分配相关的报错，这是找到根因的关键。
2. 用ES的API查看索引状态：GET _cat/indices?v，确认是否有索引被删除、分片未分配的情况。
3. 检查JVM内存使用情况：GET _nodes/jvm，看堆内存是否处于严重不足的状态。
4. 查看AWS CloudWatch的服务器监控数据，看内存、CPU、磁盘使用率在数据丢失前是否出现过峰值。

内容的提问来源于stack exchange，提问作者Tharunkumar