对 Lucene 的更改只在 Lucene commit 期间持久化到磁盘，这是一个相当昂贵的操作，因此不能在每次索引或删除操作之后执行。在进程退出或硬件故障的情况下，Lucene 还没来得及 commit 的数据将会丢失。
由于 Lucene commit 的代价太高，无法对每个单独的更改执行，为了避免数据丢失，每个 shard 副本还具有一个事务日志，称为与其关联的 translog 。所有的索引（index）和删除操作在被内部 Lucene 索引处理之后但在它们被确认（ack）之前被写入 translog 。在崩溃的情况下，当 shard 恢复时，可以从 translog 中恢复最近的事务，这些事务已被确认，但尚未包括在最后一次 Lucene commit 中。
Elasticsearch flush 是执行 Lucene comiit 并启动新的 translog 的过程。flush 是在后台自动执行的，以确保 translog 不会增长得太大，避免在恢复过程中重放其操作花费太多的时间， translog 文件达到 index.translog.flush_threshold_size（默认是512mb）就会执行一次 flush。
translog 只有当被 fsync 和 commit 的时候，才会持久化到磁盘，所以在发生故障时，还没写到磁盘的操作数据将会丢失。
translog 为顺序写，所以速度很快。
translog 有两种写入方式：
- （默认方式）index.translog.durability =
request，Elasticcsearch 只会在 translog 在 primary shard 和 每个 replica shard 上成功被 fsync 和 commit 之后，才会对 index，delete，update，bulk 请求返回确认，所以所有被确认的请求都已经持久化到磁盘了。 - index.translog.durability =
async，后台每 index.translog.sync_interval （默认5秒）会执行一次 fsync 和 commit，由于是异步的，所以在发生故障时，还没 commit 的操作将会丢失，但是性能肯定会更好。
实际上，Elasticsearch 的 translog 机制就是典型的 WAL（write-ahead logging）。
