Translog 安全性理解

Elasticsearch | 作者 hailin0 | 发布于2017年03月29日 | 阅读数:2612

在文件被fsync+到磁盘前,被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被 +fsync' 刷新到硬盘,并且 是在写请求完成之后(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。最终, 基本上,这意味着在整个请求被+fsync+到主分片和复制分片的translog之前,你的客户端不会得到一个 200 OK 响应。
 
------------------------------分割线------------------------
 
以上从权威指南中看到的,意思是说translog会每隔5秒刷新的磁盘,客户端的写操作只是保证translog被写入缓冲中吗?这样是否在刷新到磁盘之前断电会丢失数据呢?
已邀请:

kennywu76 - wood@Ctrip

赞同来自: leighton_buaa Xargin wengqiankun

权威指南针对的是es2.x,在这个版本里translog的确是定期异步fsync到磁盘。但是5.x以后,translog持久化方式已经改为per reqeust,也就是每次收到一个写请求以后,请求append到translog,进行一次fsync后才会ack用户,保证数据的安全。但是5.x也允许更改tranlog的持久化方式为async,也就是和 2.x一样,定期异步做。
 
这种安全保障是以牺牲写入吞吐量来换取的(这也是为什么升级到5.x后会发现写入吞吐量下降),所以应该怎么选择要看业务需求。 由于一般线上会配置1个或更多复制片,即使采用异步fsync模式,当某个结点真的掉电translog丢失了部分数据的时候,复制片会被promote成主片,而它的数据是完整的,数据依然安全。 只有同一个shard主副分片所在机器同时掉电才可能丢失部分数据。
 
所以在日志应用场景,一般用户允许极端情况丢失数据,我们就采用async方式持久化translog,可以换取巨大的吞吐量提升。 而在某些业务搜索的场景,一般数据量级很小,如果对于写入速度要求不高,那么可以采用5.x默认的per request方式,保证极端情况下的数据安全。

kennywu76 - wood@Ctrip

赞同来自:

补充:
仔细看了下最新版本的权威指南,内容其实已经针对最新版本的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
 

要回复问题请先登录注册