translog是elasticsearch的事务日志文件,它记录了所有对索引分片的事务操作(add/update/delete),每个分片对应一个translog文件。

干嘛用的?

translog是用来恢复数据的。Es用“后写”的套路来加快写入速度 — 写入的索引并没有实时落盘到索引文件,而是先双写到内存和translog文件,

es存储数据时,先把输出存储在内存中,等到refresh(该时间可以在设置mapping时的setting中设置intavel_refresh=xxx)时间后,才把数据存储到lucene中的segment中,清空内存缓冲区,往磁盘里写入commit point信息,文件系统的page cache(segments) fsync到磁盘,之后把translog旧日志删除掉。


什么时机写?

有两种玩法:

request — 每操作都写(默认策略),可靠性最高。

async — 异步定时写,可靠性跟时间间隔有关,试问自己断电时你能接受多少数据无法恢复?

https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-translog.html

我实际对比两种策略的性能数据,第二种的性能优势表现不明显。


存在哪里?

elasticsearch 事务日志translog_ES的translog日志详解

在索引分片目录下,取名translog(蓝色框),跟数据文件目录(金×××)相邻。

translog-N.tlog  - 真正的日志文件,N表示generation(代)的意思,通过它跟索引文件关联

tranlog.ckp - 日志的元数据文件,长度总是20个字节,记录3个信息:偏移量 & 事务操作数量 & 当前代


什么时候删?

在flush的时候,translog文件会被清空。实际的过程是先删掉老文件,再创建一个新文件,取名时,序号加1,比如图2中,flush后你只会看到 translog-2.tlog,原来的translog-1.tlog已被删除。

为什么要删?

如果能留着该多好?像mysql的binlog那样,只要日志在,那么随时可以重放来恢复数据,还可以通过对接数据平台,把数据同步到其它的系统。

那留着有什么坏处呢?数据冗余(因为索引文件和日志文件各有一份),想想mysql的数据文件和binlog文件,人家也冗余,冗余就冗余,没毛病。

是恢复数据时间更长吗?不对,因为恢复只跟新日志文件有关,旧文件可以留着不删。

这个问题我没想特明白,我猜也许只是个设计思路的问题 — 删掉一了百了,更简洁,不考虑重放,留着没多大用,还得要想法子收拾

elasticsearch 事务日志translog_ES的translog日志详解_02

translog为什么总是43个字节?

因为每次事务默认总是被提交,导致translog总会立刻被删除,然后创建新的。而你能看到的总是新的文件。

看下面的代码,当REQUESET时,indexShard.sync会执行,引发flush 操作。

elasticsearch 事务日志translog_ES的translog日志详解_03

可以通过添加以下配置改变策略,不要每次都flush。

index.translog.durability: async

index.translog.sync_interval: 3600s

translog-n.tlog 文件这43个字节到底写的啥?

elasticsearch 事务日志translog_ES的translog日志详解_04

 

数据项

魔法数

中断符

常量

中断符

版本

中断符

UUID长度

UUID

长度(字节)418313122
取值3fd76c1708“translog”的ascII码ox000ox02ox000ox16uuid hex
作用

用来区分lucene不同版本

的文件




确认es的版本

区分tranlog文件,

同一个分片目录的translog

这个值是一样的

translog.ckp 里面都有啥?

其实就是tranlog-1.tlog的3个元数据,而且一直都会是20个字节

当前偏移量 —  2b十进制就是43,正好是文件头的位置

事务数 — 当前是0

当前代 — 1,可以还原出文件名 tranlog-1.tlog