1:什么是TransLog
对Lucene的更改只在Lucene提交期间持久化到磁盘，这是一个相对昂贵的操作，因此不能在每次索引或删除操作之后执行。当进程退出或硬件故障时，Lucene将从索引中删除一次提交之后和另一次提交之前发生的更改（也就是说当你删除或者添加数据的时候集群出现故障，那么es不会保存这部数据，这些数据包括你的执行命令都被存储在了translog文件中，这是一个磁盘文件，以此来维护数据的安全性）。
由于Lucene提交的开销太大，无法对每个单独的更改执行，所以每个碎片复制都有一个事务日志，称为与其关联的translog。所有索引和删除操作都是在被内部Lucene索引处理之后(但在它们被确认之前)写入translog的。在发生崩溃的情况下，当（重启后）碎片恢复时，可以从translog中恢复最近已确认但尚未包含在上一次Lucene提交中的事务（数据都在translog不在倒排索引中）。
Elastiscseach的flush就是一个执行luence commit和新建一个translog的操作(意思是：flush操作被luence确认数据已经落入到luence倒排索引磁盘文件中，已经不在内存中了，安全了。translog中对这部分数据的记录已经没有用了，可以删除旧的translog新建一个新的准备迎接新的数据了)。flush在后台自动执行，以确保translog不会增长得太大。（数据最终要存储到集群中的磁盘文件里的，不可能一直在translog中，因此flush默认是：内存数据达到10%内存空间，或者是半个小时 旧将内存的数据flush到磁盘，同时清空对应的translog文件内容），因此集群启动的时候若是在崩溃之前你在大批量的录数据的话，恢复重启的时候最周一次flush之后的一批没有被flush的数据都在tranlog中，恢复起来可能需要一些时间。
2：Translog设置
操作磁盘是昂贵的操作，默认情况下我们每一个操作到集群的时候是先写到translog disk中的，如果你操作比较频繁，每次都写translog会有一定的性能问题。如此一来，我们只要了解到Translog写入磁盘translog文件的机制就可以做一些优化。官网原话：The data in the translog is only persisted to disk when the translog is fsynced and committed ，这句话的意思是translog只有在同步并且被提交之后才会从内存中落入到磁盘translog文件中。（给小白：任何的I/O操作刚开始都是在内存里的，然后再到磁盘）。既然translog策略就是 fsynced and committed那么接着看。 In the event of hardware failure, any data written since the previous translog commit will be lost.（这句话：在发生硬件故障时，那些还在内存里还没被写入磁盘translog文件中的数据将会丢失。）
2.1看官网：
By default, Elasticsearch fsyncs and commits the translog every 5 seconds if index.translog.durability is set to async or if set to request (default) at the end of every index, delete, update, or bulk request. More precisely, if set to request, Elasticsearch will only report success of an index, delete, update, or bulk request to the client after the translog has been successfully fsynced and committed on the primary and on every allocated replica.（默认情况下：如果 index.translog.durability：request 的话就是每一次请求写一次translog disk文件,如果index.translog.durability：fsync 就是间隔5s之后写一次translog disk文件如果集群故障这5s内存中的数据就会丢失。）
The following dynamically updatable per-index settings control the behaviour of the translog:
index.translog.sync_interval
How often the translog is fsynced to disk and committed, regardless of write operations. Defaults to 5s. Values less than 100ms are not allowed.
index.translog.durability
Whether or not to fsync and commit the translog after every index, delete, update, or bulk request. This setting accepts the following parameters:
request
(default) fsync and commit after every request. In the event of hardware failure, all acknowledged writes will already have been committed to disk.
async
fsync and commit in the background every sync_interval. In the event of hardware failure, all acknowledged writes since the last automatic commit will be discarded.