如果沒有用 fsync 把數據從文件系統緩存刷（flush）到硬盤，我們不能保證數據在斷電甚至是程序正常退出之后依然存在。為了保證 Elasticsearch 的可靠性，需要確保數據變化被持久化到磁盤。在 動態更新索引，我們說一次完整的提交會將段刷到磁盤，并寫入一個包含所有段列表的提交點。Elasticsearch 在啟動或重新打開一個索引的過程中使用這個提交點來判斷哪些段隸屬于當前分片。 <br/> 即使通過每秒刷新（refresh）實現了近實時搜索，我們仍然需要經常進行完整提交來確保能從失敗中恢復。但在兩次提交之間發生變化的文檔怎么辦？我們也不希望丟失掉這些數據。Elasticsearch 增加了一個 translog ，或者叫事務日志，在每一次對 Elasticsearch 進行操作時均進行了日志記錄。 <br/> 整個流程如下： 1. 一個文檔被索引之后，就會被添加到內存緩沖區，并且追加到了 translog。 :-:  2. 刷新（refresh）使分片每秒被刷新（refresh）一次。 * 這些在內存緩沖區的文檔被寫入到一個新的段中，且沒有進行 fsync 操作。 * 這個段被打開，使其可被搜索。 * 內存緩沖區被清空。 :-:  3. 這個進程繼續工作，更多的文檔被添加到內存緩沖區和追加到事務日志。 :-:  4. 每隔一段時間—例如 translog 變得越來越大—索引被刷新（flush）；一個新的 translog 被創建，并且一個全量提交被執行。 * 所有在內存緩沖區的文檔都被寫入一個新的段。 * 緩沖區被清空。 * 一個提交點被寫入硬盤。 * 文件系統緩存通過 fsync 被刷新（flush）。 * 老的 translog 被刪除。 translog 提供所有還沒有被刷到磁盤的操作的一個持久化紀錄。當 Elasticsearch 啟動的時候， 它會從磁盤中使用最后一個提交點去恢復已知的段，并且會重放 translog 中所有在最后一次提交后發生的變更操作。 <br/> translog 也被用來提供實時 CRUD 。當你試著通過 ID 查詢、更新、刪除一個文檔，它會在嘗試從相應的段中檢索之前， 首先檢查 translog 任何最近的變更。這意味著它總是能夠實時地獲取到文檔的最新版本。 :-:  執行一個提交并且截斷 translog 的行為在 Elasticsearch 被稱作一次 flush。分片每 30 分鐘被自動刷新（flush），或者在 translog 太大的時候也會刷新。 <br/> 你很少需要自己手動執行 flush 操作；通常情況下，自動刷新就足夠了。這就是說，在重啟節點或關閉索引之前執行 flush 有益于你的索引。當 Elasticsearch 嘗試恢復或重新打開一個索引， 它需要重放 translog 中所有的操作，所以如果日志越短，恢復越快。 <br/> translog 的目的是保證操作不會丟失，在文件被 fsync 到磁盤前，被寫入的文件在重啟之后就會丟失。默認 translog 是每 5 秒被 fsync 刷新到硬盤， 或者在每次寫請求完成之后執行(e.g. index, delete, update, bulk)。這個過程在主分片和復制分片都會發生。最終， 基本上，這意味著在整個請求被 fsync 到主分片和復制分片的 translog 之前，你的客戶端不會得到一個 200 OK 響應。 <br/> 在每次請求后都執行一個 fsync 會帶來一些性能損失，盡管實踐表明這種損失相對較小（特別是 bulk 導入，它在一次請求中平攤了大量文檔的開銷）。 <br/> 但是對于一些大容量的偶爾丟失幾秒數據問題也并不嚴重的集群，使用異步的 fsync 還是比較有益的。比如，寫入的數據被緩存到內存中，再每 5 秒執行一次 fsync 。如果你決定使用異步 translog 的話，你需要 保證 在發生 crash 時，丟失掉 sync_interval 時間段的數據也無所謂。請在決定前知曉這個特性。如果你不確定這個行為的后果，最好是使用默認的參數（ `"index.translog.durability": "request"` ）來避免數據丟失。