共计 1281 个字符，预计需要花费 4 分钟才能阅读完成。
前言
Elasticsearch 在解决文档变更的时候，首先会把变更记录在索引缓冲区里，而后每隔 1s 将索引缓冲区刷新到文件系统缓存，存在于文件系统缓存中的变更会定时 fsync 到磁盘，文档变更长久化到了硬盘才算不会失落了。
在未长久化到磁盘之前如果产生了意外状况可能会导致数据失落，比方：Elasticsearch 宕机（索引缓冲区未刷新的变更会失落），机房断电导致操作系统重启（文件系统缓存中的变更会失落）。
事务日志
简介 & 作用
Elasticsearch 在数据的变更提交过程中减少了事务日志（Translog），采纳追加写的形式。事务日志是磁盘上一块区域内的程序 I /O，防止了随机 I/O 须要在磁盘的多个中央挪动磁头，事务日志的形式相对来说要快很多。
一个文档被索引后，会增加到内存缓冲区，同时记录到事务日志。
内存缓冲区 refresh 后，事务日志不清空。
Elasticsearch 索引的每个分片都存在一个事务日志，事务日志记录实现后才会给客户端返回胜利。这就意味着，只有客户端接到胜利响应，文档的变更就曾经长久化到磁盘了，体现在事务日志里。
事务日志提供所有还没有被刷到磁盘的操作的一个长久化纪录。当 Elasticsearch 启动的时候，它会从磁盘中应用 最初一个提交点（Commit point）去复原已知的段，并且会重放 Translog 中所有在最初一次提交后产生的变更操作。
安全性
在文档变更被 fsync（fsync 指的是长久化文档变更到事务日志）到磁盘前，变更的文档在重启之后就会失落。默认 Translog 是每 5s 被 fsync 刷新到硬盘，或者在每次写申请实现之后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会产生。最终，这意味着在整个申请被 fsync 到主分片和复制分片的 Translog 之前，客户端不会失去一个 200 OK 响应。
在每次申请后都执行一个 fsync 会带来一些性能损失，只管实际表明这种损失绝对较小（特地是 bulk 导入，它在一次申请中平摊了大量文档的开销）。
然而对于一些大容量的偶然失落几秒数据问题也并不重大的集群，应用异步的 fsync 还是比拟无益的。比方，写入的数据被缓存到内存中，再每 5s 执行一次 fsync。这个行为能够通过设置 durability 参数为 async 来启用：
PUT /my_index/_settings
{
"index.translog.durability": "async",
"index.translog.sync_interval": "5s"
}这个选项能够针对索引独自设置，并且能够动静进行批改。如果决定应用异步 Translog 的话，就须要能承受在产生 crash 时，失落掉 sync_interval 时间段的数据也无所谓。
总结
事务日志提供了一种长久化保障，意外状况可能会产生，期间数据可能会失落，然而可能从事务日志中进行复原其实曾经几近做到了数据不失落。大多数分布式应用中，分区数据一致性保障，数据不失落保障采纳的解决方案也都如此。
参考
https://www.elastic.co/guide/…
