在文件被fsync+到磁盘前，被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被 +fsync' 刷新到硬盘，并且 是在写请求完成之后(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。最终， 基本上，这意味着在整个请求被+fsync+到主分片和复制分片的translog之前，你的客户端不会得到一个 200 OK 响应。
------------------------------分割线------------------------
以上从权威指南中看到的，意思是说translog会每隔5秒刷新的磁盘，客户端的写操作只是保证translog被写入缓冲中吗？这样是否在刷新到磁盘之前断电会丢失数据呢？
------------------------------分割线------------------------
以上从权威指南中看到的，意思是说translog会每隔5秒刷新的磁盘，客户端的写操作只是保证translog被写入缓冲中吗？这样是否在刷新到磁盘之前断电会丢失数据呢？
2 个回复
kennywu76 - Wood
赞同来自: leighton_buaa 、Xargin 、wengqiankun
这种安全保障是以牺牲写入吞吐量来换取的（这也是为什么升级到5.x后会发现写入吞吐量下降），所以应该怎么选择要看业务需求。 由于一般线上会配置1个或更多复制片，即使采用异步fsync模式，当某个结点真的掉电translog丢失了部分数据的时候，复制片会被promote成主片，而它的数据是完整的，数据依然安全。 只有同一个shard主副分片所在机器同时掉电才可能丢失部分数据。
所以在日志应用场景，一般用户允许极端情况丢失数据，我们就采用async方式持久化translog，可以换取巨大的吞吐量提升。 而在某些业务搜索的场景，一般数据量级很小，如果对于写入速度要求不高，那么可以采用5.x默认的per request方式，保证极端情况下的数据安全。
kennywu76 - Wood
赞同来自:
仔细看了下最新版本的权威指南，内容其实已经针对最新版本的ES更新了。 即默认设置是per request fsync， 每次客户端写入请求被持久化以后，才会回应200(同时后台也会异步每5s持久化一次)。
对于这段原文：
By default, the translog is fsync'ed every 5 seconds and after a write request completes (e.g. index, delete, update, bulk).
中文版本的这个翻译读起来有些歧义。 我感觉更准确的翻译应该是:
"默认 translog 是每 5 秒、或者处理完写请求(e.g. index, delete, update, bulk)之后，被 +fsync' 刷新到硬盘"
译文里将and翻译成"并且"，读起来容易让人理解成“每次处理完写请求后，还要等待5s的时间异步刷新"。
@medcl