是什麼？
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
長度（位元組）41
8313
122取值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，懂了吧
Elasticsearch事務日誌translog
跟大多數分布式系統一樣，es也通過臨時寫入寫操作來保證資料安全。因為lucene索引過程中，資料會首先據快取在記憶體中直到達到乙個量 文件數或是占用空間大小 才會寫入到磁碟。這就會帶來乙個風險，如果在寫入磁碟前系統崩潰，那麼這些快取資料就會丟失。es通過translog解決了這個問題，每次寫操作都會...
elasticsearch配置詳解
elasticsearch的config資料夾裡面有兩個配置檔案 elasticsearch.yml和logging.yml，第乙個是es的基本配置檔案，第二個是日誌配置檔案，es也是使用log4j來記錄日誌的，所以logging.yml裡的設定按普通log4j配置檔案來設定就行了。下面主要講解下e...
誰在使用Elasticsearch
github github使用elasticsearch搜尋20tb的資料，包括13億的檔案和1300億行的 這個不用介紹了吧，碼農們都懂的，github在2013年1月公升級了他們的 搜尋，由solr轉為elasticsearch，目前集群規模為26個索引儲存節點和8個客戶端節點 負責處理搜尋請求...