一、持久化变更的概述

• 没有用 fsync 把数据从文件系统缓存刷（flush）到硬盘，我们不能保证数据在断电甚至是程序正常退出之后依然存在。
• 为了保证 Elasticsearch 的可靠性，需要确保数据变化被持久化到磁盘。
• 动态更新索引（即：一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点）。
• Elasticsearch 在启动或重新打开一个索引的过程中使用这个提交点（即：一个列出了所有已知段的文件）来判断哪些段隶属于当前分片。

二、事务日志（translog）

• 即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确保能从失败中恢复。
• 在两次提交之间发生变化的文档怎么办？我们也不希望丢失掉这些数据。Elasticsearch 增加了一个 translog（即：事务日志），在每一次对 Elasticsearch 进行操作时均进行了日志记录。

三、持久化变更完整流程

• 一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了 translog。
  

• 使分片每秒被刷新（refresh）一次。

  （1）、这些在内存缓冲区的文档被写入到一个新的段中，且没有进行 fsync 操作。
  （2）、这个段被打开，使其可被搜索。
  （3）、内存缓冲区被清空。

  

• 当前进程继续工作，更多的文档被添加到内存缓冲区和追加到事务日志。
  

• 每隔一段时间（例如 translog 变得越来越大）索引被刷新（flush）；一个新的 translog
  被创建，并且一个全量提交被执行。

  所有在内存缓冲区的文档都被写入一个新的段。
  缓冲区被清空。
  一个提交点被写入硬盘。
  文件系统缓存通过 fsync 被刷新（flush）。
  老的 translog 被删除。

  

四、事务日志（translog）的作用

• 事务日志（translog）提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时候， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。
• 事务日志（translog）也被用来提供实时 CRUD 。当你试着通过 ID 查询、更新、删除一个文档，它会在尝试从相应的段中检索之前， 首先检查 translog 任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。

五、事务日志（translog）的目的

• 保证操作不会丢失（即：在文件被 fsync 到磁盘前，被写入的文件在重启之后就会丢失）。
• 默认 translog 是每 5 秒被 fsync 刷新到硬盘， 或者在每次写请求完成之后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。这意味着在整个请求被 fsync 到主分片和复制分片的 translog 之前，你的客户端不会得到一个 状态码为200的OK 响应。