elasticsearch 事务日志translog
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
