一文详解Elasticsearch数据写入流程与防丢失配置

一文详解Elasticsearch数据写入流程与防丢失配置

在使用Elasticsearch时，数据丢失是一个常见的担忧。本文将深入探讨Elasticsearch的数据写入流程，解释数据丢失的本质，并提供确保数据安全性的配置建议。

丢失数据的本质

在讨论如何防止数据丢失之前，我们首先需要明确什么是数据丢失。如果你向Elasticsearch写入数据时收到写入错误的响应，这并不算数据丢失。真正的数据丢失是指Elasticsearch返回写入成功，但后续由于节点重启或宕机等原因导致数据消失的情况。

数据写入流程

Elasticsearch的数据写入过程可以分为以下几个步骤：

1. 写入内存缓存：数据首先会被写入一个名为index buffer的内存缓存中。此时数据是不可见的，只有经过refresh操作后，数据才能变得可见。可以通过以下请求设置index buffer的大小：

   PUT /_cluster/settings
   {
       "persistent" : {
           "indices.memory.index_buffer_size" : "30%"  
       }
   }
   

2. 写入事务日志：在写入index buffer成功后，会写translog记录写入的数据。此时数据依然不可见。由于操作系统对文件写入，并不会立即落盘。所以ES提供了关于刷盘的配置，index.translog.durability两个选项值，如下，

• request会在每次创建segment写入数据后就对translog进行刷盘操作。
• async则会定时对translog进行刷盘操作。定时刷新到磁盘的周期是通过index.translog.sync_interval参数去进行控制，默认是5s。

3. 刷新操作：refresh操作可以主动触发也可以定时触发，默认是1s会进行一次， 该操作会创建一个lucece的segment段用于存储新写入到index buffer中的数据，注意这里即使写入到了segment里，数据还是在os Cache系统文件系统缓存中，并没有落入磁盘，只有 在lucece将数据 commit 到磁盘后，数据才能落盘。

4. 数据落盘：在文件系统缓存中的segment最终需要写入磁盘。默认情况下，每30分钟或当translog的日志量达到某个阈值时，segment会进行落盘，同时删除translog日志。这个阈值由index.translog.flush_threshold_size控制，默认是512MB。

防止数据丢失的策略

通过理解上述写入流程，我们可以发现，如果将index.translog.durability设置为request，这样便能让每次请求返回客户端成功时，保证一定会有translog日志存储到磁盘上，后续如果在系统缓存中的segment因为系统宕机而没有落盘依然能够通过translog去进行恢复。而如果index.translog.durability设置为async则有可能会丢失5s的数据。