持久化变更

没用fsync同步文件系统缓存到磁盘，我们不能确保电源失效，甚至正常退出应用后，数据的安全。为了ES的可靠性，需要确保变更持久化到磁盘。

我们说过一次全提交同步段到磁盘，写提交点，这会列出所有的已知的段。在重启，或重新打开索引时，ES使用这次提交点决定哪些段属于当前的分片。

当我们通过每秒的刷新获得近实时的搜索，我们依然需要定时地执行全提交确保能从失败中恢复。但是提交之间的文档怎么办？我们也不想丢失它们。

ES增加了事务日志（translog），来记录每次操作。有了事务日志，过程现在如下：

1. 当一个文档被索引，它被加入到内存缓存，同时加到事务日志。

   图1：新的文档加入到内存缓存，同时写入事务日志

2. refresh使得分片的进入如下图描述的状态。每秒分片都进行refeash：

• 内存缓冲区的文档写入到段中，但没有fsync。

• 段被打开，使得新的文档可以搜索。

• 缓存被清除

  图2：经过一次refresh，缓存被清除，但事务日志没有

3. 随着更多的文档加入到缓存区，写入日志，这个过程会继续

图3：事务日志会记录增长的文档

4. 不时地，比如日志很大了，新的日志会创建，会进行一次全提交：

• 内存缓存区的所有文档会写入到新段中。

• 清除缓存

• 一个提交点写入硬盘

• 文件系统缓存通过fsync操作flush到硬盘

• 事务日志被清除

  事务日志记录了没有flush到硬盘的所有操作。当故障重启后，ES会用最近一次提交点从硬盘恢复所有已知的段，并且从日志里恢复所有的操作。

事务日志还用来提供实时的CRUD操作。当你尝试用ID进行CRUD时，它在检索相关段内的文档前会首先检查日志最新的改动。这意味着ES可以实时地获取文档的最新版本。

图4：flush过后，段被全提交，事务日志清除

flush API

在ES中，进行一次提交并删除事务日志的操作叫做 flush。分片每30分钟，或事务日志过大会进行一次flush操作。

flush API可用来进行一次手动flush：

POST /blogs/_flush <1> 

POST /_flush?wait_for_ongoing  <2>
copy

• <1> flush索引blogs

• <2> flush所有索引，等待操作结束再返回

  你很少需要手动flush，通常自动的就够了。

当你要重启或关闭一个索引，flush该索引是很有用的。当ES尝试恢复或者重新打开一个索引时，它必须重放所有事务日志中的操作，所以日志越小，恢复速度越快。