根据官方文档 看源码 实验总结出来的ES各种提交的作用与原理(对应版本7.2.0).
我本地是用xmind做的, 附上xmind的截图.
ES提交.png文字版如下:
ES提交
触发方式
给索引设置
- PUT /my-index-000001/_settings { "index" : { "refresh_interval" : "1s" } }
给文档增删改请求设置
- PUT /test/_doc/1?refresh {"test": "test"}
手动触发
- POST /my-index-000001/_refresh
效果
refresh
- tlog不截断
- 文档可见
- 不会触发段合并
- 不调用fsync, 不保证持久化
- 注意: 默认1s触发一次, 但有个特殊设定, 只有30s内接收到至少一个搜索请求的时候, 索引的refresh才会按照设置时间频率触发, 也就是说没有搜索请求的索引的refresh不会自动触发.
flush
- tlog截断
- 文档不可见
- 可能触发段合并
- 调用fsync, 保证持久化
- 没有类似于Solr的openSearcher=true选项, 不能让文档可见.
原理
refresh
- 触发lucene的reopen, 把in-memory buffer转化为in-memory segment.
flush
- 触发lucene的commit, 将in-memory buffer提交到新的段, 与已有的in-memory segments一起提交到硬盘.
lucene
- flush
- 1. 把内存段写到硬盘
- 2. 不调用fsync
- 3. 不更新segment_N文件- commit
- 1. 把内存段写到硬盘
- 2. 调用fsync
- 3. 更新segment_N文件建议
硬提交频率
- 参考tlog的硬盘大小, 使tlog的大小合理, 否则可能会使重启时间过长
软提交频率
- 在满足业务需求的情况下尽可能长一些
不要使用kill -9
- 正确的步骤
- 停止索引程序
- 手动硬提交或等待自动提交触发
- 停止ES服务T-log
作用
- 异常恢复
- RealTime Get By ID
