是什么？
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，懂了吧
