#持久化變更 沒用`fsync`同步文件系統緩存到磁盤，我們不能確保電源失效，甚至正常退出應用后，數據的安全。為了ES的可靠性，需要確保變更持久化到磁盤。 我們說過一次全提交同步段到磁盤，寫提交點，這會列出所有的已知的段。在重啟，或重新打開索引時，ES使用這次提交點決定哪些段屬于當前的分片。 當我們通過每秒的刷新獲得近實時的搜索，我們依然需要定時地執行全提交確保能從失敗中恢復。但是提交之間的文檔怎么辦？我們也不想丟失它們。 ES增加了事務日志（`translog`），來記錄每次操作。有了事務日志，過程現在如下： 1. 當一個文檔被索引，它被加入到內存緩存，同時加到事務日志。 **圖1：新的文檔加入到內存緩存，同時寫入事務日志**  2. refresh使得分片的進入如下圖描述的狀態。每秒分片都進行refeash： * 內存緩沖區的文檔寫入到段中，但沒有fsync。 * 段被打開，使得新的文檔可以搜索。 * 緩存被清除 **圖2：經過一次refresh，緩存被清除，但事務日志沒有**  3. 隨著更多的文檔加入到緩存區，寫入日志，這個過程會繼續 **圖3：事務日志會記錄增長的文檔**  4. 不時地，比如日志很大了，新的日志會創建，會進行一次全提交： * 內存緩存區的所有文檔會寫入到新段中。 * 清除緩存 * 一個提交點寫入硬盤 * 文件系統緩存通過fsync操作flush到硬盤 * 事務日志被清除 事務日志記錄了沒有flush到硬盤的所有操作。當故障重啟后，ES會用最近一次提交點從硬盤恢復所有已知的段，并且從日志里恢復所有的操作。 事務日志還用來提供實時的CRUD操作。當你嘗試用ID進行CRUD時，它在檢索相關段內的文檔前會首先檢查日志最新的改動。這意味著ES可以實時地獲取文檔的最新版本。 **圖4：flush過后，段被全提交，事務日志清除**  ##flush API 在ES中，進行一次提交并刪除事務日志的操作叫做 `flush`。分片每30分鐘，或事務日志過大會進行一次flush操作。 `flush API`可用來進行一次手動flush： ```Javascript POST /blogs/_flush <1> POST /_flush?wait_for_ongoing <2> ``` - &lt;1> flush索引`blogs` - &lt;2> flush所有索引，等待操作結束再返回 你很少需要手動`flush`，通常自動的就夠了。 當你要重啟或關閉一個索引，flush該索引是很有用的。當ES嘗試恢復或者重新打開一個索引時，它必須重放所有事務日志中的操作，所以日志越小，恢復速度越快。