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

干嘛用的？

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

下图1中灰色部分(见蓝色箭头)表示数据出于 可搜索 & 未落盘 & 已写日志 的状态。此时如果掉电，es重启后还可以把数据从日志文件中读回来。

图1

什么时机写？

有两种玩法：

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

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

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

存在哪里？

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

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

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

图2

什么时候删？

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

为什么要删？

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

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

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

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

translog 长成啥样？

translog为什么总是43个字节？

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

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

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

index.translog.durability: async

index.translog.sync_interval: 3600s

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

数据项魔法数中断符常量中断符版本中断符UUID长度UUID

长度(字节)

4

1

8

3

1

3

1

22

取值

3fd76c17

08

“translog”的ascII码

ox000

ox02

ox000

ox16

uuid hex

作用

用来区分lucene不同版本

的文件

确认es的版本

区分tranlog文件，

同一个分片目录的translog

这个值是一样的

translog.ckp 里面都有啥？

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

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

事务数 — 当前是0

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